mirror of
https://github.com/PerpetualSoftware/pad.git
synced 2026-09-22 18:43:45 +00:00
0778c68ca1e1906c545d35988cc9666fedc8a6ee
295 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 xarmian
|
0778c68ca1 |
feat(web): print header + footer for item detail pages (TASK-623) (#154)
Add a rendered header and footer that repeat on every printed page.
Replaces the browser's default print chrome (localhost URL, page
title, date).
Header (top of each page):
{Workspace name} · {Collection icon + name} · {Issue ID}
Footer (bottom of each page):
Printed {date} · {full URL} · Page {n}
Implementation
- Two new `<div>`s rendered inside the item detail page template:
`.print-header` and `.print-footer`. Both carry `aria-hidden` and
are `display: none` on screen, so they never affect the live UI.
- A `@media print` block shows them as `position: fixed` elements at
top: 0 / bottom: 0. In Chromium this causes the browser to repeat
them on every page of the print output. Firefox and Safari render
them only on the first page -- documented as a known limitation
since Chromium is the expected print target.
- `@page { margin: 1.1in 0.6in 0.9in 0.6in }` carves out space for the
header and footer strips so body content doesn't overlap them. This
overrides the default 0.75in margin set in app.css (TASK-621).
- Page number uses `.print-page-num::after { content: counter(page); }`.
`counter(page)` in a pseudo-element evaluates to the current printed
page number in all modern browsers.
- Print date and URL are captured via a `beforeprint` listener so the
values reflect the moment of print, not page-load time. Falls back
to onMount values if `beforeprint` doesn't fire (older browsers).
Users should uncheck "Headers and footers" in the browser print dialog
for the cleanest result -- there's no CSS to suppress the browser's
default print chrome.
Parent: PLAN-620.
|
||
|
xarmian
|
f9a248f4da |
feat(web): print-format the item detail page (TASK-622) (#153)
* feat(web): print-format the item detail page (TASK-622) Layer item-page print formatting on top of the base stylesheet added in TASK-621: - Title row renders as plain text (large, serif-friendly, no button affordance); issue ref prefix stays as a subtle prefix. - Meta info (created/updated + actor) keeps as small-print subtitle. - Properties panel becomes a definition-list block (label / value grid) wrapped in a light card, with form widgets stripped so the selected value reads as plain text. - Content layout stacks the fields panel above the markdown body (no side-by-side columns in print). - Code context section, relationships list, and child items stay. - Comments / activity / version timeline are hidden entirely. - Action buttons, breadcrumb, share/move/delete controls, edit-mode toggle, add-relationship form, save-status chip, link-delete buttons are all stripped. Rendered markdown (.prose) gets a print tune-up in app.css: 11pt body, inline URL suffix on external links (skipped for wiki-links and fragment links), break-inside guards on code / images / tables, light-palette overrides for code blocks and blockquotes. Editor overlays (bubble menu, link popover, slash menu, mobile toolbar, table toolbar, editor toolbar) are hidden in print. Parent: PLAN-620. * fix(web): keep relationship status chips + print title during edit mode (PR #153) Address Codex P2 review comments on TASK-622: - Relationship rows: previously hid the entire `.link-row-actions` wrapper, which silently dropped the `.link-status` chip alongside the destructive delete button. Hide only `.link-delete-btn` so the status stays visible in print. - Title during inline edit: the screen renders either a `.title` button (read) or a `.title-input` textarea (edit); previous rules displayed the button and hid the textarea, so printing while editing produced a title-less page. Apply the same print typography to both, turning the textarea into a non-interactive, borderless plain-text heading. * fix(web): preserve checkbox field state in print output (PR #153) Address Codex P2 review comment on TASK-622. The form-widget strip rule `.field-value button { border: none; background: transparent; }` killed the visual state of `.toggle` (the checkbox field's switch button), since it renders state purely via styling — no text label. The printed page would lose the on/off signal entirely. Exempt `.toggle` from the strip rule via `:not(.toggle)` and add a dedicated print style that renders the toggle as an outlined 11pt box; when the field is on, overlay a check mark via `::after`. The toggle-knob is hidden (it's the sliding switch visual, not useful in print). * fix(web): print URL suffixes for SafeLink + print raw markdown legibly (PR #153) Address Codex P2 review comments on TASK-622: - Rich-editor links (Tiptap SafeLink extension) render with `data-href` instead of `href`, so the print suffix rule `.prose a[href]::after` never fired for the main document body. Add a parallel selector `.prose a[data-href]::after { content: " (" attr(data-href) ")"; }` plus matching skips for internal data-href wiki-links. - The Markdown editor's raw textarea had no print styling. Printing while the Markdown tab was active either clipped the textarea to its screen height or rendered with dark-theme chrome. Add a @media print block to `RawMarkdownEditor.svelte` that flattens the textarea into a plain monospace flow: no border, no background, auto height, visible overflow, page-break-inside: auto. Content prints as markdown source -- not ideal, but readable and content-preserving. * fix(web): hoist FieldEditor print strip rules to global scope (PR #153) Address Codex P2: the `.field-value select / input / button / .toggle` print overrides were defined inside the item detail page's scoped style block. Svelte scoped selectors don't cross component boundaries, so the form widgets rendered inside `FieldEditor` kept their interactive styling in print preview -- selects rendered with their screen chrome, toggles disappeared, etc. Move these rules into app.css's @media print block (which applies globally) and leave a note in +page.svelte explaining why. The `.assignment-select` rule stays in +page.svelte because those selects are inline in this template and correctly scoped. |
||
|
xarmian
|
e81da7a24f |
feat(web): add base @media print stylesheet for workspace layout (TASK-621) (#152)
Tune Ctrl/Cmd+P output so Pad pages can be saved as clean PDFs. This is the first of four tasks under PLAN-620 (Print-friendly item detail pages) and handles the layout-level chrome: hides the sidebar, top bar, floating expand toggles, toasts, command palette, modals, and any [data-print-hide] opt-in element; unlocks the 100vh / overflow:hidden app shell so content flows across pages; forces a light color palette regardless of theme; strips shadows and background images; sets a default 0.75in @page margin. Item-level formatting (title, properties, markdown body), the rendered print header / footer, and the child-item checklist ship in TASK-622, TASK-623, and TASK-624 respectively. Parent: PLAN-620. |
||
|
xarmian
|
f6aa70efb3 |
fix(web): schema-driven trigger+scope options in create forms (IDEA-619) (#151)
* fix(web): schema-driven trigger+scope options in create forms (IDEA-619) Follow-up to PLAN-609. Non-software templates (hiring, interviewing) ship their own convention + playbook trigger vocabularies via the Conventions and Playbooks collection schemas, but the web UI's CREATE forms on both pages were still iterating hardcoded software- only constants. Users in a non-software workspace could see seeded items (thanks to the display tolerance added in PR #146) but could not CREATE new items with the workspace's own vocabulary via the web UI — only via the CLI. Both conventions and playbooks pages now: - Load their collection schema alongside items (non-blocking — a failed schema load falls back to the hardcoded software constants so the page stays functional offline or against an older server). - Derive `createTriggers` and `createSurfaces`/`createScopes` from the schema's `trigger`/`scope` field `options`, with the hardcoded lists as the backstop. - Drive the create-form `<select>` dropdowns from the derived lists instead of the hardcoded constants. - Snap `newTrigger` / `newSurface` / `newScope` state into the effective list when the schema changes so the select never shows a phantom value. - Use the schema-derived lists as the "known" baseline for the filter dropdowns (`allSurfaces` / `allTriggers` / `allScopes`), still unioned with any trigger/scope values discovered on loaded items (preserves the display tolerance from PR #146). Net effect: in a hiring workspace, the New Convention form's trigger dropdown shows `on-candidate-advance`, `on-offer-extended`, etc.; the scope dropdown shows `sourcing`, `screening`, `interviewing`, `offers`. Interviewing workspace gets its own vocabulary. Software workspaces are unchanged. Closes IDEA-619. * fix(web): guard schema loads against workspace-switch stale responses Per Codex review on PR #151. When a user navigates between workspaces quickly, an earlier api.collections.get(...) call for workspace A might resolve AFTER the user is on workspace B, overwriting the current schema state with A's schema. The create/filter dropdowns would then reflect the wrong workspace's trigger/scope vocabulary. Fix: capture the workspace slug at call time; skip the state assignment if the current workspace has changed by the time the response resolves. Symmetrical guard on the catch branch so a failed call from the previous workspace doesn't null out the current one. Applied to both conventions and playbooks pages. * fix(web): clear schema state before workspace-schema fetch Per Codex review iteration 2 on PR #151. The previous guard only dropped stale responses AFTER they resolved — but while a new workspace's fetch was in flight, the old workspace's schema was still present in state. In that window the create/filter dropdowns showed the previous workspace's vocabulary on the new page, so a user could submit a convention with stale trigger/scope values. Fix: clear conventionsCollection / playbooksCollection to null at the START of loadXCollection, before awaiting the fetch. During the in-flight window, createTriggers/createSurfaces fall back to the hardcoded software defaults — the correct conservative state for a workspace whose schema we haven't observed yet. The existing resolved-response stale guard remains. |
||
|
xarmian
|
37ee53d21d |
docs: reflect domain-agnostic template library (TASK-618) (#150)
- CLAUDE.md: templates section expanded to list the 6 categories and what ships under each. Calls out the per-template trigger vocabularies (on-commit vs on-candidate-advance vs on-interview-scheduled) so future agents understand the Conventions/Playbooks collections are domain-aware, not software-hardcoded. Points to PLAN-609 + IDEA-583 as the design record. - README.md: Quick Start template examples now include hiring + interviewing, mention the interactive picker when no --template is passed, and frame templates as covering software AND non-software workflows (people, research, content, operations, personal). Parent: PLAN-609. Closes out the last architecture-tranche task. |
||
|
xarmian
|
dee968e309 |
feat(web): categorized template picker with icons (TASK-617) (#149)
Turns the web workspace-creation pickers into category-grouped lists that mirror the CLI picker shipped in TASK-616. Both the full-page new-workspace flow (/console/new) and the create-workspace modal now group templates under Software / People / Research / Content / Operations / Personal headings and render each template's icon. - WorkspaceTemplate TS type gains optional `category` and `icon` (already emitted by /workspaces/templates since TASK-610). - New shared helper at web/src/lib/utils/templates.ts exposes CATEGORY_ORDER (mirrors Go CategoryOrder), categoryLabel, and groupTemplatesByCategory. Keeps CLI and web pickers aligned on ordering + labels without a third source of truth. - /console/new: replaced the flat template grid with a grouped layout; each group has a small category subhead; each button renders tmpl.icon alongside name + description. Offline fallback templates (used when the API call fails) updated to include category='software'. - CreateWorkspaceModal: same grouped layout for the create tab, with the existing "blank" option retained as a trailing category-less button. Icon prefixed on every template card. Tests ----- Go side (existing library tests for grouping behavior via TestGroupTemplatesByCategory cover the shared ordering contract). Web build verified via `npm run build` — clean. Parent: PLAN-609. |
||
|
xarmian
|
e0f3583333 |
feat(cli): categorized template picker + interactive select (TASK-616) (#148)
* feat(cli): categorized template picker + interactive select (TASK-616)
Turns the CLI template picker from a flat alphabetical dump into a
category-aware flow that reflects the Software / People / Research /
Content / Operations / Personal taxonomy established by PLAN-609.
Library
-------
- collections.GroupTemplatesByCategory returns visible templates
bucketed into CategoryOrder with a trailing slot for any
custom-category templates — one canonical grouping that both CLI
and the upcoming web picker (TASK-617) can consume.
- collections.CategoryLabel turns category slugs into display labels
("software" → "Software") with passthrough for unknown values.
- collections.CategoryOrder exposes the canonical display order.
CLI
---
- New cmd/pad/templates_picker.go defines:
- printGroupedTemplates: writes the grouped listing with icons,
aligned columns, and a dim "(default)" marker on startup.
- pickTemplateInteractive: prompts when the user hasn't passed
--template and is on a TTY. Accepts a number OR a template name;
enter selects the default (startup); invalid input re-prompts.
- canPromptForTemplate: TTY detection so scripts never block.
- pad workspace init --list-templates now uses the grouped printer.
- pad workspace init / pad init error messages for unknown templates
show the grouped list instead of a flat dump.
- pad init now triggers pickTemplateInteractive when no --template
flag is set AND stdin/stdout are TTYs. Non-TTY invocations fall
back to the "startup" default unchanged.
- --template flag help no longer hardcodes "startup, scrum, product"
since the list now grows with non-software templates.
Tests
-----
- Library: TestGroupTemplatesByCategory (canonical order, no hidden,
every visible template assigned), TestCategoryLabel.
- CLI: TestPickTemplateInteractiveDefault / ByName / ByNumber /
RetriesOnInvalid, TestPrintGroupedTemplatesIncludesEveryVisibleTemplate
(smoke: every visible template renders, demo hidden, category
headers present).
Parent: PLAN-609.
* fix(cli): propagate non-EOF prompt read errors in template picker
Per Codex review on PR #148. pickTemplateInteractive previously
mapped any ReadString error to silently selecting the default
template. A detached PTY returning EIO or a similar read failure
would quietly create a workspace with the startup template even
though the user never made a valid choice. Restrict the silent
fallback to io.EOF (which is benign for pipes, tests, closed
stdin) and bubble up any other error so the command aborts.
* test(cli): cover non-EOF read error path in template picker
Adds TestPickTemplateInteractiveSurfacesNonEOFReadErrors to verify
the behavior change from the previous commit — a non-EOF read
failure propagates up instead of silently selecting the default
template.
|
||
|
xarmian
|
fed365d914 |
feat(templates): ship interviewing template (TASK-615) (#147)
* feat(templates): ship interviewing template (TASK-615) Candidate-side companion to the hiring (company-side) template. Same People category, near-zero collection overlap — a real proof that one category can hold two templates with barely-related schemas. Collections ----------- - Applications (APP) — roles being tracked, stages from researching → applied → screen → interviewing → offer → accepted / rejected / withdrawn - Interviews (INT) — individual rounds, child of an Application, with round type, format, date, prep_status (including completed) - Companies (CO) — standalone research notes on companies, referenced from Applications via wiki-link so notes are persistent even across multiple Applications at the same company - Contacts (CON) — referrals, recruiters, interviewers — tracked independently for followup hygiene - Docs, Conventions, Playbooks Trigger vocabularies -------------------- - InterviewingConventionTriggers: always, on-application-submitted, on-interview-scheduled, on-interview-completed, on-stage-change, on-offer-received, on-rejection, weekly-review - InterviewingPlaybookTriggers: on-application-submitted, on-interview-scheduled, on-interview-completed, on-stage-change, weekly-review, manual - Scopes: all, research, applications, interviews, followups Starter pack ------------ - Conventions (3): 48h prep notes (should/on-interview-scheduled), end-of-application retros (should/on-stage-change), 24h thank-yous (should/on-interview-completed) - Playbooks (3): Log an Interview, Weekly Job Search Review, Interviewing Workspace Onboarding - Seed items (2): one example Application, one example Company Tests ----- - TestInterviewingTemplate — collections present, interviewing triggers present and distinct from both software AND hiring triggers - TestSeedCollectionsFromTemplateInterviewing — end-to-end: seven collections created, starter pack populated, prefixes correct Parent: PLAN-609. * fix(templates): mark interviewing Companies.closed as terminal Per Codex review on PR #147. The Companies status field had a 'closed' option but no TerminalOptions declared, so done-state resolution fell back to the global default set which doesn't include 'closed' — closed companies were being counted as active in dashboard and progress views. Adding TerminalOptions fixes lifecycle metrics without changing user-facing options. * fix(templates): Log-an-Interview playbook uses only interviewing collections Per Codex review iteration 2 on PR #147. The playbook step referenced 'Create a follow-up Task' but the interviewing template doesn't ship a tasks collection. Rewrote the step to use the collections that actually exist — log the thank-you as a comment on the Interview and update the matching Contact's last_contact. Keeps the starter playbook consistent with the schema it ships alongside. |
||
|
xarmian
|
b891ba84a4 |
feat(templates): ship hiring template (TASK-614) (#146)
* feat(templates): ship hiring template (TASK-614) First non-software template under PLAN-609. Proves the machinery built by TASK-610 through TASK-613 end-to-end: category grouping, per-template trigger vocabularies, template-owned starter packs, domain-specific seed items. Collections ----------- - Requisitions (REQ) — open roles, with status/team/level/location - Candidates (CAND) — applicants, parent-linked to a Requisition - Interview Loops (LOOP) — interview rounds, parent-linked to a Candidate - Feedback (FB) — per-interviewer debriefs, parent-linked to a Loop - Docs — rubrics, process notes - Conventions + Playbooks — using hiring trigger vocabulary Trigger vocabularies -------------------- - HiringConventionTriggers: always, on-candidate-advance, on-loop-scheduled, on-feedback-submitted, on-offer-extended, on-close-requisition - HiringPlaybookTriggers: on-candidate-advance, on-interview-scheduled, on-feedback-submitted, on-close-requisition, manual - HiringConventionScopes / HiringPlaybookScopes: all, sourcing, screening, interviewing, offers Starter pack ------------ - Conventions (3): PII handling (must/always), requisition linking (should/always), 24h debriefs (should/on-feedback-submitted) - Playbooks (2): "Advance a Candidate" (on-candidate-advance), "Hiring Workspace Onboarding" (manual) - Seed items: one example Requisition, one example Candidate (both labeled as seeded so users can delete or overwrite) Tests ----- - TestHiringTemplate — collections present, trigger vocabulary uses hiring values and does not leak software triggers (on-commit etc.) - TestSeedCollectionsFromTemplateHiring — end-to-end: seeding creates all seven collections plus populates the starter pack Parent: PLAN-609. * fix(web): display hiring triggers on conventions + playbooks pages Per Codex review P1 on PR #146. The conventions page hardcoded a software-only TRIGGERS list in its grouping loop, silently hiding any convention whose trigger wasn't in that list — so a hiring workspace's seeded conventions (on-candidate-advance etc.) never appeared in the primary management UI. Same issue on the playbooks page's filter dropdown. - conventions page: grouping now iterates the union of the hardcoded TRIGGERS (in original order) plus any triggers discovered in the data (sorted alphabetically). Unknown triggers fall back to a generic bell icon + the raw trigger string via a triggerMeta helper. byTrigger is now SvelteMap<string, Item[]>; the narrow Trigger type still gates the create form. - playbooks page: the filter dropdowns for trigger and scope now expose the union of the hardcoded list and any distinct values found on loaded playbooks. Create form still uses the narrow list. The broader "derive options from collection schema so the CREATE forms also follow the workspace's trigger vocabulary" is tracked as IDEA-619 for a follow-up PR. * fix(templates): ship explicit prefixes for hiring collections Per Codex P2 on PR #146. The seeded candidate's content referenced --parent REQ-1, but the default DerivePrefix turns "Requisitions" into "REQUI" (strips trailing S, caps at 5), so the example wouldn't resolve. Similar problems for Candidates (CANDI) and Feedback (FEEDB). - Add optional Prefix string field to DefaultCollection so templates can override the derived prefix. Empty (the default) preserves today's auto-derivation for every existing template. - Thread DefaultCollection.Prefix through SeedCollectionsFromTemplate to the CollectionCreate call — the CreateCollection API already supported a Prefix field. - Hiring template sets explicit prefixes: Requisitions → REQ, Candidates → CAND, Interview Loops → LOOP, Feedback → FB. The seeded onboarding text's --parent REQ-1 reference now resolves. - Test asserts the expected prefixes land on the created collections. * fix: add 'offers' to hiring playbook scopes + tolerate custom scopes in web UI Per Codex review iteration 3 on PR #146. - HiringPlaybookScopes now includes 'offers', matching HiringConventionScopes. The hiring pipeline has a distinct offer stage and playbook workflows tied to offer management were previously uncovered in the schema. - web/conventions page: the scope filter dropdown now exposes the union of SURFACES (original order) plus any scopes discovered on loaded conventions, via a new allSurfaces $derived. Same pattern as the earlier triggers fix. Non-software scopes (sourcing, screening, interviewing, offers) now show up for hiring workspaces instead of being hidden by the narrow hardcoded list. The conventions create form still uses the hardcoded SURFACES — that broader "derive from collection schema" fix is tracked as IDEA-619. * fix(templates): hiring Feedback BoardGroupBy uses submitted, not recommendation Per Codex review iteration 4 on PR #146. Feedback items have two select fields: recommendation (strong-hire/hire/mixed/no-hire/ strong-no, no terminal values) and submitted (pending/submitted, terminal=submitted). The done-state pipeline prefers settings.board_group_by when it's a select field, so grouping on recommendation made terminal detection fall back to checking recommendation against default done-statuses — never matching, leaving submitted feedback perpetually 'active' in active-count views. Group on submitted so completion actually registers. * fix(templates): Advance-a-Candidate playbook uses valid Feedback fields Per Codex review iteration 5 on PR #146. The seeded playbook told agents to create Feedback items with recommendation=pending, but recommendation's allowed values are only the concrete verdicts (strong-hire, hire, mixed, no-hire, strong-no) — 'pending' would be rejected at field validation. Updated the step to use submitted=pending (which IS in the allowed options) and call out that recommendation should stay blank until the interviewer actually records a verdict. |
||
|
xarmian
|
4d02616d54 |
refactor(skill): generalize /pad for domain-agnostic workspaces (TASK-613) (#145)
* refactor(skill): generalize /pad for domain-agnostic workspaces (TASK-613) The /pad skill is baked into the binary and runs the same regardless of whether the workspace is a software project, a hiring pipeline, or a research notebook. This change strips the software-centric framing without losing any dev workflow — dev-specific rules that used to live in SKILL.md are already shipped as conventions by the software templates (TASK-612). Changes ------- - Always-on conventions blurb now frames trigger vocabulary as workspace-dependent and gives non-software examples (anonymize candidate names, always cite sources). - "Before Performing Work" no longer hardcodes on-commit / on-pr-create as if they were universal. Replaced with a generic X→on-X mapping and a note that each template defines its own trigger set, with the software set called out as the common case. - "Creating items" examples mix dev and non-dev patterns and add a guiding note to match intent to the workspace's actual collections. - Planning workflow drops "Each task should be PR-sized" — replaced with a domain-neutral sizing guideline (software=PR, hiring=loop, research=question, etc.). PR-sizing for software workspaces is captured in the template's conventions. - Onboarding workflow now prefers the template's onboarding playbook as its first step, falls back to the codebase scan only when a playbook isn't present or is software-flavored. Makes room for hiring/interviewing/research templates to ship their own onboarding flows without skill churn. - Key principle #7 ("Keep it practical — tasks should be PR-sized") rewritten to reference the workspace's conventions. No CLI, API, or store changes — skill file only. Parent: PLAN-609. * fix(skill): replace literal on-X placeholder, include playbook triggers Per Codex review on PR #145: - The on-X placeholder in the pre-action example commands would be run literally by an agent and return 0 results, causing required conventions to be skipped. Replaced with explicit <trigger> angle- bracket placeholders plus concrete examples (on-implement, on-commit, on-review) an agent can substitute or run directly. - Software playbooks use a slightly different trigger vocabulary from software conventions (on-triage, on-release, on-review, on-deploy, manual). Updated the \"inspect the schema\" guidance to call out that agents should inspect BOTH the Conventions and Playbooks schemas to discover triggers, not the Conventions one alone. |
||
|
xarmian
|
115b33849e |
feat(templates): software starter pack + idempotent seeding (TASK-612) (#144)
* feat(templates): software starter pack + idempotent seeding (TASK-612) Ship the software templates (startup, scrum, product) with a curated starter pack of conventions + playbooks so new workspaces feel "batteries included" rather than empty shells. The pack is a safe, small subset drawn from the existing convention/playbook library — the library itself remains the full catalog for interactive onboarding. Starter pack contents --------------------- Conventions (4): - Conventional commit format (on-commit, should) - Never push directly to main (on-commit, must) - Run tests before completing tasks (on-task-complete, must) - Review your own changes before PR (on-pr-create, should) Playbooks (2): - Implementation Workflow (on-implement) - Code Review Process (on-review) The pack is materialized by looking up library items by title and converting them to SeedConvention / SeedPlaybook via json.Marshal of the expected field shape. When the library's wording changes, the template's seed content changes automatically. Store-side changes ------------------ SeedCollectionsFromTemplate is now idempotent with respect to seed items: items are only created in collections that were freshly created during the current call (tracked via a freshlyCreated set). That's the invariant that lets the server's startup auto-upgrade safely re-run on every boot without duplicating items across every workspace in the DB. Empty template name preserves the old behavior (default collections, no starter pack) — this keeps backward compatibility for callers that don't pass a template, including the server-startup auto-upgrade path and all existing server tests. Explicit "startup" / "scrum" / "product" now gets the starter pack. Tests ----- - TestSoftwareStarterPacksPopulated — guards against library-title drift - TestSoftwareTemplatesShipStarterPacks — each software template ships a pack - TestSeedCollectionsFromTemplateSeedsStarterPack — end-to-end seeding works - TestSeedCollectionsFromTemplateIdempotentWithSeedItems — re-seed doesn't duplicate Parent: PLAN-609. * fix(cli): default pad init to startup template when --template is omitted Per Codex review on PR #144. Without this, `pad workspace init` without `--template` no longer seeded the starter pack, even though startup is documented as the default. The fix lives in ensureWorkspace (shared by both init.go and the workspace creation command in main.go) — empty flag is rewritten to "startup" there. Tests and other direct API callers that want an empty workspace still pass Template="" through. * fix(cloud): auto-create workspace passes startup template for starter pack Per Codex review iteration 2 on PR #144. The auto-create cloud-signup flow calls SeedCollectionsFromTemplate with an empty template, which after this PR's semantics meant new cloud workspaces got no starter conventions/playbooks. Pass "startup" explicitly to match the CLI init behavior. * fix(store): propagate collection lookup errors during seeding Per Codex review iteration 3 on PR #144. seedItem previously treated any error from GetCollectionBySlug as a silent no-op, which hid real DB lookup failures — a transient error during workspace creation would make seeding appear successful while conventions/playbooks were in fact missing. Now we distinguish the two cases: - err != nil → propagate so callers can detect partial init - coll == nil → benign (template references a slug not in its collections list; template-author bug, no-op) * fix(store): idempotent seeding by item title (partial-init recovery) Per Codex review iteration 4 on PR #144. The previous design gated item seeding on collections being freshly-created-in-this-call, which trapped partially-initialized workspaces: if a DB error fired between collection creation and item seeding, a retry would see the collections already existed and skip every remaining seed item. Switch to title-based idempotency. Before inserting a seed item we list the target collection's existing items (once per collection, via a small cache) and skip any whose title already exists. That makes seeding: - Idempotent: re-running a template doesn't duplicate items - Recoverable: retrying fills in missing items after partial init - Retry-safe: the auto-upgrade path can re-run safely on every boot New test TestSeedCollectionsFromTemplateRecoversPartialInit exercises the recovery path explicitly. |
||
|
xarmian
|
d1c7ede735 |
feat(templates): parameterize conventions & playbooks schemas (TASK-611) (#143)
The Conventions and Playbooks collections currently hardcode their trigger and scope select options to a software-centric vocabulary (on-commit, on-pr-create, backend, frontend, ...). That makes it impossible for a non-software template to ship domain-specific triggers like on-candidate-advance or on-interview-scheduled, which is a hard blocker for PLAN-609. - Change conventionsCollection() and playbooksCollection() to accept trigger + scope option lists from the caller. - Export SoftwareConventionTriggers, SoftwareConventionScopes, SoftwarePlaybookTriggers, SoftwarePlaybookScopes as the canonical software-domain defaults. Non-software templates pass their own lists. - Defensively copy the caller's slices inside the helpers so a template package author cannot accidentally mutate a shared option list. - Update scrum + product templates to pass the software defaults. - Refactor Defaults() in defaults.go to use the same parameterized helpers — eliminates ~85 lines of duplicated schema definition that had drifted out of sync with the templates.go copy. - Add tests covering: caller option propagation, defensive copying, and software-template invariants. Parent: PLAN-609. |
||
|
xarmian
|
73a6e1f3a9 |
feat(templates): categorize WorkspaceTemplate + hide demo (TASK-610) (#142)
Refactor the WorkspaceTemplate struct to carry the metadata and domain- specific seed packs needed for the upcoming non-software templates. - Add Category, Icon, Hidden, Conventions, Playbooks fields to the WorkspaceTemplate struct. Existing fields (Name, Description, Collections, SeedItems) unchanged. - Define SeedConvention and SeedPlaybook types so templates can carry domain-specific rules and workflows (populated in a follow-up task). - Introduce category constants (software, people, research, content, operations, personal). - Assign Category=software and Icon to startup (🚀), scrum (🏃), product (📦). Mark demo (🎬) as Hidden so it no longer appears in the picker while remaining buildable by explicit --template demo. - Split ListTemplates() into a filtered picker view and a new ListAllTemplates() for internal tooling. - Expose category and icon on the /workspaces/templates API response so the web picker can group by category in a follow-up task. - Add package tests for hidden-filtering and picker metadata invariants (the package previously had no tests). Parent: PLAN-609. |
||
|
xarmian
|
f222131dfe |
fix(ui): always show faint hover-only sidebar + buttons and card stars (#141)
* fix(ui): always show faint hover-only controls The sidebar + buttons and item-card star buttons were fully hidden until hover, which wasn't discoverable. They're already muted enough that showing them at reduced opacity is fine, and they still pop to full opacity on hover. - Sidebar .section-add-btn: opacity 0 -> 0.5 - Sidebar .nav-quick-add: visibility:hidden -> opacity 0.5 - ItemCard .star-btn: opacity 0 -> 0.4 (unstarred outline ☆ now visible) Refs IDEA-605 * fix(ui): bump unstarred star opacity 0.4 -> 0.65 for mobile readability |
||
|
xarmian
|
9e7daa779f |
feat: tie done-detection to the board group-by field (TASK-604) (#140)
* feat: tie done-detection to the board group-by field
Closes TASK-604. Make "is this item done?" follow the collection's
settings.board_group_by rather than the hardcoded `status` key. If a
collection's board is grouped by `resolution`, then resolution's
terminal options drive dashboard counts, progress bars, changelog,
and starred-items filtering. Collections without an explicit
board_group_by (every collection today) continue to behave exactly
as before because the fallback resolves to `"status"`.
Why this shape
- No ambiguity: one field per collection wins. No reconciling
"status says in-progress, resolution says fixed."
- One JSON path to swap: every $.status query becomes
$.<done_field>. No dynamic OR across schema-discovered fields.
- Matches the mental model: the field you organize the board by is
the field that represents the item's current state. The old
mismatch (board grouped by X, "done" count from status) is a
latent bug this resolves.
- Non-breaking: board_group_by defaults to nil → DoneFieldKey
returns "status" → behavior identical to pre-TASK-604.
Model layer (internal/models/terminal.go)
- DoneFieldKey(schema, settings) resolves the done-field key with a
fallback chain: valid select on schema → that field, else "status".
- TerminalValuesForDoneField(schema, settings) returns (fieldKey,
values) honoring the done field, falling back to
DefaultTerminalStatuses when the resolved field has no
terminal_options.
- TerminalPlaceholdersForDoneField(schema, settings) is the SQL
convenience returning (fieldKey, placeholders, args).
- IsTerminalItem(fields, schema, settings) is the canonical
Go-side membership check.
- Legacy API (TerminalStatusesFromSchema, IsTerminalStatus,
TerminalStatusPlaceholders) kept as back-compat wrappers that
delegate with empty settings — resolve to "status" for callers
that don't have settings in scope yet.
SQL callers migrated to the new helpers
- internal/store/collections.go ListCollections active-count query
- internal/store/items.go GetItemProgress + GetAllItemProgress:
- New collectionDoneFilter type + childrenDoneFiltersFor{Parent,
Collection} + doneFiltersForWorkspace helpers load each
candidate collection's (schema, settings) and resolve per-
collection done keys + terminals.
- buildChildrenDoneExpr(filters, alias) compiles filters into a
single SQL boolean expression using per-collection OR clauses:
((alias.collection_id=? AND LOWER(...)
IN (?,?)) OR (alias.collection_id=? AND LOWER(...)
IN (?,?)) ...)
- Each child item is evaluated against its own collection's
done rules, so mixed-collection child progress is correct
without a global union hack.
- internal/store/agent_roles.go GetRoleBreakdown + Go-side filter
- internal/store/item_stars.go starred-items filtering now uses a
collectionDoneContext map (schema + settings) and IsTerminalItem.
Go-side callers migrated
- internal/server/handlers_dashboard.go: buildSchemaMap →
buildDoneContextMap (carries settings), isItemTerminal →
isItemDone (evaluates against the done field). 7 call sites
updated.
- internal/server/handlers_items.go: plan-progress recompute and
per-item /progress endpoint now use the done-context approach.
Left status-specific (per task scope)
- Link-payload $.status extracts in items.go getItemLink /
GetItemLinks / GetParentForItem — these populate
link.SourceStatus / link.TargetStatus, which are status-specific
by design.
- cmd/pad reconcile paths — no schema in scope, default-list
fallback is the right call.
- search.go facet "status breakdown" — a different UX concept
(bucket search results by status values) than done-detection.
Web UI reactivity
- FieldEditor: new activeDoneField prop. Each modal derives it from
boardGroupBy with the same fallback rule as the Go DoneFieldKey.
- Fields tab: the "Done?" column header on each select field renders
an "Active" green pill when that field is the board group-by, or a
muted "Saved" pill + inline hint otherwise ("Switch the board
group-by to <key> to make them drive done-detection"). Reactive to
boardGroupBy changes in the Display tab.
- DisplaySettingsEditor: "Board group by" label gets a helper line
explaining the new responsibility.
Tests
- internal/models/terminal_test.go: 13 unit tests covering fallback
resolution, placeholder args, membership (case-insensitive), and
back-compat shim semantics.
- internal/store/done_field_test.go: 3 integration tests:
1. Bugs collection grouped by resolution → items with terminal
resolution values count as done; items with status=fixed but
resolution=open do NOT count as done (proves status is no
longer consulted when it isn't the done field).
2. Collection without board_group_by still uses status terminals.
3. Mixed-collection children: each child evaluated against its
own done rules.
All pass alongside the full existing suite.
* fix: restrict done field to select (reject multi_select)
Two linked Codex P1 findings on PR #140, both rooted in the same
gap: multi_select fields store their values as JSON arrays, but both
the Go-side membership check (IsTerminalItem) and the SQL done
expression (buildChildrenDoneExpr) assume a scalar string. Naively
accepting multi_select as a done field would silently miss items
whose terminal value is one of several in the array — dashboards
and progress would report wrong counts.
Rather than implement array-containment semantics across both
paths (which would require deciding "any terminal value → done" vs
"all terminal values → done", SQL-dialect-aware JSON-contains, and
new tests for both shapes), close the gap with a constraint: only
select fields qualify as a done field. If array semantics become
a requirement later, that's a focused follow-up that can update
both paths together with a clear definition.
Changes
- DoneFieldKey and TerminalValuesForDoneField: loop bodies now
match only `select`, not `select || multi_select`. A
board_group_by pointing at a multi_select field falls back to
'status' — matching the rule for non-existent or non-select
fields.
- IsTerminalItem: docstring made the scalar contract explicit;
non-string values (which would be the multi_select array shape)
already returned false, which is now the deliberate behavior.
- buildChildrenDoneExpr: added a doc note that the scalar
JSON_EXTRACT path is correct because the upstream resolution
only hands us select fields.
- Web UI: EditCollectionModal + CreateCollectionModal derive
activeDoneField matching the backend rule (select only), and
FieldEditor.isActiveDoneField gates on field.type === 'select'.
A multi_select field never lights up the green "Active" pill now,
even if a user somehow pointed board_group_by at one.
Tests
- Replaced TestDoneFieldKey_AcceptsMultiSelect with
TestDoneFieldKey_RejectsMultiSelect. Asserts that a multi_select
board_group_by falls back to 'status' instead of being honored.
- Existing 12 unit tests + 3 integration tests all still pass.
* fix: include soft-deleted collections in done-filter loaders
Two related Codex P2s on PR #140. The done-filter loaders were
limiting their SELECT to collections with deleted_at IS NULL, but
the outer callers (GetItemProgress, GetAllItemProgress,
GetRoleBreakdown) count items regardless of their collection's
deleted_at. Net effect: after a collection was soft-deleted, its
items lost their per-collection clause in buildChildrenDoneExpr and
were always evaluated as non-terminal — undercounting done in plan
progress and inflating active counts in the role breakdown.
Fix
Drop the `c.deleted_at IS NULL` guard from all three filter
loaders:
- childrenDoneFiltersForParent
- childrenDoneFiltersForCollection
- doneFiltersForWorkspace
Soft-deleted collections still have valid schema + settings rows in
the DB, so the done rules remain applicable until a hard delete
cascades. This also matches what the outer queries count: if they
include items from a soft-deleted collection, the filter loaders
must too.
Regression test
TestGetItemProgress_HonorsSoftDeletedChildCollections:
1. Create a parent + two children in a child collection where one
child is done and one is open — assert done=1.
2. DeleteCollection on the child collection (soft-delete).
3. Re-run GetItemProgress — assert done is still 1, not 0.
Fails before the filter-loader fix, passes after.
* fix: avoid N+1 in plans progress + preserve done fallback on bad schemas
Two Codex P2s on PR #140.
P2: Avoid N+1 list-collection queries in plans progress
handlePlansProgress's restricted path was calling s.store.
ListCollections solely to build a ctxMap, but ListCollections runs a
separate active-item COUNT query per collection (collections.go),
burning O(number of collections) round-trips on every call. In
larger workspaces this materially inflates latency and can cause
timeouts. Add a lightweight Store.ListCollectionsMinimal that
returns only the ID / Schema / Settings needed for done-context
construction and skips the count queries entirely. Handler switches
to it.
P2: Preserve done fallback for unparseable collection schemas
scanCollectionDoneFilters was `continue`-ing past collections whose
schema failed to parse. Because buildChildrenDoneExpr composes a
per-collection OR clause and only applies the default-list fallback
when NO filters are constructed overall, a single malformed
collection could leave its items without a matching clause —
silently marking them as perpetually active in progress / role /
starred queries. Emit a fallback filter (status + DefaultTerminal-
Statuses) for that collection instead of skipping it, matching
pre-TASK-604 behavior for its items while still honoring the
configured rules for every other collection.
* fix: sanitize done-field keys + cover granted-item collections
Two more Codex findings on PR #140.
P1: Sanitize done-field keys before embedding SQL JSON paths
buildChildrenDoneExpr passes the resolved done-field key straight
into JSONExtractText, whose dialect implementations interpolate it
as a string literal inside `json_extract(..., '$.<key>')` /
`-->>'<key>'`. Schema / settings rows are persisted without backend-
side key validation, so a crafted board_group_by (e.g. a key with
quotes, semicolons, or SQL metacharacters) could break the
resulting query or inject. Since TASK-604 made done-field
resolution dynamic, this needs a chokepoint.
Fix: DoneFieldKey now refuses to resolve to any candidate that
doesn't match ^[a-zA-Z][a-zA-Z0-9_]*$ and falls back to the literal
"status" (which is always safe). The pattern matches the convention
already in use for search-field filtering in internal/server/
handlers_search.go.
Added TestDoneFieldKey_RejectsUnsafeKeys covering injection-shaped
strings, dots, dashes, leading digits, empty strings, and spaces.
P2: Include granted-item collections in dashboard done context
The dashboard was filtering `collections` by visibility BEFORE
building ctxMap, but allItems can still include items from
collections outside the visibility set via item-level grants
(dashItemIDs). Those items missed their own done-rules and
fell back to the status-default, misclassifying them for guests
with item-level grants in collections that use a non-status done
field.
Fix: build ctxMap from ListCollectionsMinimal(workspaceID) first —
always covering every collection in the workspace — then apply
visibility filtering to `collections` for the summary section only.
isItemDone now sees the real done rules for every item the
dashboard iterates, regardless of how visibility surfaced it.
* fix(web): mirror backend safe-key check in activeDoneField derivation
Codex P2 on PR #140. The previous commit added a safe-key regex on
the backend (DoneFieldKey rejects keys outside ^[a-zA-Z][a-zA-Z0-9_]*$
and falls back to "status"), but the Web activeDoneField derivation
in both modals only checked type === 'select'. For legacy / API-
created schemas carrying keys like `resolution-v2` or `foo.bar`, the
Fields tab would display an "Active" green pill on that field even
though the server silently ignores it and falls back to status. Users
could configure terminal options on the wrong field and never see
them take effect.
Fix: export isSafeDoneFieldKey from field-editor-types.ts (a tiny
helper wrapping the same regex the backend uses) and gate both
modals' activeDoneField derivations on it. Unsafe keys fall back to
'status' in the UI, matching the backend's behavior exactly —
Active/Saved pills are now truthful.
|
||
|
xarmian
|
bafb3c2be5 |
feat(web): create-time Display/Quick Actions + live prompt preview (TASK-599) (#139)
* feat(web): create-time Display/Quick Actions + live prompt preview
Closes TASK-599 in PLAN-593 — the last task.
Closes the parity gap between Create and Edit modals by bringing the
Display and Quick Actions editors to the Create flow (under an
"Advanced" reveal so the default create path stays short), and adds a
live substitution preview to the Quick Actions prompt editor in both
modals.
New shared code
- web/src/lib/utils/quick-action-preview.ts: single source of truth
for the template-variable list, kept in lockstep with the runtime
substitution in QuickActionsMenu. Exports parsePrompt() that
tokenizes a prompt into text / known-var / unknown-var segments,
plus contextFromItem() (real items for Edit) and
placeholderContext() (synthetic for Create or empty collections).
- DisplaySettingsEditor.svelte: extracts the 5 display selects
(default view, layout, board/list group-by, list sort-by) into a
reusable pure-presentation block with bindable props.
- QuickActionsEditor.svelte: extracts the full Quick Actions sub-UI
(both Item and Collection sections) with add/remove/reorder logic
internal to the component. Each action card now renders a live
preview panel below the prompt input showing the resolved output
with subtle blue highlights on known variables and red + wavy
underline on unknown ones. An explicit warning line appears below
the preview when typos are detected.
EditCollectionModal
- Replaces the inline Display tab markup with DisplaySettingsEditor.
- Replaces the inline Quick Actions tab markup with QuickActionsEditor.
- Fetches the first item in the collection on open
(api.items.listByCollection limit=1) to build a realistic preview
context; falls back to placeholder values if the collection is
empty or the fetch fails.
- Net result: ~390 lines removed (deduped into the components), local
state for action list and group-by derivation remains here since it
drives the schema save.
CreateCollectionModal
- New collapsible "Advanced" section below the fields area, collapsed
by default. Contains DisplaySettingsEditor + QuickActionsEditor.
- New state for default_view / layout / board_group_by / list_group_by
/ list_sort_by / quick_actions, wired into handleCreate's settings
serialization.
- Template selection now pre-fills the Advanced state from the
template's settings (board_group_by, default_view, quick_actions
etc.), so template-provided settings are preserved even for users
who never open the Advanced section.
- Derived selectFieldKeys / sortableFieldKeys from the (not-yet-saved)
fields so the group-by pickers reflect what the user is building.
- A small $effect auto-corrects boardGroupBy / listGroupBy when the
user removes the select field they pointed at (Advanced only —
doesn't mutate state behind the user's back while collapsed).
- Preview context uses placeholderContext() since no items exist yet;
the {collection} token updates live as the user types a name.
Out of scope
- Cross-field done-detection (separate, tracked in TASK-604).
- Any new field types / schema additions.
* fix(web): scope-aware previews and honest empty-resolution rendering
Two Codex findings on PR #139, both about preview accuracy:
P2: Use scope-aware context for collection action previews
Collection-scope actions run with `item` unset in QuickActionsMenu,
so item-only variables ({ref}, {title}, {status}, {priority},
{content}, {fields}, {plan}, {phase}) resolve to empty strings at
runtime. The preview was parsing collection-scope prompts with the
same item-populated context used for item-scope actions, so the
preview could show rich substitutions the user would never actually
get when clicking the action.
Fix: add toCollectionScope() in quick-action-preview.ts that clears
item-only variables and keeps only {collection}. QuickActionsEditor
now derives itemScopeContext (verbatim) and collectionScopeContext
(reshaped), and the two sections parse against the right one.
P2: Render empty resolved variables as empty in preview
The preview template `{seg.resolved || `{${seg.name}}`}` treated
legit empty substitutions as falsy and fell through to the raw
token, so a known variable that legitimately resolves to `""` at
runtime (e.g. {plan} with no plan, or any item variable in a
collection-scope action) was displayed as if the token would be
copied literally. That's the opposite of what runtime actually
does.
Fix: when seg.resolved === '', render an italic muted "(empty)"
pill with a tooltip explaining the variable resolves to an empty
string. Non-empty resolutions render unchanged. This surfaces the
emptiness to the user without lying about what gets copied.
Both fixes pair with the scope-aware context change — collection-
scope previews now correctly show all item variables as "(empty)"
instead of rich values, matching runtime output exactly.
* fix(web): drop template quick_actions from spread so user can clear them
Codex P2 (PR #139): the Create modal merged `selectedSettings` into
the final settings object and only wrote `quick_actions` when
`savedActions.length > 0`. After picking a template with pre-shipped
quick actions, a user who deleted every quick-action row would still
end up saving the template's original quick_actions because they were
re-introduced by `...selectedSettings`. "Remove all quick actions"
was effectively impossible for templates that defined them.
Fix: destructure `quick_actions` out of `selectedSettings` before the
spread, leaving only the non-action template fields (default_view,
board_group_by, etc.) to be merged. `quickActions` state is already
the single source of truth for quick actions — it's populated from
the template on pick and then edited by the user — so the spread no
longer needs to contribute them. This makes `savedActions` ← the
in-editor list authoritative, including when it's empty.
|
||
|
xarmian
|
6d5fa969e2 |
feat(web): visual redesign pass across collection modals (#138)
Closes TASK-598 in PLAN-593. Applies the design doc recorded on the task before implementation. The work: 1. Field card alignment (resolves the T2 regression) Key row moved out of the header flex into a full-width block below. Header is now baseline-aligned at a consistent height: drag handle, label input, type-select, remove button all sit on one row regardless of whether a key row is present. Label-and- key feel related without being cramped. 2. Emoji picker parity Both modals' General tabs now render EmojiPickerButton (size md) next to the name input, matching the Quick Actions pattern. The inline .icon-btn + <EmojiPicker> dance, its showEmojiPicker state, and all supporting CSS are deleted. 3. Danger zone Archive moved out of the footer into a dedicated "Danger zone" section at the bottom of the General tab. Red-tinted background, red section header, red destructive button that fills on hover. Confirmation flow lives inside the section (not crammed into the footer). Footer is now Cancel + Save Changes only. 4. Empty states Fields empty state gets icon + title + description (not a bare string). Quick Actions empty states explain what item / collection actions are for, inside a dashed-bordered suggestion block. 5. Template picker Blank card shares the same structure as other templates — a muted circular + icon wrapper instead of a dashed outline. All cards have a consistent min-height so Blank doesn't look stubby. Added :focus-visible outline for keyboard users. 6. Typography rhythm Section labels normalized to the app convention: 0.75em, 600, uppercase, 0.05em tracking, --text-muted. Applied to .fields-label, .form-label, .actions-section-title. 7. Responsive Both modals: 16px overlay padding, scrollable content, full- width under 640px. Edit modal tab bar scrolls horizontally with a right-edge fade mask under 640px; settings grid collapses to one column; footer buttons fill width. 8. Motion Modal fade + subtle scale-in (160ms ease-out). Respects prefers-reduced-motion. Existing tab/chevron transitions kept. Out of scope (per plan): new features (T6), backend changes, schema shape changes. |
||
|
xarmian
|
26d124f19d |
feat(web): allow terminal toggle on any select/multi_select field (TASK-597) (#137)
* feat(web): allow terminal-option toggle on any select/multi_select field
Closes TASK-597 in PLAN-593 (scope A — UI + persistence).
FieldEditor previously gated the "Done?" column and per-option
terminal toggle on field.key === 'status', matching the pre-T4
behavior exactly. This commit lifts that gate so any select or
multi_select field with at least one option exposes the toggle, and
updates all three save paths (CreateCollectionModal, Edit addedFields,
Edit existingFields) to persist terminal_options for any
select-typed field instead of only status.
Changes
- FieldEditor.svelte: showsTerminalColumn now derives from
isSelectType && options.length > 0. Removed the inner
{#if field.key === 'status'} around both the option-done-toggle
button and the option-terminal class:directive. Extended the
column-header title to explain what terminal means (dashboard
filtering, progress bars, changelog) instead of the prior
status-specific wording.
- CreateCollectionModal / EditCollectionModal save paths: replace
the key === 'status' gate with a select/multi_select type check.
Stale terminal values are still filtered to the saved options set
so renames/removals don't leave orphan terminal pointers.
Scope note: the backend's done-detection (dashboards, progress
bars, search filters, changelog) remains status-centric. Marking
terminal options on a non-status field persists the schema but
doesn't yet affect aggregation — that architectural change is
tracked separately in TASK-604 (follow-up). This scope-A ship
satisfies PLAN-593's "surface, don't hide" principle by making the
UI match the data model without coupling it to the bigger backend
refactor.
Manual smoke test
- Create a "resolution" select field; mark fixed/wontfix/duplicate
as terminal; save. Reopen collection — terminal markings round
trip correctly.
- Existing status field behavior unchanged: terminal toggles still
render, apply, and persist.
* fix(web): align terminal tooltip with status-only backend semantics
Codex P2 (PR #137): the prior tooltip claimed terminal options on
any select field drive dashboard filtering / progress bars /
changelog, but the backend still only reads terminal_options from
the status field (internal/models/terminal.go,
TerminalStatusesFromSchema). That copy misled users into making
configurations that silently do nothing.
Rewrite the tooltip to be honest about current semantics: only the
status field drives aggregation today; markings on other fields are
persisted on the schema for API consumers and for the future
cross-field done-detection work tracked in TASK-604.
|
||
|
xarmian
|
3463c83bf7 |
feat(web): contextual browser-tab titles (IDEA-592) (#136)
* feat(web): add page title store and wire root layout (TASK-602)
Foundation for contextual browser-tab titles (IDEA-592 / PLAN-601).
Introduces a centralized rune store at web/src/lib/stores/title.svelte.ts
that composes titles as `{item|section} · {workspace} · Pad` with the most
specific label first (browsers truncate from the right). The root layout's
<svelte:head> renders `<title>{titleStore.title}</title>` reactively.
The store exposes `setPageTitle({ workspace?, section?, item? })` with
per-key merge semantics: omitted keys preserve, `null` clears, strings set.
This lets a layout set the workspace once while leaf pages contribute only
their own section or item ref without clobbering context.
With no route wired yet (TASK-603), all pages continue to render `Pad` —
identical behavior to before, now served via the store.
OG meta tags are unchanged on purpose; this only affects the browser tab.
* feat(web): wire contextual titles for big-four routes (TASK-603)
Completes contextual browser-tab titles for IDEA-592 / PLAN-601.
Each workspace-area route now calls `titleStore.setPageTitle(...)` from
a `$effect` to contribute its slice of context:
- `[username]/[workspace]/+layout.svelte` — sets `workspace` from
`workspaceStore.current?.name`; clears on destroy so leaving the
workspace area resets the tab to bare `Pad`.
- `[username]/[workspace]/+page.svelte` (workspace home) — clears
section/item so only the layout-owned workspace name shows.
- `[username]/[workspace]/[collection]/+page.svelte` — section from
the loaded collection's display name.
- `[username]/[workspace]/[collection]/[slug]/+page.svelte` — item
from `formatItemRef(item)` (e.g. `IDEA-592`); section cleared so
the format reads `{REF} · {Workspace} · Pad` (the ref prefix
already encodes the collection).
- `[username]/[workspace]/activity/+page.svelte` — static section
`Activity`; removes the old ad-hoc `<svelte:head><title>` block
that conflicted with the store-driven root <title>.
Results:
- `/` → `Pad`
- `/{user}/{ws}` → `{Workspace} · Pad`
- `/{user}/{ws}/{collection}` → `{Collection} · {Workspace} · Pad`
- `/{user}/{ws}/{collection}/{ref}` → `{REF} · {Workspace} · Pad`
- `/{user}/{ws}/activity` → `Activity · {Workspace} · Pad`
Niche routes (settings, roles, console, billing) are unchanged and
continue to fall back to `Pad` — they can migrate to the store
incrementally.
* fix(web): clear stale title parts on route change in workspace layout
Addresses Codex P1 on PR #136: `setPageTitle` preserves omitted keys by
design, so navigating from a wired route (item detail, collection list,
activity) to an unwired route (settings, roles, dashboard, library,
playbooks, conventions) left the previous section/item in the tab title.
The workspace layout's title effect now reads `page.url.pathname` so it
re-runs on every SPA navigation and clears `section`/`item` alongside
the `workspace` set. Leaf pages that want to contribute their own parts
continue to do so in their own `$effect`s, which run after this one per
Svelte 5's parent-before-child effect ordering. Unwired routes inherit
the cleared state and correctly fall back to `{Workspace} · Pad`.
* fix(web): re-run activity title effect on pathname change
Addresses Codex P2 on PR #136. The activity page's title `$effect` set
`section: 'Activity'` with no reactive dependencies, so it only fired on
first mount. Because SvelteKit reuses the page component when navigating
between `/{user}/{ws1}/activity` and `/{user}/{ws2}/activity`, and the
workspace layout now clears `section` on every pathname change, the tab
title dropped to `{Workspace} · Pad` after cross-workspace navigation
until a full remount.
Reading `page.url.pathname` at the top of the effect gives it a dep that
changes on every SPA navigation, so the activity section is re-asserted
after the layout's clear.
The other wired leaf pages (workspace home, collection list, item detail)
are not affected: the home page sets only nulls (matches the layout's
clear), and the collection/item effects already depend on reactive state
(`collection?.name`, `formatItemRef(item)`) that gets refreshed on
navigation.
* fix(web): split workspace-name sync from section/item clear in layout
Addresses Codex P1 on PR #136 (third round). The previous combined
effect in the workspace layout depended on both `page.url.pathname` and
`workspaceStore.current?.name`, so every async resolution of the
workspace name would clear `section`/`item` in addition to updating
`workspace`. If a leaf page (e.g. activity) had already set its section
before the workspace resolved, the layout's rerun would wipe it.
Splitting the single effect into two:
1. Workspace-name sync — depends only on `workspaceStore.current`. Only
touches the `workspace` slot. Safe to fire asynchronously after the
leaf has set its context.
2. Route-change clear — depends only on `page.url.pathname`. Fires
exactly once per SPA navigation, clearing `section`/`item`. Leaf
`$effect`s run after (parent-before-child ordering) and re-assert
their parts.
Unwired routes still correctly fall back to `{Workspace} · Pad`, and
the activity page retains `Activity · {Workspace} · Pad` after the
workspace-name resolution.
|
||
|
xarmian
|
5f7b7af50f |
feat(web): surface required/default/suffix/relation field controls (TASK-596) (#135)
* feat(web): surface required/default/suffix/relation field controls
Closes TASK-596 in PLAN-593.
Expose field capabilities that already round-tripped through
EditableField but had no UI. Controls live in a collapsible Advanced
section on each field card.
FieldEditor
- New exported CollectionOption type for the relation picker input.
- Advanced section (collapsed by default, auto-expanded when any of
required/default/suffix/collection is already set) containing:
* Required checkbox (all types)
* Default value — type-appropriate input:
text/url -> text input
number -> number input (+ Suffix row below it)
date -> date picker
checkbox -> "Checked by default" toggle
select -> dropdown restricted to the field's options
multi_select / relation -> deliberately skipped
* Relates to dropdown (relation type only), populated from the
workspace collections list passed in via props. Shows a helpful
empty-state when no other collections exist.
- Computed fields render a muted "computed" badge and the advanced
inputs are disabled (changing defaults / suffix / required on a
computed field is nonsensical). Label / type / remove remain
editable to preserve current behavior.
- Typed input handlers coerce field.default into the right shape
(string / number / boolean) so the polymorphic value stays clean.
CreateCollectionModal + EditCollectionModal
- Both fetch api.collections.list(ws) lazily on open and pass the
result down to every FieldEditor as `collections`.
- Both new-field save paths now emit required / computed / suffix /
collection / default onto the serialized FieldDef. Existing-field
save path in EditCollectionModal already handled these; this brings
the new-field path to parity and adds equivalent handling in the
Create modal.
Behavior notes
- Values round-trip: set in Advanced -> save -> reopen -> still there.
- Emit-when-set keeps payloads compact and compatible with existing
schemas that don't carry these fields.
- Known visual quirk: the taller card may exacerbate the type-select
alignment already tracked on TASK-598; deferred to the visual pass.
* fix(web): gate advanced field properties by current field type
Codex P2 (PR #135): the save paths emitted `suffix`, `collection`,
and `default` for every new field regardless of f.type, so a user
could set a number default/suffix, switch the field to `relation` or
`multi_select`, and still persist the hidden value — producing schema
defaults that don't match the final type and are then auto-applied
to new items by ValidateFields.
Fix: gate type-specific advanced-value emission by the current type
at save time. This keeps the user's in-memory state intact (no
surprise clears on type toggle) but prevents stale values from
leaking into the saved schema.
- suffix: only when type === 'number'
- collection (relation target): only when type === 'relation'
- default: only when typeSupportsDefault(type) returns true
Apply the gating in all three save paths:
- CreateCollectionModal.handleCreate (new fields)
- EditCollectionModal.handleSave addedFields (new fields)
- EditCollectionModal.handleSave updatedExisting (existing fields) —
same pre-existing risk if the user changes an existing field's
type and hits save
Extract the default-support check into typeSupportsDefault() in
field-editor-types.ts so FieldEditor (which gates the rendered
default input) and the save paths share one predicate. Adjust
FieldEditor's local `supportsDefault` derived to call through it.
* fix(web): coerce and normalize default values at save time
Two related Codex findings on PR #135:
P1: Coerce default values to active field type before save
Type-switch drift — user sets a boolean default on a checkbox, then
switches the type to `text`, the stale boolean was previously
serialized as the text default. ValidateFields later auto-applies
it to new items without re-validating the value type.
P2: Trim select defaults to match normalized option values
Option text is trimmed on save ("open " -> "open"), but the select
default handler stored raw option text, producing schemas with
`options:["open"]` + `default:"open "` — defaults that aren't in
the allowed set and get auto-injected as invalid values.
Fix: add coerceDefault(raw, type, options?) to field-editor-types.ts.
Returns undefined when the raw value can't be represented in the
target type (caller drops it). Handles:
- text/url -> must be a non-empty string
- number -> number, or parseable non-empty numeric string
- date -> non-empty string (server validates format)
- checkbox -> must be boolean
- select -> trimmed string that exists in normalized options
Wire through all three save paths:
- CreateCollectionModal.handleCreate (new fields)
- EditCollectionModal.handleSave addedFields (new fields)
- EditCollectionModal.handleSave updatedExisting (existing fields,
where the same type-switch risk applies)
The select-options branch passes the already-normalized `def.options`
into coerceDefault so whitespace drift is caught in the same step as
type coercion.
* fix(web): tighten date coercion, preserve opaque defaults, stable keys
Three Codex findings on PR #135:
P1: Validate date defaults before persisting them
coerceDefault was accepting any non-empty string for the date type,
so switching a field from text/select to date could serialize stale
garbage like "soon" as the date default even though the date input
renders blank. Tighten the date branch to require ISO 8601 format
(YYYY-MM-DD, optionally followed by a T-prefixed datetime tail).
Server still performs stricter parsing; this guard blocks obvious
invalid strings from leaking through.
P1: Preserve unsupported field defaults during edit saves
The existing-fields save path dropped `default` whenever
typeSupportsDefault(f.type) returned false. Opening and saving a
collection that contained a multi_select or relation default (e.g.
from an API import) would silently strip those defaults as a side
effect of unrelated edits — schema-mutating regression.
Fix: in the existing-fields branch, if the active type isn't UI-
editable for defaults, pass field.default through verbatim instead
of dropping it. Types that *are* UI-editable still run through
coerceDefault. New-field paths are unchanged because new fields
never carry a pre-existing opaque default.
P2: Use stable unique keys for select default options
The default-value dropdown for select fields keyed its <option>s by
text, but duplicate option labels aren't prevented anywhere in the
editor or save path. A collection with duplicate options would hit
Svelte's keyed-each duplicate-key behavior and break the control.
Switch to keying by index for display stability.
* fix(web): clear stale relation options before async reload
Codex P2 (PR #135): loadCollectionOptions() awaited the fetch before
replacing collectionOptions, so a reopened modal — especially after
a workspace switch — briefly showed the previous workspace's
relation targets. A fast user could pick one and persist a slug that
doesn't exist in the current workspace.
Fix: clear collectionOptions = [] synchronously at the start of
loadCollectionOptions(), before awaiting the request. If the fetch
fails the picker falls back to its empty-state hint. Applied in both
CreateCollectionModal and EditCollectionModal.
* fix(web): token-guard collection fetch + checkbox default clear
Two Codex findings on PR #135:
P2: Ignore stale collection-list responses before setting options
The previous fix cleared collectionOptions at fetch start but still
unconditionally applied whichever response resolved last. Rapid
reopens or slow networks could let an older response land after a
newer one and overwrite it, letting a user persist a relation slug
from the wrong workspace.
Fix: add a monotonic collectionsRequestToken in both modals. Bump it
on each fetch, capture the current value, and drop the response if
the token has moved on when it resolves. Applied in both success
and error paths.
P2: Allow clearing checkbox defaults instead of forcing false
The checkbox default was tri-state at the schema level (no default
/ default false / default true) but the UI only toggled between
true and false. Unchecking stored `false`, and there was no way to
get back to `undefined` — so ValidateFields would auto-inject
`false` into new items even when the user meant "no default".
Fix: add an explicit "Clear" affordance next to the checkbox that
shows only when field.default is set. Clears to undefined, leaving
schema with no default for that field. Preserves the intentional
`false` case (user wants new items to default to unchecked).
* fix(web): calendar-validate date defaults instead of regex shape only
Codex P2 (PR #135): the date branch of coerceDefault accepted any
string matching the YYYY-MM-DD shape, so impossible dates like
"2026-99-99" or "2026-01-32" could be persisted when users switched
a field from text/select to date. ValidateFields later auto-applies
these as defaults on new items without re-checking, propagating
invalid dates silently.
Replace the shape-only regex with real calendar validation:
- Plain date branch (YYYY-MM-DD): parse month/day, then round-trip
through Date.UTC and verify the resulting year/month/day match
the input. Rejects out-of-range components (month > 12) and
overflow cases (day 32 rolling to next month).
- RFC3339 datetime branch: keep the shape check (stricter than a
loose `T.+` suffix — rejects "2026-01-01Tnot-a-time"), then confirm
Date.parse yields a finite timestamp.
Both branches return undefined on rejection so the caller drops the
default rather than persisting garbage.
* fix(web): strict datetime coercion + drop select defaults w/ empty opts
Two follow-up Codex findings on PR #135:
P1: Reject non-RFC3339 datetime defaults in coercion
Previous fix did shape + Date.parse, but `new Date(...)` silently
rolls calendar-invalid dates (e.g. "2026-02-31T10:00:00Z" becomes
March 3) so impossible timestamps still passed. Switch the datetime
branch to the same component-parse + round-trip technique as the
YYYY-MM-DD branch:
- Extract Y/M/D + h/m[/s] from the regex capture groups
- Range-check each component (month 1–12, day 1–31, h ≤ 23, m/s ≤ 59)
- Construct a UTC Date from Y/M/D and verify the resulting
components match the input to catch day overflow
Date.parse is no longer trusted alone. Out-of-range days,
impossible calendar dates, and non-RFC3339 strings are all dropped.
P2: Drop select defaults when normalized options are empty
The save paths passed `def.options` into coerceDefault, but
`def.options` is omitted when the normalized list is empty, so a
select field with no options would skip the membership check and
keep a stale string default. ValidateFields would then auto-apply
a default that doesn't exist in any allowed set.
Fix: in all three save paths, pass the already-normalized opts
array (including []) to coerceDefault when the type is select.
Non-select types continue to pass undefined since they don't
consult the options parameter.
- CreateCollectionModal: use the local `opts` variable
- EditCollectionModal addedFields: use the local `opts` variable
- EditCollectionModal updatedExisting: extract a
`normalizedOpts` local (options were previously inlined) and
reuse it for both def.options and the coerceDefault call
* fix(web): drop stale default on type switch to multi_select/relation
Two Codex findings on PR #135:
P1: Drop stale default when existing field switches to relation/multi_select
The existing-fields save path preserved f.default verbatim for every
UI-unsupported type. That's correct when the field was loaded with a
pre-existing opaque default (API/import). But it misfires when the
user sets a default while the field is text/number/select and then
switches the type to relation or multi_select — the default UI
hides, but the stale value persists and gets saved.
Fix: track the load-time type as `originalType` on EditableField and
only fall through to the verbatim-preserve branch when the active
type still matches the original. In-session type switches to a
UI-unsupported type now drop the default instead. New-field paths
don't need this because new fields never carry pre-existing
opaque defaults.
P2: Enforce strict RFC3339 datetime shape in default coercion
The previous datetime regex accepted optional timezone and
offsets without the colon, so "2026-01-01T10:00" and
"2026-01-01T10:00+0100" round-tripped as defaults even though the
backend's time.RFC3339 parser requires seconds + a colon in the
offset. That lets defaults survive here that the server rejects.
Fix: require seconds, require timezone, require colon in offset.
Matches strict RFC3339 / Go time.RFC3339.
* fix(web): validate RFC3339 timezone offsets in date coercion
Codex P2 (PR #135): the datetime regex enforced the `±hh:mm` shape
but never validated the numeric ranges of the offset, so values like
"2026-01-01T10:00:00+99:99" were treated as valid and serialized.
Go's time.RFC3339 (backend parser) rejects those, and defaults are
auto-applied to new items without re-validation, so an invalid
offset would silently propagate.
Add explicit offset bounds: hours 0–23, minutes 0–59 (matching Go's
time.RFC3339 acceptance of ±23:59). `Z` skips the check. Applied
after the regex match in the datetime branch.
* fix(web): raw string number default + defaults-equal type switch check
Two Codex findings on PR #135:
P2: Preserve raw number input until commit
The number-default input called Number(v) on every oninput and
wrote the coerced value back to field.default. Because the input
was controlled by `value={defaultAsString}`, partial typing states
like "1." collapsed to "1" on each keystroke (Number("1.") === 1),
making it impossible to type decimals. Negative signs had the same
problem.
Fix: keep the raw string in field.default while editing.
coerceDefault already handles string→number conversion at save
time and drops garbage strings, so no save-path change is needed.
P2: Track any type switch before preserving hidden defaults
The existing-fields unsupported-type fallback preserved f.default
whenever the active type matched originalType. That missed the
round-trip case: relation → text → relation with a new default
injected in the middle. Type matches at save but the default is
stale and un-editable through the UI.
Fix: snapshot originalDefault at load alongside originalType, and
only preserve the default when BOTH are unchanged. Otherwise drop.
Add defaultsEqual() helper to field-editor-types.ts for
polymorphic comparison (JSON-stringify-based — fine for schema
defaults, which are always JSON primitives/arrays).
* fix(web): truncate datetime defaults to YYYY-MM-DD for date input binding
Codex P2 (PR #135): <input type="date"> only accepts a YYYY-MM-DD
value. An RFC3339 datetime default like "2026-01-01T10:00:00Z" was
bound directly via defaultAsString and rendered blank, leading users
to believe the field had no default — while field.default remained
populated and was preserved on save through coerceDefault. Result:
hidden datetime defaults that silently survived unrelated edits.
Fix: derive a display-only dateDefaultDisplay string that truncates
anything after the YYYY-MM-DD prefix, and bind the date input to
that. field.default itself stays untouched until the user actually
picks a new date, at which point onDefaultDateInput writes the pure
YYYY-MM-DD value. This keeps API-loaded datetime defaults round-
tripping untouched (when the user doesn't edit them) while making
them visible for manual correction.
|
||
|
xarmian
|
c9f16a04ea |
feat(web): key/label split + slugification in collection modals (TASK-595) (#134)
* feat(web): add key/label split + slugification to collection modals
Closes TASK-595 in PLAN-593.
Replace the Create modal's stripped-down row form with the shared
FieldEditor component from TASK-594 and introduce a proper key/label
split with auto-slugification, duplicate detection, and reserved-key
validation.
New UI
- FieldEditor shows a muted monospace Key input under the Label input
for new (unsaved) fields only. The key auto-syncs from the label
via slugify(). Once the user edits the key manually (keyTouched),
auto-sync stops and an inline hint explains that keys are immutable
after save.
- Inline error message + red outline on the key input when the key is
invalid or collides with another field. Create/Save buttons are
disabled (with a reason tooltip) while any field has a blocking
error.
Shared helpers in field-editor-types.ts
- slugifyKey(): lowercase, strip non-[a-z0-9_\s-], collapse whitespace
and hyphens to underscores, trim, max 40 chars.
- RESERVED_FIELD_KEYS: UI-side reserved list mirroring top-level Item
JSON fields (id, slug, ref, title, content, created_at, etc.) that
would shadow core item properties and cause confusion.
- validateFieldKey(): structural validation (non-empty, starts with a
letter, only lowercase+digits+underscore, not reserved, length).
- fieldFromDef(): hydrate an EditableField from a FieldDef preserving
the key verbatim — used when loading templates or existing fields
so slugify doesn't overwrite already-valid keys.
CreateCollectionModal
- Drops the { key, type, options: string } row form.
- Now renders fields via FieldEditor bound to EditableField[].
- Template selection marks loaded fields keyTouched=true so template
keys stay intact. Duplicate / reserved / empty keys disable Create
with a hover tooltip reason.
- Save uses field.key directly (no longer derives key from label at
submit time).
EditCollectionModal
- New fields gain the same key/label split + validation. Duplicate
detection runs against existing field keys + other new-field keys.
- hasNewFieldBlockingErrors gates the Save button with a tooltip.
- Existing-field behavior is unchanged: label editable, key frozen,
no key row rendered.
Behavior / regression notes
- User-visible outcome for a typed-and-submitted collection is now:
label "Target Date" -> key "target_date" (was "Target Date" in
pre-T2 behavior). This is the intended fix.
- Templates continue to ship with their existing keys verbatim.
- Alignment of the type dropdown against the taller new-field card
will be revisited in TASK-598 (visual redesign pass).
* fix(web): persist terminal_options on newly-created status fields
Codex P2 (PR #134): the Create modal and EditCollectionModal's new-
fields serialization paths copied key/label/type/options into FieldDef
but not terminal_options. Users could toggle terminal markings on a
status field in the FieldEditor, click Create (or Save), and have
those choices silently dropped — making terminal-dependent behavior
fall back to defaults and misclassify statuses.
Mirror the existing-fields branch that already handles this in
EditCollectionModal: when the field key is "status" and terminalOptions
is non-empty, filter to the options that survived in the saved set and
write them to def.terminal_options.
Key === "status" gating matches the current FieldEditor UI. T4
(TASK-597) will generalize terminal options to any select field and
the gate can be removed there.
|
||
|
xarmian
|
ecea75dcd8 |
refactor(web): extract shared FieldEditor component (#133)
Pull the field-card UI out of EditCollectionModal into a reusable FieldEditor.svelte so existing and new fields render identically. Foundation for PLAN-593 (Collection Modal Redesign, TASK-594). - Add FieldEditor.svelte with its own scoped styles for the field card, reorder buttons, select/multi_select options editor, and status-field terminal toggle. - Add field-editor-types.ts with the shared EditableField interface, FIELD_TYPES list, and a blankField() factory. - EditCollectionModal adopts FieldEditor for both existing and new (unsaved) fields, replacing the stripped-down comma-separated row form. - Merge the two field lists into one visual container so new fields flow continuously with existing ones; drop the horizontal divider. - New fields gain reorder buttons within the new-fields list as a natural consequence of the unification. - Save logic, migration building, and status-terminal behavior are preserved exactly. Key-from-label derivation for new fields now reads from 'label' (was 'key'), maintaining identical user-visible behavior until TASK-595 introduces slugification. |
||
|
xarmian
|
fed2766424 |
Merge pull request #132 from xarmian/fix/open-bugs-batch-585-586-588-589-590
fix: resolve five open bugs (BUG-585, 586, 588, 589, 590) |
||
|
xarmian
|
be0ae3d8f5 |
Revert "fix: accept password confirmation at unlink for unupgraded users"
This reverts commit
|
||
|
xarmian
|
c94fc8dd6b |
fix: accept password confirmation at unlink for unupgraded users
BUG-588 follow-up: users who signed up with email/password and later linked a single OAuth provider are backfilled as password_set=false (because the backfill only flags users with no OAuth linked), and if they're currently logged in via OAuth they can't complete the ValidatePassword path that would flip the bit. They remain blocked from unlinking that only provider. Accept an optional password in the /auth/oauth-unlink request body. When the user has no other sign-in method and password_set is still false, the handler verifies the supplied password via ValidatePassword (which also upgrades password_set on success) and then allows the unlink. No password supplied → same "cannot unlink your only sign-in method" error as before, with a slightly more actionable message. |
||
|
xarmian
|
311067ade1 |
fix: fall through to legacy title lookup when ref-shaped key misses
A body like `[[ISO-9001]]` or `[[BUG1-5]]` matches REF_PATTERN but may legitimately be a pre-existing title-based wiki-link (the ref format is just PREFIX-NUMBER, which overlaps with plausible real titles). The previous commit returned the raw match immediately on a failed ref lookup, effectively dropping any ref-shaped legacy titles. Change the ref branch to fall through to the legacy title / collection matching paths when no item ref matches. Canonical `[[BUG-585]]` → BUG-586 still resolves correctly because the ref branch wins whenever the ref exists; only the miss case now continues searching. |
||
|
xarmian
|
a4496849dc |
fix: prioritize REF lookup over full-body title match
Codex flagged a precedence inversion: the earlier full-body-first checks ran before REF_PATTERN, so a canonical ref link like `[[BUG-585]]` would silently retarget onto a user item whose title happened to match the ref literal (case-insensitive). Ref storage is now our canonical form via markdownToWikiLinks, so this path must be deterministic. Restructure the resolver so ref lookup is always checked first. The legacy full-body title / collection-qualified title checks only run on bodies that actually need them — i.e. when the body contains a pipe (which is the only condition that motivated the full-body check in the first place: recovering pre-existing "[[A|B]]" / "[[coll/A|B]]" titles). |
||
|
xarmian
|
922cb26e1d |
fix: preserve legacy [[coll/Title]] links whose titles contain |
Follow-up to the previous commit: the full-body title lookup handled the plain-title case, but collection-qualified legacy links like `[[tasks/A|B]]` (where the item's real title is "A|B" in "tasks") were still split on the pipe before the collection/title resolution ran, so the lookup was attempted for title "A" and the link rendered as plain text. Add a full-body collection-qualified lookup alongside the full-body title lookup, both before the `key|display` split. |
||
|
xarmian
|
de21b1199d |
fix: preserve legacy [[Title]] links whose titles contain |
Codex flagged a behavioral regression in `wikiLinksToMarkdown`: splitting the wiki body on the first unescaped `|` unconditionally meant a legacy link like `[[A|B]]` — where the item's actual title is literally `A|B` — would be parsed as `key=A, display=B`, fail to resolve, and render as plain text. Fix by attempting an exact full-body title match (with `|` intact) before falling through to the `key|display` split. This keeps the new ref-based forms (`[[REF]]`, `[[REF|Display]]`) working while recovering pre-existing content whose titles were never escape-encoded. |
||
|
xarmian
|
d1a5ea3975 |
fix: robust wiki-link round-trip and navigable popover (BUG-586 follow-ups)
Follow-up to the BUG-586 fix that surfaced several edge cases under
real-world use. Covers three related improvements to the wiki-link
experience in the editor.
Reference-based wiki-link storage
Previously `[Title](/url)` round-tripped to `[[Title]]`. That form
broke for titles containing `[`, `]`, `/`, or `|`. Storage now uses
the item's opaque ref (e.g. `[[BUG-586]]`, or `[[BUG-586|Custom]]`
when the visible text differs from the item's current title).
`wikiLinksToMarkdown` accepts three forms in preference order:
ref-only, ref-with-display-override, and legacy title lookup.
Titles can now contain any characters and links survive renames.
Escape-aware parsing
Both `markdownToWikiLinks` and `wikiLinksToMarkdown` now recognize
`\.` escape sequences inside their capture groups. tiptap-markdown
emits `\[`, `\]`, `\\` in link text when the text contains literal
brackets, so the prior regexes (`[^\]]+`) terminated prematurely and
missed valid links. Helper functions escape/unescape the markdown
link-text layer and the wiki-link body layer separately so `]`, `|`,
and `\` can appear in display-override text.
Leave unresolved [[X]] untouched
The `[[…]]` regex is greedy and can match spans that were never
intended as wiki-links — notably `[[` sequences inside another
markdown link's text. On miss, the function now returns the original
match verbatim instead of emitting `[…](broken)`, which previously
hijacked surrounding content and accumulated corruption on each
save cycle. Broken items heal themselves on the next auto-save.
Picker: show ref + align URL with the route
The `[[` picker now lists the ref badge next to the title and keys
`{#each}` by `doc.id` so duplicate titles don't collide. `execLink`
now reads `page.params.username`/`page.params.workspace` from the
live route (previously `workspaceStore.current`, which could be
empty), so the inserted `href` matches the URL shape that the
round-trip expects.
Clickable link popover
The popover's URL label is now a real `<a href="…">`. Plain click →
`goto()` for internal paths, full navigation for external. Ctrl /
Cmd / middle-click pass through to the browser so "new tab" and
"copy link" work naturally. `onmousedown.stopPropagation` keeps the
outer popover's focus-trap from swallowing the click.
|
||
|
xarmian
|
e328844a1b |
fix: resolve five open bugs (BUG-585, BUG-586, BUG-588, BUG-589, BUG-590)
BUG-585 — Code-block copy no longer includes ``` fences
Editor.svelte: ProseMirror plugin overrides copy/cut when the selection
is inside a code_block node and writes raw textBetween to the clipboard.
NodeView for non-mermaid code blocks now shows a hover "Copy" button that
uses the existing copyToClipboard() util (with execCommand fallback).
BUG-586 — Wiki-link picker matches on item ref
Editor.svelte: getFilteredLinks() now also matches formatItemRef(item),
so typing [[DOC-535]] finds items by their issue ID. Picker dropdown
shows the ref as a badge; {#each} key switched to doc.id so duplicate
titles across collections don't collide.
BUG-588 — Can unlink OAuth provider when password is configured
Adds a password_set column to track whether a user has a usable
password vs. the random placeholder hash given to OAuth users.
CreateUser sets it true, UpdateUser sets it true when a password is
provided, and ValidatePassword auto-upgrades it on any successful
email/password login (which transparently upgrades pre-existing users
who linked OAuth after signing up with a real password — the OAuth
placeholder hash cannot match user-supplied plaintext, so this is safe).
handleOAuthUnlink now permits removing the last provider when
user.HasPassword() is true.
BUG-589 — Pre-auth pages render standalone
+layout.svelte: isAuthPage now also matches /forgot-password and
/reset-password/* so those pages don't inherit the authenticated
sidebar/topbar layout.
BUG-590 — Search no longer crashes with null results
store.Search() returned a nil Results slice on no-match queries, which
Go marshals as JSON null; CommandPalette then crashed on results.length.
Backend now normalizes nil to []SearchResult{} before returning.
CommandPalette also coalesces resp.results ?? [] on the initial search
and loadMore paths as belt-and-suspenders hardening.
|
||
|
xarmian
|
e530e5f1ab |
fix: force full navigation for OAuth link buttons (#131)
The "Link GitHub"/"Link Google" buttons on /console/settings and the OAuth sign-in buttons on /login were plain <a href="/auth/..."> tags. SvelteKit intercepted the clicks and did client-side navigation, so the request never hit the nginx router and pad-cloud never saw it. SvelteKit would then try to match /auth/github/link against the [workspace]/[collection] route, 404 on the API calls, and render "Collection not found". Add data-sveltekit-reload so the browser performs a real HTTP navigation and the nginx router can forward /auth/* to the pad-cloud sidecar. |
||
|
xarmian
|
55a779d838 |
fix: load workspaces reactively after post-auth navigation (BUG-584) (#130)
* fix: load workspaces reactively after post-auth navigation (BUG-584)
Root layout only loaded workspaceStore inside onMount, guarded by
!isAuthPage. When a user first lands on /login, onMount skips the load
(isAuthPage is true). After login, goto('/console') does a client-side
navigation — the root layout's onMount does NOT re-run, so the
workspace store stays empty. When the user then opens a workspace,
<TopBar /> renders with a blank workspace list until a hard refresh.
The same failure mode affects register, join, reset-password, and any
other post-auth redirect path, since all of them mount the root layout
on an auth page first.
Fix: replace the onMount-local loadAll() call with a reactive $effect
that fires whenever the user is authenticated, the page is an app page
(not auth/share), and the store hasn't been loaded yet. A
workspacesLoaded latch prevents re-firing for users who legitimately
have zero workspaces.
Also fix a broken template-literal in the mobile header <a href>:
\${workspaceStore.current?.slug} was a JS template-literal in a plain
HTML attribute string, which Svelte renders as a literal '$'. Changed
to Svelte's {...} attribute interpolation.
* fix: drop authStore.authenticated gate from workspace loader effect
Addresses Codex P1 feedback on #130. The onMount auth-check block
intentionally swallows authStore.load() failures with a comment
explaining the server may not support auth. Gating the $effect on
authStore.authenticated therefore regressed the original !isAuthPage
behavior for deployments where /api/v1/auth/session is unavailable:
the effect never fired and the workspace list stayed empty.
Remove that one gate. The onMount flow still redirects unauthenticated
users to /login before authReady flips true, so by the time the effect
runs on an app page we're either authenticated or auth is
unsupported/errored — both cases should load workspaces, matching the
original behavior. Comment updated to document why.
* fix: skip workspace load during logged-out-to-/login redirect window
Addresses second Codex P1 on #130. The previous commit dropped the
authStore.authenticated gate from the workspace loader effect, which
fixed auth-unsupported deployments but introduced a new regression:
authReady is set to true inside the !auth / setup_required /
!auth.authenticated branches of onMount *before* goto('/login')
completes. For a logged-out user who first hits a protected route,
during that window the effect saw authReady=true and isAuthPage=false
(still on the protected URL), fired loadAll() (silently 401), and
latched workspacesLoaded=true — blocking the retry after login.
Gate on (authStore.authenticated || authLoadFailed) where
authLoadFailed is set only in the catch branch. This preserves both
the original backward-compat for auth-unsupported deployments and the
correct skip-during-redirect behavior, without coupling the effect
to the rest of the redirect machinery.
|
||
|
xarmian
|
fb56ada1cd |
fix: align Starred page layout with sibling pages (BUG-579) (#129)
The Starred page used hardcoded layout values (max-width: 800px, asymmetric padding, vertically-stacked header, smaller h1) while every other workspace page uses the shared design tokens. Swap to the canonical pattern from activity/+page.svelte so the page feels consistent with Activity, Conventions, Settings, etc. - max-width: 800px -> var(--content-max-width) (960px) - padding: var(--space-6) var(--space-6) var(--space-12) -> var(--space-8) var(--space-6) - .page-header: flex row with justify-content: space-between - .header-top renamed to .page-header-left; redundant margin-bottom removed - h1 font-size: 1.5em -> 1.6em |
||
|
xarmian
|
bf7901ab29 |
feat: add facet summary to CLI search output (#128)
Show collection breakdown (e.g. "docs: 9, ideas: 8, tasks: 53") after the result count when searching across all collections. Hidden when filtering by a specific collection. |
||
|
xarmian
|
91920c9085 |
feat: add collection-level search with Cmd+F (#127)
* feat: add collection-level search with Cmd+F Intercept Cmd+F / Ctrl+F on collection pages to focus the search input instead of opening browser search. Replace client-side substring filtering with API-backed FTS search scoped to the collection, with 200ms debounce and instant client-side fallback while the API responds. - Cmd+F / Ctrl+F focuses the FilterBar search input - Escape clears search and blurs the input - Search uses /search?collection=<slug> for full-text matching - Client-side filter used as fallback during API debounce - searchResultIds cleared on all filter/view reset paths - FilterBar exposes searchInputEl via $bindable prop * fix: open filters panel on Cmd+F and guard stale search responses - Open filtersOpen panel before focusing search input so it exists in the DOM; use requestAnimationFrame to wait for mount - Snapshot query before async search and discard response if query changed while loading Addresses codex review on PR #127. * fix: route Cmd+F through layout keydown handler via UI store The collection page's svelte:window onkeydown couldn't reliably intercept Cmd+F because the layout already registers the window keydown handler. Move Cmd+F handling to the layout's handler and dispatch via a uiStore.collectionSearchRequested signal that the collection page watches with $effect. * fix: clear stale search IDs immediately on new query Set searchResultIds to null as soon as a new query arrives so the client-side fallback filter kicks in immediately while the API debounce is pending. Previously stale IDs from the prior query would persist during the 200ms gap. Archived filtering and limit concerns are already handled by the existing filteredItems pipeline which applies field/status filters on top of search results. Addresses codex review on PR #127. |
||
|
xarmian
|
9616374a80 |
feat: upgrade CommandPalette with filters, grouping, and pagination (#126)
* feat: upgrade CommandPalette with filters, grouping, and pagination Rewrite the Cmd+K search modal as a full-featured search experience: - Filter chips: collection and status filters from facets, toggle on click - Grouped results: items grouped by collection with section headers - Better result cards: ref, title, priority dot, status badge, relative date - Pagination: "Load more" button appends next page of results - Recent searches: last 10 queries persisted in localStorage - Result count displayed below filter chips * fix: reset loading state on empty query and guard stale loadMore - Clear loading flag when query is emptied so spinner doesn't stick - Capture query/filter snapshot before loadMore API call and discard the response if they changed while loading Addresses codex review on PR #126. |
||
|
xarmian
|
8351b8194f |
feat: add faceted counts to search results (#125)
* feat: add faceted counts to search results Add collection and status faceted counts to SearchResponse so the frontend can show breakdowns like "Tasks (24) · Ideas (4)". Facets reflect the full unpaginated result set via two GROUP BY queries using the same filters as the main search. - Add SearchFacets type with collections and statuses maps - Add searchFacets() method using appendSearchFilters for consistency - Add SearchFacets TypeScript type to frontend - Add TestSearchFacets covering counts and pagination independence * fix: include ref-hit items in facet counts Ref hits (e.g. searching "TASK-42") bypass FTS and wouldn't appear in FTS-based facet aggregation. Merge them into facets after the facet queries run so collection/status counts include all results. Addresses codex review on PR #125. * fix: remove ref-hit facet merge to avoid double-counting Unconditionally adding ref hits to facets overcounts when the item is also found by FTS (the common case). Since we can't cheaply detect overlap, leave facets as FTS-only. Ref searches typically return 1 exact match, so the off-by-one is acceptable. Addresses codex review on PR #125. |
||
|
xarmian
|
3e51bfa541 |
fix: rewrite search ref-hit pagination for correctness (#124)
* fix: rewrite search ref-hit pagination for correctness The previous ref-hit pagination logic had cascading issues: clearing results on offset>0 broke the seen map, total was wrong for ref queries on later pages, and multi-ref hits were dropped entirely. Rewrite the approach: - Save ref hits and their IDs before FTS query runs - Ref hits always appear on page 0; FTS limit reduced accordingly - On pages after 0, ref hits excluded and FTS offset adjusted - Track FTS deduplication to correct total (avoid double-counting) - Total is always >= actual result count as a safety floor - All ORDER BY clauses include i.id tie-breaker for stable pagination Addresses all 6 codex review comments on PR #123. * fix: simplify ref-hit total calculation Remove the refCount add / ftsDeduped subtract dance which was inherently broken across pages. Instead, use a simple floor: total is always at least len(results). The FTS count is accurate for FTS results; ref-only hits (rare) just bump the floor. Addresses codex review on PR #124. |
||
|
xarmian
|
999bd3cfca |
feat: add pagination and sorting to search API (#123)
* feat: add pagination and sorting to search API Extend the search endpoint with limit/offset pagination and sort options. The response now includes total count (from a separate count query) so frontends can paginate properly. - Add Limit, Offset, Sort, Order to SearchParams with Normalize() defaults - Return SearchResponse struct with total/limit/offset metadata - Count query runs alongside results query for accurate totals - Sort options: relevance (default), created_at, updated_at, title - Add --sort, --limit, --offset flags to CLI search command - Update frontend SearchFilters and SearchResponse types - Add TestSearchPagination and TestSearchSorting integration tests * fix: count ref hits in search totals and handle empty pages - Ensure total is never less than actual results when direct ref matches (e.g. "TASK-5") aren't captured by the FTS count query - Handle empty page in CLI output: show "No results on this page" instead of an invalid descending range like "Showing 11-10 of 5" Addresses codex review on PR #123. * fix: paginate ref hits correctly and add sort tie-breaker - Ref hits now occupy slots on page 0 only; FTS limit/offset adjusted so combined results respect the requested pagination contract - On subsequent pages, ref hits are excluded (already shown on page 0) - Add i.id as deterministic tie-breaker to all ORDER BY clauses to prevent duplicate/missing items across paginated pages Addresses codex review on PR #123. |
||
|
xarmian
|
aef0e2326a |
feat: add collection and field filtering to search API (#122)
* feat: add collection and field filtering to search API Extend the /search endpoint to support scoping by collection slug and filtering by structured field values (status, priority, and generic field.* params). Works on both SQLite FTS5 and PostgreSQL tsvector. - Add Collection and FieldFilters to SearchParams (store layer) - Parse collection, status, priority, field.* query params (handler) - Add SearchFilters type and update api.search() signature (frontend) - Add --collection, --status, --priority flags to CLI search command - Add integration tests for collection, field, and combined filtering * fix: validate field filter keys to prevent SQL injection Reject field filter keys containing special characters before they reach JSONExtractText, which interpolates keys directly into SQL. Keys must match ^[a-zA-Z][a-zA-Z0-9_-]*$ — validation is applied in both the handler and the store layer as defense in depth. Addresses codex review on PR #122. |
||
|
xarmian
|
c5183d2a4b |
feat: add SSE events for item star/unstar (#121)
* feat: add SSE events for item star/unstar Emit real-time events for multi-tab sync (PLAN-564, TASK-571): - New event types: item_starred, item_unstarred - Emitted from handleStarItem and handleUnstarItem after success - Includes item ID, title, collection, actor, and source - Follows existing publishItemEventWithName pattern * fix: scope star/unstar SSE events to the acting user Star events are user-specific state, not workspace-wide. Changes: - Add UserID field to Event struct for user-scoped events - SSE handler filters events with UserID, only delivering them to the user who triggered the action (multi-tab sync without leaking star actions to other workspace members) - Star/unstar handlers set UserID when publishing events |
||
|
xarmian
|
9072e49b17 |
feat: add CLI commands for item starring (#120)
Add star/unstar/starred CLI commands (PLAN-564, TASK-570): - pad item star <ref> — star an item - pad item unstar <ref> — unstar an item - pad item starred [--all] [--format json] — list starred items Client methods: StarItem, UnstarItem, ListStarredItems. |
||
|
xarmian
|
f7d93d878d |
feat: add starred items to dashboard (#119)
* feat: add starred items to dashboard Add starred items section to the dashboard (PLAN-564, TASK-569): - Dashboard API: fetches non-terminal starred items for the current user, applies RBAC visibility filtering, returns as starred_items array - TypeScript types: add starred_items to DashboardResponse - Dashboard UI: renders starred items section with card grid, item refs, status pills, and "View all" link to /starred page * fix: cap starred items in dashboard response to 10 Match the same limit applied to active_items, preventing large payloads on the polling dashboard endpoint for users with many starred items. |
||
|
xarmian
|
77d3fe2d72 |
feat: add Starred sidebar entry and starred items page (#118)
* feat: add Starred sidebar entry and starred items page
Add dedicated starred items view (PLAN-564, TASK-568):
- Sidebar: new "⭐ Starred" link below Activity, with active state
- Starred page: shows user's starred items grouped by collection
- "Show completed" toggle to include/exclude terminal status items
- Loading skeleton, empty state with usage instructions
- Excludes "starred" and "roles" from collection slug detection
* fix: reactively remove unstarred items, guard against stale responses
Two fixes for the starred page:
1. Items list is now derived from starredStore.isStarred, so unstarring
an item via the ItemCard toggle immediately removes it from the page
without a refetch.
2. Request sequencing via loadSeq counter prevents stale responses from
overwriting the UI when rapidly toggling "Show completed".
* fix: reserve collection slugs that collide with workspace UI routes
Prevent collections from being created or renamed to slugs that shadow
workspace-level routes (settings, activity, roles, starred, library,
new). If a reserved slug is generated, "-collection" is appended
(e.g. "starred" becomes "starred-collection").
Also fixes starred page: items list is now reactive to unstar actions,
and loadStarred uses request sequencing to prevent stale responses.
* fix: skip store filter on starred page until store is loaded
Trust the API response when starredStore hasn't loaded yet, since
/starred only returns starred items. Apply the reactive filter only
after the store is loaded, so unstar actions still remove items
immediately but initial render isn't broken by async timing.
|
||
|
xarmian
|
5d23791c1d |
feat: add star toggle to web UI item views (#117)
* feat: add star toggle to web UI item views Add per-user item starring to the web UI (PLAN-564, TASK-567): - API client: star(), unstar(), starStatus(), starred() methods - Starred store: loads starred IDs on workspace init, optimistic toggle - ItemCard: star button (☆/★) in top-left, hidden until hover, always visible when starred, amber color - Item detail page: star button in meta-actions header row - Workspace layout: loads starred store on workspace change * fix: guard starred store against stale workspace responses Add a monotonic request counter so that if a user switches workspaces quickly, an older in-flight response won't overwrite the current workspace's starred state. Also guards toggle revert against workspace changes. * fix: merge in-flight toggles with load result in starred store Track toggles that occur while the initial load is in-flight via a pendingToggles map. When the load completes, merge local mutations on top of the server response so optimistic updates aren't overwritten. Reverts also update the pending map for consistency. * fix: preserve toggles on load error, serialize per-item toggles Two fixes for starred store edge cases: 1. Error path now applies pendingToggles instead of resetting to empty, so optimistic toggles survive a failed initial load. 2. Per-item toggle lock (toggleInFlight set) drops rapid duplicate clicks while a toggle API call is in flight, preventing out-of-order requests from producing inconsistent state. * fix: clear stale stars immediately on workspace load Reset starredIds at the start of load() before the async fetch, so a previous user/workspace's stars are never briefly visible during SPA navigation or re-authentication flows. |
||
|
xarmian
|
844e40f0a9 |
feat: add star/unstar API endpoints (#116)
* feat: add star/unstar API endpoints
Add REST API for item starring (PLAN-564, TASK-566):
- POST /workspaces/{ws}/items/{slug}/star — star item (idempotent, 204)
- DELETE /workspaces/{ws}/items/{slug}/star — unstar item (204 or 404)
- GET /workspaces/{ws}/items/{slug}/star — check star status ({"starred": bool})
- GET /workspaces/{ws}/starred — list starred items (?include_terminal=true)
All endpoints are scoped to the authenticated user, check item visibility
via RBAC/grants, and enrich list responses with parent links and refs.
* fix: enforce RBAC visibility filtering on starred items list
Apply the same collection/item grant filtering used by handleListItems
to handleListStarredItems. Without this, guests or restricted members
could see starred items from collections they no longer have access to.
|
||
|
xarmian
|
d372be6aff |
feat: add item_stars table and store methods (#115)
* feat: add item_stars table and store methods for per-user item starring Add the data layer for item starring/favorites (PLAN-564, TASK-565): - Migration 042 (SQLite) / 022 (PostgreSQL): item_stars join table with (user_id, item_id) primary key, ON DELETE CASCADE, and indexes - Store methods: StarItem, UnstarItem, IsItemStarred, AreItemsStarred (batch), ListStarredItems (enriched), CountStarredItems, DeleteStarsForItem - 8 tests covering CRUD, idempotency, per-user isolation, and batch ops * fix: implement includeTerminal filter in ListStarredItems The includeTerminal parameter was accepted but unused — starred items in terminal statuses (done, completed, etc.) were always returned. Now post-filters using IsTerminalStatusDefault, matching the pattern used by GetRoleBoardItems. Adds test coverage for the filter. * fix: use per-collection schemas for terminal filtering, cascade user deletes Addresses two code review findings: 1. Terminal filtering now loads collection schemas and uses IsTerminalStatus per collection instead of IsTerminalStatusDefault. This correctly handles custom terminal statuses (e.g. "closed"). 2. Added ON DELETE CASCADE to the user_id foreign key in both SQLite and PostgreSQL migrations, so deleting a user automatically cleans up their stars. * perf: use lightweight query for collection schema loading Replace ListCollections call in buildCollectionSchemaMap with a direct SELECT of only id and schema columns. ListCollections runs per-collection COUNT(*) queries for ActiveItemCount which are unnecessary here. |
||
|
xarmian
|
6a552b83ae |
fix: link comment to activity record to prevent duplicate timeline entries (#114)
* fix: link comment to activity record to prevent duplicate timeline entries (#BUG-563) When creating a comment, the handler created a comment (activity_id=NULL) and a separate "commented" activity but never linked them. The timeline dedup logic only filters activities that have a linked comment, so both showed up as separate entries. Fix: create the activity first via logActivityWithMetaReturningID, then pass its ID to CreateComment so buildTimeline correctly deduplicates them. * fix: only link activity ID to comment when activity insert succeeds Address review feedback: CreateActivity assigns an ID before Exec and returns it even on insert failure. Since comments.activity_id has a FK constraint, setting a dangling reference would break comment creation. Now we only set ActivityID when the activity was actually persisted. |
||
|
xarmian
|
b620b7e5cc |
feat: add edit button to collection detail page header (#113)
* feat: add edit button to collection detail page header Wire up the existing EditCollectionModal to the collection detail page with a pencil icon button in the header actions bar. Owner-only, responsive (icon-only on mobile), refreshes page data after saves. Closes IDEA-494 * fix: navigate to new slug after collection rename in edit modal When a collection is renamed, the backend regenerates the slug. The onupdated callback now receives the updated Collection object, so the collection page can detect a slug change and navigate to the new URL instead of 404ing on the old slug. Addresses PR review feedback from #113. * fix: refresh collectionStore after edit modal update Ensures the sidebar reflects updated collection name/slug/icon immediately after editing, matching the settings page behavior. Addresses P2 review feedback from #113. |