68 Commits

Author	SHA1	Message	Date
xarmian	0d0c660565	feat(insights): navigate to past periods (offset + prev/next) (TASK-1639) (#649) ... Add an `offset` to the report (periods back; 0 = current, clamped >= 0): window becomes [now - (offset+1)*lookback, now - offset*lookback]. Throughput and cycle-time shift automatically; response echoes `offset` + shifted range. Backend: ReportOptions.Offset + ReportData.offset; handler parses ?offset=. Web: api.report.get passes offset; ReportData.offset typed. Insights page: ◀ Previous / Next ▶ controls (Next disabled at offset 0) + a period label; offset is session-only (not persisted to the layout); resets on window or workspace change. Interim: WIP + status-distribution are hidden when viewing a past period (they're as-of-now) with a note — TASK-1640 reconstructs them historically. Parent: PLAN-1628.	2026-05-29 16:59:37 -04:00
xarmian	eeff78118b	feat(insights): per-user layout customization + persistence (TASK-1634) (#645) ... * feat(insights): per-user layout customization + persistence (TASK-1634) Let users personalize the Insights surface, persisted per-user per-workspace: toggle which metric cards show, and remember the window + collection filter. Backend: - migrations 064/043: user_report_layouts (user_id, workspace_id, config JSON, PK(user_id,workspace_id), ON DELETE CASCADE) — dual-dialect. - models.ReportLayout (hidden_cards/default_window/default_collections) + ReportCardIDs/ValidReportWindow validation. - store.GetReportLayout / SaveReportLayout (ON CONFLICT upsert, both dialects). - GET/PUT /workspaces/{ws}/report/layout — per-user; PUT sanitizes window + filters hidden_cards to the known card set. web client + TS type. Frontend (Insights page): - loads the saved layout, hydrates window/collections/hidden cards - a "Customize" panel toggles each card (SvelteSet-backed); each section gated on !hiddenCards.has(id); Totals always shown - debounced auto-save, gated on a per-workspace `hydrated` flag so it never saves during load or stomps another workspace's layout on switch Single config per user (no named/multiple layouts — deliberate v1 scope). Parent: PLAN-1628. * fix(insights): save layout only on explicit user changes, not on load per Codex review (round 1) The auto-save $effect ran once after hydration (loadLayout assigns reactive state, then flips hydrated=true), firing a PUT /report/layout on mere page view — which 401s on no-user/legacy-token sessions and bounces the user to /login. Replace the effect with a scheduleSave() called only from explicit handlers (toggleCard, selectWindow, toggleCollection, clearCollectionFilter); hydration never saves. Also capture wsSlug at schedule time and drop the pending save if the workspace changes mid-debounce, so A's edit can't land on B.	2026-05-29 15:00:34 -04:00
xarmian	a1d09c90df	feat(report): windowed project report endpoint + DateBucket dialect (TASK-1630) (#638) ... * feat(report): windowed project report endpoint + DateBucket dialect (TASK-1630) GET /workspaces/{ws}/report?window=week&collections=tasks,bugs returns a time-bucketed report: created-vs-completed throughput, net flow, completed-by-collection, and a current status-distribution snapshot. - Dialect.DateBucket(column, granularity) — day/hour bucketing via fixed-width substring on the UTC RFC3339 TEXT (identical + exact on SQLite + Postgres; avoids SQLite 'Z'-parsing fragility). Routes all report date math through it. - store.GetReport: resolves per-collection done field + positive terminals (terminal options minus rejected/cancelled/etc.), counts completions from status_transitions and created from items.created_at, zero-fills buckets. - HTTP handler + route; web ReportData type + api.report.get client. - Tests: throughput/totals, negative-terminal exclusion, status distribution, collection filter, non-status done-field, out-of-window exclusion, hourly day-window, DateBucket per granularity. Dual-dialect via testStore. Fixes the response contract that TASK-1632/1633/1635 consume (noted on them). Parent: PLAN-1628. * fix(report): scope report to caller's visible collections per Codex review (round 1) The endpoint sits under RequireWorkspaceAccess (members, restricted members, guests), but GetReport resolved ALL workspace collections — letting a caller with access to one collection infer hidden collections' slugs, created/ completed counts, and status distribution. Mirror the dashboard: the handler computes visibleCollectionIDs() and GetReport restricts to that set (ScopeToVisible). Empty visible set → empty report. Aggregate reports are a full-collection-visibility feature; item-level grants aren't surfaced in workspace-wide counts. * fix(report): correct visibility scoping for all-access + item-grant callers per Codex review (round 2) Round 1's scoping had two bugs in how it read visibleCollectionIDs: 1. nil means "all-access" (admin / collection_access=all), but the handler treated nil as an empty visible set → all-access users got an EMPTY report. Now nil → ScopeToVisible stays false (full workspace report). 2. For guests, visibleCollectionIDs includes collections visible only via item-level grants; passing those to the aggregate report leaked the whole collection's counts. Now mirror the dashboard: when item-level grants are present, scope to fullCollIDs (full-access collections only). Adds report handler tests (owner full report + default window) alongside the store-level scoping test. * fix(report): bearer-aware admin visibility scoping per Codex review (round 3) visibleCollectionIDs grants ANY platform admin an unrestricted (nil) view, but RequireWorkspaceAccess suppresses the platform-admin bypass for bearer auth and falls through to membership (BUG-1616/1617). So a bearer admin (PAT/CLI/OAuth) who is only a restricted workspace member could read the full workspace report. Extract reportVisibleCollections(): gate the admin bypass on cookie auth; for everyone else resolve actual member/guest visibility, and when item-level grants exist scope to the full-access collection set only. Adds a cookie-vs- bearer scoping test (cookie admin unrestricted, bearer restricted-member scoped to the granted collection, end-to-end through GetReport). * fix(report): exclude soft-deleted items from completion counts per Codex review (round 4) status_transitions rows survive a soft delete (only a HARD delete cascades them), so a completed-then-soft-deleted item still counted toward completed / completed_by_collection while created and status_distribution (which filter deleted_at IS NULL) excluded it — inconsistent totals. Join live items in both completed queries. Adds a regression test.	2026-05-29 08:24:05 -04:00
xarmian	225fb4a53f	Wire upgrade CTAs with Stripe-ready billing flow (TASK-800) (#629) ... * feat(billing): add billing_available session flag gated on PAD_BILLING_AVAILABLE (TASK-800) Add Server.billingAvailable field set by SetBillingAvailable(), called from cmd/pad/main.go when PAD_BILLING_AVAILABLE=true|1. Expose the flag as billing_available in both the setup-state and authenticated session payloads (value: cloudMode && billingAvailable) so the web UI can gate Stripe CTAs without a code change at deploy time. False by default. * feat(billing): wire upgrade CTAs, checkout POST flow, plan section, clickable limit toasts (TASK-800) Frontend prep work gated on authStore.billingAvailable (from billing_available session field). When false, upgrade buttons remain hidden and the "coming soon" note stays in place — flip PAD_BILLING_AVAILABLE=true at deploy time. Changes: - client.ts: add billing_available to AuthSession; add api.billing.createCheckoutSession() (POST /billing/checkout → parse {url} → caller does window.location.href) - auth.svelte.ts: billingAvailable getter - console/billing: replace STRIPE_AVAILABLE=false with $derived(authStore.billingAvailable); fix GET→POST on upgrade buttons; add ?checkout=cancelled banner; add cancelled style - console/settings: new cloud-mode-gated "Plan" section with current plan + upgrade/manage link - All 11 limit-hit sites: replace plain-text '/console/billing' appendage with toastStore.show(msg, 'error', 6000, '/console/billing') so the toast is clickable * docs(billing): document pad-cloud CSRF and error-envelope contract divergences in createCheckoutSession (TASK-800)	2026-05-25 13:18:43 -04:00
xarmian	342679a364	Standardize plan-limit error envelope across HTTP/MCP/CLI/UI (TASK-788) (#628) ... * fix: limit-hit responses were actively broken — garbled toasts, no upgrade signal The limit enforcement responses (plan_limit_exceeded on 403) used a flat body shape {"error": "plan_limit_exceeded", ...} that is incompatible with every consumer: the frontend PadApiError parser, the CLI parseError path, and the MCP classifyHTTPStatusKind all expect {"error": {"code": ..., "message": ...}}. As a result, hitting any of the 5 plan limits (items, members, workspaces, api_tokens, webhooks) produced garbled toasts with undefined message text and zero upgrade signal. Fix: - writePlanLimitError now emits the standard nested error envelope with a human-readable message sentence and limit details in error.details. - CLI parseError now correctly surfacing the message (net positive, no code change needed). - MCP classifyHTTPStatusKind: adds ErrPlanLimitExceeded to the taxonomy and the allowedStructuredErrorCodes whitelist so 403 plan-limit errors pass through with code + details rather than collapsing to ErrPermissionDenied (TASK-788). - Frontend: exports isPlanLimitError() type-guard and planLimitMessage() formatter from client.ts; all 4 limit-hit write call sites (item create, member invite, workspace create, token create) now branch on the code and show an upgrade-signal message pointing at /console/billing. - Test: updates handlers_workspace_cap_test.go to the new body shape; adds TestPlanLimitError_ResponseShape covering members_per_workspace limit hit. TASK-788 * fix(R1): cover MCP stdio path, 5 more item-create sites, polish message wording Finding A — MCP stdio transport was missing plan-limit coverage: - cli/client.go: add PlanLimitDetails struct, AsPlanLimit() helper, and WritePlanLimitError() that emits the pad-structured-error/v1 marker so the MCP stdio classifier can lift code + details instead of falling through to ErrServerError. - cmd/pad/main.go: wire the WritePlanLimitError branch into all three CreateItem call sites (item create, convention activate, playbook activate). - internal/mcp: add TestClassifyHTTPStatus_PlanLimitPreservesCodeAndDetails, TestClassifyHTTPStatus_Generic403FallsToPermissionDenied, TestClassifyExecError_PlanLimitMarkerLiftsStructuredPayload, and TestClassifyExecError_PlanLimitWithoutMarkerFallsThrough. Note: extractUpstreamErrorEnvelope already parses details (json.RawMessage field) — the codex concern about it being silently empty was a false alarm; no fix needed there. Finding B — 5 more item-create entry points were unguarded: - EditorBubbleMenu.svelte (inline wiki-link capture) - Sidebar.svelte (quick-add) - roles/+page.svelte (board new-item, was console.error only; adds toastStore) - conventions/+page.svelte - playbooks/+page.svelte (both create and duplicate paths) B1/B2 polish — server message is now statement-of-fact only, no doubled upgrade verb. planLimitMessage() drops "Upgrade to Pro to add more." (each surface appends its own CTA). limitStr uses hyphenated adjective form "3-member" / "10-item" (compound modifier before "limit"). TASK-788 * feat(task-788): extend MCP-stdio plan-limit coverage to workspace, invite, webhook Wire WritePlanLimitError into three additional CLI command error paths so the MCP stdio classifier surfaces ErrPlanLimitExceeded with details instead of falling through to ErrServerError: - workspaceCreateCmd: check before fmt.Errorf wraps the APIError - inviteCmd: check before returning the raw error - webhooksCreateCmd: check before returning the raw error Add TestClassifyExecError_PlanLimitWorkspaceCreate to exercise the full workspace-create stdio round-trip through classifyExecError, asserting ErrPlanLimitExceeded code, feature="workspaces", limit, and upgrade_url. Token create intentionally left bare (agents don't drive token creation).	2026-05-25 11:46:41 -04:00
xarmian	35ac7552eb	feat(backlinks): UI panel + mention badge + CLI + MCP (Phase 3) (#623) ... * feat(backlinks): UI panel + mention badge + CLI + MCP (Phase 3) Phase 3 of PLAN-1593 (TASK-1596). Surfaces the backlinks index shipped in Phases 1/2a/2b across every place users live: web UI, CLI, MCP. What changed Web UI - New BacklinksPanel.svelte at web/src/lib/components/. Fetches via api.items.backlinks (new method) and renders inbound `[[...]]` references grouped by source collection. Per-row: collection icon, ref + title, snippet, relative timestamp, optional `(displayed as)` override, faint workspace badge on cross-ws rows. Pagination via "Show older" when the page is full. Collapses entirely when the count is zero — no header, no whitespace, no empty surface for items with no inbound links. - Mention badge ("📎 N") in the item-page action bar next to the Timeline button. Hidden when N=0; smooth-scrolls to the panel. Wired via onCountChange callback so badge + panel stay in sync. - New Backlink TypeScript type at web/src/lib/types/index.ts mirroring internal/models/backlink.go; new api.items.backlinks(ws, slug, opts) client method. CLI - `pad item show <ref>` enriched with inline top-5 "Mentioned in" section in TTY mode (skipped when empty), and a backlinks_top array in JSON output. Hint at the dedicated `pad item backlinks` command when the inline list hits the 5-row cap. MCP - New `pad_item.action: backlinks` — passes through to `pad item backlinks <ref>` with optional `limit` (default 50, max 300) + `offset` params. Bumps ToolSurfaceVersion 0.5 → 0.6 with a backwards-compatible additive note in version.go. Updated the catalog_readonly_test fixtures so the cmdhelp drift check passes. Test plan - [x] go build ./... + go test ./internal/mcp/ green - [x] make check (lint + Go + web) green - [x] make install + restart - [x] pad item show TASK-1596 shows --- Mentioned in --- inline - [x] pad item show TASK-1596 --format json includes backlinks_top - [x] svelte-check 0 errors - [ ] /codex review --loop → CLEAN Out of scope (filed as separate ideas if anyone asks) - Force-directed graph visualization of the link network - Broken-links report (target_item_id IS NULL feeds it but it's its own feature) PLAN-1593 / TASK-1596. * fix(backlinks): unique each-block key for multi-occurrence rows (Codex round 1) Codex round 1 P1: BacklinksPanel keyed each row by source_item_id, but the server preserves multiplicity — a source body that mentions the target three times produces three Backlink rows (Phase 1 design decision, covered by TestWikiLinks_RepeatedRefStoresMultipleRows). Duplicate keys in Svelte's #each are rejected at dev time and silently reuse DOM in prod, so the panel would render only one of the N rows from a multi-mention source. Fix: compose a unique key per row via new rowKey(bl, index) helper: `${source_item_id}|${snippet}|${index}`. The snippet usually differs across positions (centered on the bracket byte offset); the index suffix is the unconditional tie-breaker. PLAN-1593 / TASK-1596.	2026-05-24 15:02:06 -04:00
xarmian	8fb46ca1b5	fix(web): surface open_children 409 + offer force override (BUG-1538) (#597) ... * fix(web): surface open_children 409 + offer force override on status changes (BUG-1538) The server's open-children guard (IDEA-1494) returns a structured 409 when transitioning a parent to a terminal status while it still has non-terminal children. The web UI was catching this generically and toasting "Failed to update status" — users couldn't tell why the change was rejected or that --force exists. Now the API client preserves the structured `details` payload, and a singleton OpenChildrenDialog (mounted at +layout.svelte) lists the blocking children as links to their detail pages, surfaces hidden_blocker_count, and offers an "Override and mark <value>" button that retries the PATCH with force=true — same semantics as the CLI's --force flag. Wired into the two PATCH sites that change the done-field: the collection page's handleStatusChange (covers Board drag-drop + inline status changes) and the detail page's updateField (FieldEditor on the item detail page). TASK-1539. * fix(web): address self+codex review (round 1) - Item moves (POST /move) also hit the open-children guard server-side. Wire the same modal + force-override path through api.items.move() and handleMove() on the detail page (Codex finding 1). - OpenChildrenDialog: add a focus trap so Tab / Shift-Tab cycle within the modal, and restore focus to the previously-focused element on close (Codex finding 2 + self-review a11y note). - Simplify the nested try/catch in handleStatusChange / updateField: branch on isOpenChildrenError early so cancelling the modal stops emitting console.error noise and the retry-failure path stays distinct from the original-guard path (self-review nits 2 + 3). - updateField: assign item = { ...item } on cancel to force a fresh prop pass to FieldEditor in case it caches by identity. BUG-1538 / TASK-1539. * fix(web): capture full route identity in handleMove pre-modal (Codex round 2) Captures sourceItem/sourceWs/sourceUsername at move kickoff so a confirmed force-retry after navigation can't move the wrong item. Adds navIfStillCurrent helper that gates the success-path goto on identity match — stale resolutions complete silently rather than yanking the user away from the new page. BUG-1538. * fix(web): also gate handleMove navigation on route params (Codex round 3) Compare page.params.{collection,slug} in addition to item.id and workspace — during same-component navigation `item` can briefly still hold the source object after the URL has advanced. Route- param check closes that race. BUG-1538.	2026-05-19 20:54:55 -04:00
xarmian	fc6afd01be	feat(connect): unified Connect-to-agent modal + claim-code endpoint (TASK-1525) (#586) ... * feat(connect): unified Connect-to-agent modal + claim-code endpoint (TASK-1525) Phase E of PLAN-1519. Repurposes the avatar-menu "Connect a project…" modal as a one-stop hub where users can connect ANY agent surface (claim-code → existing OAuth grant, fresh MCP OAuth, or local CLI) to the current workspace. Backend - GET /api/v1/workspaces/{slug}/claim-code — generates a stateless 6-digit HMAC claim code (re-uses the verifier's secret + bucket math) for the calling member, OR reports `suppressed: true` when smart-suppression detects the workspace is already covered by one of the user's active OAuth connections (wildcard OR explicit allow-list rows). Returns `expires_at` at the current bucket boundary so the UI can drive a countdown. - store.IsWorkspaceCoveredForUser — single indexed query against oauth_connections + oauth_*_tokens; filters by ACTIVE tokens so a dangling revoked connection row doesn't suppress fresh modals. - Tests cover 412 (disabled), 404 (non-member), 200 + matching code, wildcard suppression, explicit-allow-list suppression, and the revoked-connection-doesn't-suppress invariant. Frontend - ConnectWorkspaceModal rewritten as a tabbed unified modal: - Agent (claim code) — fetches on activate, live countdown, auto-refetches at bucket roll-over, renders smart-suppression panel that links to /console/connected-apps, and renders the locked prompt block `Authorize the pad workspace '<slug>' with claim code <code>.` per IDEA-1517 §4. - MCP setup — subsumed from the now-deleted ConnectMCPModal: URL block + client-card grid linking to per-client docs. - CLI — existing install + `pad init` flow, unchanged. - Default tab: Agent when mcpPublicUrl is set; CLI when not. MCP tab hidden entirely on self-host without a public MCP URL. - ConnectBanner simplified: single modal state, generic "Connect an AI agent to this workspace" copy, no MCP/CLI dual-modal branching. - ConnectMCPModal.svelte deleted (fully subsumed). - API client gets `workspaces.claimCode(slug)` + `ClaimCodeResponse` TypeScript type. - TopBar + workspace home callsites pass `mcpPublicUrl` from authStore so the unified modal can pick the right default tab. Verification - go build ./... clean - go test ./... — all packages green (server + store) - cd web && npm run build — clean Parent: PLAN-1519. Phases A-D already shipped (oauth_connections schema, MCP claim action, /authorize redesign, connections-page mutation UI); this lands Phase E. Phase F (TASK-1526) will wire post-create auto-open from IDEA-1516's new-workspace modal; Phase G (TASK-1527) is cross-agent paste validation of the locked prompt string. * fix(connect): require membership at claim-code generation; guard modal against stale-response races per Codex review (round 1) 1. Guest-grant generation gap. RequireWorkspaceAccess admits item-grant guests who aren't workspace members; claim-code REDEMPTION requires full membership. Generating without the same check handed guests a valid-looking code + prompt that the claim endpoint always 404s. Add an explicit GetWorkspaceMember check after getWorkspace and return 403 not_a_member to fail closed on the same response shape the redemption path would have used. 2. Stale-response race in the modal. ConnectWorkspaceModal stays mounted across workspace switches (TopBar reuses the same instance), so an older claimCode fetch can resolve AFTER a newer one and stomp claimState with suppression or a code for the wrong workspace. Add a monotonic seq + captured-slug guard mirroring the refreshHasAgentActivity pattern already in ConnectBanner. Test additions: - TestHandleWorkspaceClaimCode_GrantOnlyGuest_403 asserts a non-member authenticated caller never gets a 200 + code from the generation endpoint.	2026-05-18 10:25:08 -04:00
xarmian	26aa800b3b	feat(oauth): connected-apps mutation endpoints + edit UI (TASK-1524) (#585) ... * feat(oauth): connected-apps mutation endpoints + edit UI (TASK-1524) Phase D for PLAN-1519. Adds four mutation endpoints under /api/v1/connected-apps/{id}/... and extends the console page with an inline Edit panel per connection card. Backend (internal/server/handlers_connected_apps.go + server.go) - PATCH .../name — rename, trim + cap at 120 chars - PATCH .../flags — atomic set of may_create / all_current / include_future (rejects toggling all_current=false when the join table is empty — empty-allow-list invariant from IDEA-1517 §3 Acceptance) - POST .../workspaces — add workspace; membership-checked, 404 uniform when the user isn't a member (no enumeration leak) - DELETE .../workspaces/{slug} — remove; idempotent for missing slugs; rejects last-workspace removal when all_current=false (same orphan guard as the flags handler) All four route through requireConnectionOwner which returns the same 404 envelope for non-owned connections as the existing Revoke endpoint. Each handler echoes the updated DTO so the page can re-render in place; respondWithConnection handles both active-token chains (via ListUserOAuthConnections) and connections without token rows (direct fetch of oauth_connections + the access projection). DTO (connectedAppDTO) gains name + the three scope flags. Model already carried the fields (TASK-1522). Frontend (web/...) - ConnectedApp TS type extended; api.connectedApps gains rename/updateFlags/addWorkspace/removeWorkspace methods. - Connections page: Edit button per card opens an inline panel with: connection name input (debounced save), three scope-flag toggles (auto-save), allow-list chips with X-to-remove plus a workspace picker that lists memberships not already in the list. - Last-workspace removal disabled at the UI level (chip-remove disabled when list length <= 1); API enforces the same invariant if a tampered call slips through. - Workspaces fetched lazily on first Edit open (cached for the page lifetime). Tests - 7 handler tests cover happy paths + edge cases: - rename trims/caps, non-owner 404 - flags happy path + empty-allow-list block - add workspace happy path + non-member 404 - remove workspace happy path + last-blocked + idempotent missing - loginTestUserAs helper to seed a second user for the non-owner case (the existing loginTestUser hardcodes a single email). Parent: PLAN-1519. * fix(oauth): wildcard→specific toggle now works after pre-stage per Codex review (round 1) PR #585 round 1 caught that switching all_current_workspaces from true to false was effectively impossible: the flags handler's empty-allow-list guard called GetOAuthConnectionAccess, which intentionally short-circuits on wildcard and reports zero slugs. Even with join rows present, the guard always tripped. The UI compounded the issue by hiding the allow-list editor while in wildcard mode, so users had no way to pre-stage workspaces. Backend fix: new Store.ConnectionWorkspaceCount(requestID) returns the raw join-row count regardless of the parent's wildcard flag. The flags handler now uses this; the remove-workspace handler's "orphan guard" also routes through the new count (plus an IsConnectionWorkspaceAllowed probe so a no-op removal of a slug that isn't even in the list doesn't trip the guard). Frontend fix: the allow-list editor renders unconditionally inside the Edit panel. While wildcard is on, an "Inert while wildcard is on" badge clarifies that staged workspaces don't take effect until the user flips the flag. Chip-remove disabled only when actively in specific mode AND about to drop to zero — wildcard-mode removes are always allowed. Added TestHandleUpdateConnectedAppFlags_WildcardToSpecific_AfterPrestage as the regression guard: seeds a wildcard connection, adds one workspace via the API, then asserts the flag flip succeeds and the resulting DTO carries the pre-staged slug. Parent: PLAN-1519. * fix(oauth): staged-while-wildcard rows now visible per Codex review (round 2) PR #585 round 2 caught that the round-1 fix (always-rendered allow-list editor + Backend ConnectionWorkspaceCount) was incomplete: pre-staging a workspace while wildcard=true succeeded on the server but the response DTO still suppressed the staged slugs (ListUserOAuthConnections + respondWithConnection both set AllowedWorkspaces=nil when AllCurrentWorkspaces=true). The UI rendered "No workspaces staged" even after a successful add, so users had no way to see or remove a mistaken staged row. Backend fix: new Store.ListConnectionWorkspaceSlugs returns the join table's slugs regardless of the wildcard flag. ListUserOAuthConnections + respondWithConnection both route through it now. The hot-path GetOAuthConnectionAccess still short-circuits on wildcard (correct for the introspection path — when wildcard is on, slugs are irrelevant for gating); the read- for-display path needs to surface them. Frontend fix: isAnyWorkspace now reads the all_current_workspaces flag directly (drives the "Any workspace" badge), independent of the slug list. The slug list drives the edit panel chips. Legacy fallback for missing-flag wire shapes preserved. Added TestHandleAddConnectedAppWorkspace_VisibleUnderWildcard as the regression guard: seeds a wildcard connection, adds a workspace, asserts the slug appears in DTO.AllowedWorkspaces while AllCurrentWorkspaces stays true. Parent: PLAN-1519.	2026-05-18 08:33:39 -04:00
xarmian	3a2ee6a45d	feat(web): Insert from URL — TipTap toolbar button + modal (TASK-1473) (#557) ... * feat(web): Insert from URL — TipTap toolbar button + modal (TASK-1473) Wires the editor to POST /api/v1/import/url from TASK-1472. Pieces: - ImportURLResponse type + api.importURL() in lib/api/client.ts. - ImportFromUrlModal.svelte — focus-on-open URL input, fetch button, preview pane with detected-type tag (OpenAPI / Generic) + title + source_url, Insert / Cancel footer. ESC and backdrop click close. Insert converts markdown → HTML via the project's existing `marked` renderer (same shape the editor uses for setContent on load), then insertContent(html) splices at the cursor. - EditorToolbar.svelte — new 🌐 button in the blocks group opens the modal. Optional onImportInserted callback bubbles the response metadata so the parent (the item editor page in TASK-1474) can stamp source_url / imported_at into the item's fields. Validation: light client-side URL parse + scheme check before hitting the server. The server's canonical SSRF guard is the authority. Toast feedback on successful insert via toastStore.show('...', 'success'). Parent: PLAN-1467. * fix(web): wire ImportFromUrl into Editor's slash menu + race guard per Codex review (round 1) P1: EditorToolbar.svelte is unused legacy — the live editor mounts Editor.svelte directly with a slash-command UI. The previous diff added a toolbar button no user could reach. Now: - Revert EditorToolbar.svelte to its pre-PR state. - Add `importUrl` block type to block-types.ts (insertOnly so it appears in the slash menu but not in the "Turn into" menu). - Editor.svelte's execSlash handles the new case by setting `importUrlModalOpen = true`; the modal is mounted at the bottom of the editor template. The slash command surfaces via type "/url", "/fetch", "/web", "/openapi", "/import", or "/page". P2: closing or re-fetching during an in-flight request previously let a stale response land on a fresh modal session. Now a monotonic `requestGen` counter is bumped on (a) every new fetch start, (b) every cancel, and (c) every reopen via the open effect. handleFetch captures its generation before await and drops both the response and the error if requestGen has advanced past it.	2026-05-15 00:53:00 -04:00
xarmian	2a5b0113d8	feat(web): surface invocation_slug + arg count on library playbook cards (TASK-1399) (#528) ... * feat(web): surface invocation_slug + arg count on library playbook cards (TASK-1399) Adds the PLAN-1377 invocation surface to the playbook library UI so users can see at a glance what makes an invokable playbook different from a passive checklist. - web/src/lib/types/index.ts: add LibraryPlaybookArgument type; extend LibraryPlaybook with optional invocation_slug + arguments matching the Go struct shape (T1). - web/src/lib/api/client.ts: activatePlaybook payload now forwards invocation_slug + arguments into the seeded item's fields JSON when set, mirroring ShipPlaybook() and the CLI/MCP activate paths fixed in T1. - web/src/routes/[username]/[workspace]/library/+page.svelte: - Playbook cards render `/pad <slug>` chip (mono, green) when invocation_slug is set. - Render `N arg{s}` badge (amber) when arguments has entries. - Both badges are conditional, so legacy library entries that omit them render unchanged. Verified: `npm run build` clean. Cards for trigger-only playbooks look unchanged; future invokable entries (T3-T5) will pick up the new chips automatically. Parent: PLAN-1397. * fix(library): use template-literal expression for slug-chip title per Codex review (round 1) Round 1 P1: the `title="Invoke via \`/pad {slug}\`"` form on line 218 tripped Svelte's parser because the literal backticks inside the quoted attribute value were interpreted as template-literal delimiters mid-attribute. `svelte-check` reported 9 errors on the line; vite build accepted it but the type-check did not. Fix is the form Codex suggested: pass the value as a JS expression with a real template literal: title={`Invoke via /pad ${playbook.invocation_slug}`} svelte-check now reports 0 errors on the file. The remaining warnings in the output are pre-existing in unrelated files (NestedChildren, ChildItems, roles, admin) and are out of scope for this PR.	2026-05-13 00:34:09 -04:00
xarmian	f1c9457790	feat(web): 403-driven cache purge for localIndex (TASK-1360) (#507) ... * feat(web): 403-driven cache purge for localIndex (TASK-1360) Per DOC-1342 design decision #3: the local cache is "what you could see last time you synced." When the server returns 403 mid-session, the offending entry is purged so the next read doesn't surface stale-by-permission rows. ## API client (web/src/lib/api/client.ts) - New `AccessRevokedScope` type + `setAccessRevokedHandler` registration hook. Keeps client.ts free of any store import (no circular dep). - `request()` on 403 parses the URL with `parseAccessRevokedScope` (handles item endpoints `/workspaces/{ws}/items/{idOrSlug}` and collection-items endpoints `/workspaces/{ws}/collections/{coll}/items`) and invokes the handler. Handler failures are caught + logged; the 403 still propagates as a `PadApiError`. ## localIndex - New `removeByCollection(ws, collSlug)` — bulk-remove every row in a collection. Used when a collection-scoped 403 means the whole grant is revoked. - New `findByIdOrSlug(ws, idOrSlug)` — id-first then slug-scan lookup so an item-scoped 403 with a slug URL can resolve to the in-RAM id (the SvelteMap is keyed by id). ## App bootstrap (+layout.svelte) - Registers the handler once at top level: item → `remove` after `findByIdOrSlug` resolves; collection → `removeByCollection`. Both purges write through to IDB via the existing `persistRemovals` path so reloads don't resurrect the stale row. 401 already triggers a /login redirect; this lands as the 403 counterpart. Permission-revocation that doesn't trigger a 403 (e.g. visibility loss with no fetched row) is explicitly punted per DOC-1342 #3 — best-effort cache, not authoritative for permissions. Parent: PLAN-1343. See DOC-1342 design decision #3. * fix(web): only purge on GET 403s, not write-method 403s (Codex round 1) [P1] notifyAccessRevoked fired on every 403 — including POST /items (create), PATCH /items/{id} (update), DELETE /items/{id} (archive), and the grants/share-link write endpoints. A read-only user who correctly fails to create or modify an item would have their entire collection purged from localIndex. Gate the purge on read methods (GET / HEAD). Write-method 403s mean "you can read but not write" — the cached rows are still legitimately visible. Read-method 403s are the canonical "visibility revoked" signal. Parent: PLAN-1343. * fix(web): purge entire workspace on 403, not per-item/collection (round 2) [P1] Codex caught two related issues: 1. Pad's server returns 403 from the workspace-access middleware (`permission_denied`, `not a member of this workspace`), and item-level visibility misses return 404. A 403 on /workspaces/{ws}/items/{slug} therefore means workspace access is gone — purging only `slug` leaves the rest of the workspace's cache stale. 2. The item URL parser matched `/items/{slug}/grants`, `/items/{slug}/share-links`, etc. — owner-only subroutes that can 403 after a role downgrade while the item itself is still readable. Purging the item on those was incorrect. Both fixed by collapsing the scope to "the entire workspace": AccessRevokedScope is now `{ kind: 'workspace'; workspace }`; the parser just extracts the workspace slug from any `/workspaces/{ws}/...` path; the handler in +layout.svelte calls `localIndex.reset(ws)`. The per-item `findByIdOrSlug` and `removeByCollection` helpers added in round 0 stay in localIndex for future per-item revocation paths (e.g. server-side `unauthorized` SSE events), but the 403 path no longer uses them. Parent: PLAN-1343. * fix(web): scope 403 purge to read-model endpoints only (Codex round 3) [P1] Codex caught that workspace-scoped 403s aren't all workspace-access-revoked signals. Grant-only guests legitimately get 403 on /workspaces/{ws}/members, /workspaces/{ws}/storage/usage, etc., while their item read access is fine. The previous "any workspace-scoped 403 → reset" handler would wipe the local index on every such 403, leaving guest views stuck loading. Restrict parseAccessRevokedScope to the explicit read-model endpoints the local-first store actually consumes: GET /workspaces/{ws}/items GET /workspaces/{ws}/items/{idOrSlug} GET /workspaces/{ws}/items-index GET /workspaces/{ws}/items-changes GET /workspaces/{ws}/collections/{coll}/items A 403 on any of these means the cache is stale-by-permission. A 403 on anything else stays opaque to the local index. Parent: PLAN-1343.	2026-05-11 21:15:43 -04:00
xarmian	a5b93c17c9	feat(api): add /items-changes?since=<seq> delta endpoint (TASK-1354) (#494) ... * feat(api): add /items-changes?since=<seq> delta endpoint (TASK-1354) Adds the delta-fetch sibling of /items-index for the local-first read model (PLAN-1343 / DOC-1342 design decision #1). Clients track the workspace-scoped monotonic seq cursor returned by /items-index (TASK-1353) and poll /items-changes?since=<cursor> to apply just the rows that have mutated — without re-downloading the entire workspace. ## Endpoint GET /api/v1/workspaces/{ws}/items-changes?since=<seq>&limit=<n> - `since`: exclusive seq lower bound (returns `seq > since`). Defaults to 0 → full delta == /items-index modulo ordering. Bad input → 400. - `limit`: cap on rows. Defaults to 5000, clamped to 50000. Bad input → 400. ## Response { "changes": [...skinny rows with `deleted: bool`...], "cursor": "<decimal MAX(seq) or unchanged since when empty>" } Soft-deleted rows propagate (no `deleted_at IS NULL` filter on the backing scan) so a delta consumer can remove them from its local index without a second roundtrip. Parent metadata enrichment matches /items-index: the underlying GetItem filters soft-deleted parents so we never leak parent title/ref for an archived parent. Cursor contract: - Sorted ASC by seq → re-passing the response's cursor as `since` on the next poll is no-overlap, no-gap (strictly monotonic seq invariant from TASK-1352). - Empty response preserves the caller's `since` so position isn't lost. - Truncated-by-limit responses set cursor to the last row's seq. ## Tests - FullDeltaFromZero — three creates, since=0, ascending seq, every row deleted=false, cursor=MAX(seq). - IncrementalUpdateAndDelete — typical resume flow: snapshot cursor, mutate, delta returns exactly the mutated + tombstoned rows with the right `deleted` flag. - CursorRoundtripsCleanly — empty-poll after consuming, cursor preserved. - LimitTruncatesAndCursorResumes — paging contract holds end to end with no overlap. - InvalidParams — bad since / limit values rejected with 400. - EmptyWorkspace — cursor round-trips caller's since unchanged. ## Web TypeScript: `ItemChangeRow = ItemIndexRow & { deleted: boolean }`, `ItemChangesResponse = { changes, cursor }`. API client gains `api.items.changes(ws, sinceCursor, opts?)` with the same defensive content-strip as listIndex so a stray `content: ""` key from a Go zero-value can never clobber the canonical store. Parent: PLAN-1343. Depends on TASK-1352 (seq column) and TASK-1353 (seq cursor on /items-index). Unblocks the future client-side localIndex.applyDelta integration task. * fix(api): surface tombstones for item-grant users in /items-changes per Codex review (round 1) Codex round 1 caught that handleListItemsChanges was building its ItemIDs filter from guestResourceFilter, which itself uses GuestVisibleResources whose item-grant query filters out soft-deleted items. The result: a guest or restricted member with an item-level grant on a single item would see that ID disappear from the lookup as soon as the item was soft-deleted — and /items-changes would never emit a `deleted:true` tombstone, so the client would keep the stale row in its local index forever. Fix: - New Store.GuestVisibleResourcesIncludeDeleted that drops the `i.deleted_at IS NULL` / `c.deleted_at IS NULL` filters on both collection and item grants so tombstone IDs flow through. - New Server.guestResourceFilterIncludeDeletedItems delegate pointing at the new store helper. Implementation is shared with the live variant via guestResourceFilterCore so the member-collection-access + system-collection merge logic stays in one place. - handleListItemsChanges swaps to the include-deleted variant. Test: TestGuestVisibleResourcesIncludeDeleted_SurfacesTombstones covers both variants side-by-side — live drops the soft-deleted grant, include-deleted preserves it. * fix(store): assign per-row unique seqs in MigrateItemFieldValues per Codex review (round 2) Codex round 2 caught that the bulk UPDATE inside MigrateItemFieldValues gave every affected row the SAME MAX(seq)+1. A /items-changes?limit=N poll that cut through that equal-seq group would advance the cursor to the shared seq, and the next `seq > cursor` poll would silently miss the rest of the group — the cursor contract requires strict monotonicity. Switched to a per-row loop inside the migration transaction so every UPDATE re-reads MAX(seq) and each affected row ends up with a strictly unique seq. The workspace advisory lock makes the read-modify-write race-free on Postgres; SQLite's single-writer rule handles it implicitly. Trade-off: O(N) statements instead of O(1) for the bulk path. Option-rename is an admin one-off so the cost is acceptable (~1s/1000 rows on a warm SQLite connection). If future use cases demand a larger row budget, a single-statement UPDATE..FROM with ROW_NUMBER() CTE assigning per-row seqs would also work. Test: TestMigrateItemFieldValues_PerRowUniqueSeq confirms 5 rows in a single migration step all get unique seqs.	2026-05-11 13:42:11 -04:00
xarmian	974472799a	feat(api): wire real workspace seq into /items-index cursor + rows (TASK-1353) (#493) ... * feat(api): wire real workspace seq into /items-index cursor + rows (TASK-1353) Replaces the placeholder `updated_at`-derived cursor on the /items-index response with the real workspace-scoped MAX(seq) introduced by TASK-1352. Each returned row carries its own `seq` field so clients can reason about ordering without parsing the cursor. When the requested scope returns zero rows but the workspace has items (e.g. ?collection=docs on a workspace whose docs collection is empty but whose tasks/ideas are not), the cursor falls back to the workspace's true MAX(seq) via a new Store.MaxItemSeq helper. That way the client's next /items-changes?since=cursor poll starts at the right floor instead of replaying every prior mutation from 0. Empty workspaces collapse to "0". Encoding: cursor is the decimal-encoded MAX(seq). Treated as opaque on the wire (clients re-pass it as ?since=). String form leaves room to switch to base32/etc later without an API break. TypeScript: `ItemIndexRow` (via `Item`) adds optional `seq?: number`; `ItemIndexResponse.cursor` docstring updated to reflect the real seq cursor semantics. `api.items.listIndex` docstring updated. Tests: - TestListItemsIndex_SkinnyProjectionAndShape: cursor now asserts decimal-encoded MAX(seq); per-row seq is non-zero. - TestListItemsIndex_EmptyResultFallsBackToWorkspaceMax: new test covering the cursor fallback on filtered-but-empty results. - TestListItemsIndex_CursorMonotonicAcrossMutations: new test confirming cursor advances after every mutation. Parent: PLAN-1343. Depends on TASK-1352 (seq column). Unblocks TASK-1354 (/items-changes endpoint). * fix(api): snapshot workspace MAX(seq) before list to close cursor race per Codex review (round 1) Codex round 1 caught a real race in /items-index cursor computation: ListItemsIndex ran first, then MaxItemSeq ran in a separate query. A concurrent INSERT visible to a future /items-changes call could land between them — the response would be `items: []` with cursor = the new seq, and a subsequent /items-changes?since=cursor poll (seq > cursor) would never return that row. Fix: capture MaxItemSeq BEFORE the list query. Per the workspace's monotonic counter invariant (TASK-1352) any insert after that snapshot has seq > captured M, so /items-changes?since=M will see it. Rows the list DOES observe may have seq > M (a concurrent insert the list query happened to commit-snapshot); MAX(rows.seq) bumps the cursor for that case so the client never re-fetches what was already in the response. Long-form comment on the handler captures the race scenario and the invariant that makes the snapshot order safe.	2026-05-11 13:09:49 -04:00
xarmian	d6894def4f	feat(web): collection page fetches via skinny /items-index endpoint (TASK-1349) (#491) ... * feat(web): collection page fetches via skinny /items-index endpoint (TASK-1349) Replaces every \`api.items.listByCollection(ws, coll)\` call in the collection page with \`fetchSkinnyItems(ws, coll, includeArchived)\`, which calls the local-first \`/items-index\` endpoint (TASK-1344) through the typed client wrapper (TASK-1345). Items now ship without the rich-text \`content\` body — the bulk of the per-row wire size — until the user opens an item detail page, which still goes through its existing full-item fetch. Call sites updated: - loadCollection — primary load + plans-names lookup - SSE handler for item_created / item_archived / item_restored / item_updated - Sync coordinator's full-refresh fallback The skinny rows are widened to \`Item[]\` at the boundary by setting \`content: ''\` on each row. This keeps the existing view component type contract unchanged and means existing call sites that read \`item.content\` see an empty string — already a "nothing to do" sentinel in the markdown-checklist progress branch. Documented regression — out of scope for this task: non-plans collections used to display checklist progress derived from item content's markdown checkboxes. With \`content\` no longer fetched for the list view, that progress no longer appears. Plans progress is unaffected (uses /plans-progress, not content parsing). Re-introducing the feature requires either server-side progress on the index endpoint or a separate lazy fetch — a follow-up rather than a blocker for the bandwidth win. In-scope behavior preserved: - Item create/update flow: server still returns full items, dropped into the array as-is; sync coordinator's incremental updates similarly use the full-item type from the changes feed - Server-side FTS search via \`searchResultIds\`: still id-keyed, works against skinny rows - List / Board / Table view components: already only read fields present on the skinny row (title, fields, tags, sort_order…) - Detail page fetch: unchanged — still goes through \`api.items.get\` which returns the full Item with content Parent: PLAN-1343. * fix(api+web): add /collections/{coll}/checkbox-progress endpoint to preserve list-view checklist progress per Codex review (round 1) Codex round 1 [P2] flagged that the original PR shipped a real regression: non-plans collections used to compute markdown-checkbox progress client-side from `item.content`, and the skinny `/items-index` endpoint dropped `content` from the payload — so list/board/table progress badges silently stopped appearing on docs/tasks/custom collections. This commit closes that gap with a new server endpoint that computes the same `{item_id, total, done}` counts via LENGTH/REPLACE arithmetic on the stored content, returning only the small derived counts. No item bodies cross the wire. Server (Go): - `store.CollectionCheckboxProgress(workspaceID, collectionID)` — SQL: `(LENGTH(content) - LENGTH(REPLACE(content, '- [ ]', ''))) / 5 + (LENGTH(content) - LENGTH(REPLACE(content, '- [x]', ''))) / 5` for total, the second clause alone for done. Same trick on SQLite and PostgreSQL. - `handleCollectionCheckboxProgress` — collection-visibility + item-grant filter so guests / restricted members can't enumerate items they shouldn't see. Mirrors `guestResourceFilter` exactly. - Route: `GET /api/v1/workspaces/{ws}/collections/{coll}/checkbox-progress`. - Test `TestCollectionCheckboxProgress` covers the math (open + done counts), zero-result rows are filtered, unknown collection → 404, empty result → 200 + `[]`. Web: - `api.items.collectionCheckboxProgress(ws, coll)` - Both call sites in `+page.svelte` (initial `loadCollection` non-plans branch + `refreshProgress` non-plans branch) now pull from the endpoint instead of parsing `item.content`. - Drops the previous "documented regression" comment — the feature is fully preserved. Sub-100-byte response per item (vs. the full content body) so the bandwidth win from `/items-index` is preserved. The endpoint scans content server-side, but doesn't transmit it — the original listByCollection call both scanned AND transmitted content. Parent: PLAN-1343. * fix(api+web): plumb include_archived through checkbox-progress per Codex review (round 2) Codex round 2 [P2] caught that the Archived toggle path lost checklist progress badges: `CollectionCheckboxProgress` hard-coded `deleted_at IS NULL`, but the page-side fetch is called with the same `showArchived` flag that toggles whether archived items render. With the toggle on, archived non-plan items appeared in the list but had no `itemProgress` row — the old client-side parse would have counted them. Fix: thread `includeArchived` through the call chain. - store.CollectionCheckboxProgress(workspaceID, collectionID, includeArchived bool) — appends `AND deleted_at IS NULL` only when includeArchived is false. Default match the original archived-off behavior. - handleCollectionCheckboxProgress reads ?include_archived=true and forwards. - api.items.collectionCheckboxProgress(ws, coll, { includeArchived }) on the client. - +page.svelte's two call sites pass `showArchived` / `includeArchived` exactly. TestCollectionCheckboxProgress now archives one of the seeded items and asserts: - default response excludes the archived item (1 row) - ?include_archived=true response includes it (2 rows) Also clarified the const-doc on `checkboxCountSQL` to reflect the dynamic deleted-at clause.	2026-05-11 11:51:06 -04:00
xarmian	f13e299d44	feat(web): typed client wrapper for /items-index (TASK-1345) (#487) ... * feat(web): typed client wrapper + ItemIndexResponse for /items-index (TASK-1345) Adds the TypeScript surface for the local-first read model bootstrap endpoint shipped in TASK-1344: - `ItemIndexRow` — `Omit<Item, 'content'>` so adding a column to `Item` flows into the skinny row shape automatically. - `ItemIndexResponse` — `{ items, total, cursor }` wrapper. `cursor` is documented as opaque since Phase 2 swaps the placeholder for a `seq` cursor. - `api.items.listIndex(ws, { collection?, includeArchived? })` — mirrors `listByCollection`'s shape, hits `/workspaces/{ws}/items-index` (workspace-level, not `/items/index`, to avoid colliding with an item whose slug is `"index"` — see PR #486 round 1). No callers wired yet — that's TASK-1346 (ListView virtualization) and the IDB sync layer in Phase 2. Parent: PLAN-1343. * fix(web): strip empty content field in listIndex per Codex review (round 1) Codex round 1 [P2] flagged that the server still ships `content: ""` on every row of /items-index because `models.Item.Content` is tagged `json:"content"` without `omitempty`. TypeScript's `Omit<Item, 'content'>` hides the field from downstream consumers, so naive spread/cache code could silently overwrite real item bodies with the empty string. Enforce the typed contract at the wrapper boundary: parse the raw response with `content` typed as optional, then destructure it out of each row before returning. The returned object has no `content` key, matching `ItemIndexRow`'s shape both at compile time AND runtime. Future cleanup option (separate task): add a Go DTO struct so the server doesn't put the empty field on the wire in the first place. The client-side strip is the minimal fix that addresses the correctness risk without touching the server contract.	2026-05-11 09:57:17 -04:00
xarmian	18087463ce	feat(collab): op-log cursor protocol — force-refresh + watermark advance (TASK-1319) (#472) ... * feat(collab): op-log cursor protocol — force-refresh + watermark advance (TASK-1319) Closes both holes left by TASK-1309: 1. Long-disconnected tab + external-write race. A reconnecting client announces its highest applied item_yjs_updates.id via `?since=<id>`. If that id is below MIN(id) for the item, rows it expected to replay have been pruned and the server sends a `force_refresh` control frame and closes the conn. Client recreates the Y.Doc and lazy-seeds from items.content. Without this, Tab A's stale state would silently overwrite an external CLI/MCP write on the next 5s flush. 2. Browser-only-edited items never GC'd. Browser collab-snapshot PATCHes now carry an op_log_cursor body field. The store advances items.content_flushed_op_log_id only when the cursor matches the current MAX(op-log.id) — proving the markdown captures every persisted op. SQL CASE clause re-evaluates MAX at COMMIT time so a peer op landing between client-side cursor capture and the UPDATE leaves the watermark untouched (no over-advancement). Combined cursor mechanism: - Server attaches op_log_cursor JSON control frames after replay, after every successful AppendYjsUpdate (originator), and to every peer's binary fan-out (so all peers stay in lockstep without a round trip). - Client persists per-tab in sessionStorage (NOT localStorage — avoids cross-tab cursor leakage that would force-refresh stable sessions). - Server's MIN(id) check + force_refresh fires only when a non-zero `since` is below MIN; `since=0` is treated as a fresh client. New store methods: MinOpLogID, MaxOpLogID. New ItemUpdate field: OpLogCursor *int64. New control message types: op_log_cursor, force_refresh. New OpEvent.OpLogID for cursor piggyback. Existing collab tests updated to drain TextMessage cursor frames. Tests cover: initial cursor frame after replay (populated + empty op-log), force_refresh fires when since<MIN, delta replay when since>=MIN, cursor broadcast to originator + peers on append, and watermark advancement gated on cursor==MAX. Parent: PLAN-1248. Builds on TASK-1309. * fix(collab): skip stale-Ydoc flush on force_refresh teardown per Codex review (round 1) A force_refresh tear-down means the local Y.Doc cursor is below the server's MIN(item_yjs_updates.id) — its derived markdown is stale. Without this guard the collab $effect cleanup runs flushCollabNow on the way out and silently PATCHes that stale markdown back to items.content, overwriting the canonical content the fresh provider is supposed to lazy-seed from. Per Codex round 1 [P1] of TASK-1319. * fix(collab): force_refresh on empty op-log + cancel pending flush per Codex review (round 2) Two P1 fixes: 1. Manager.Join now force_refreshes when since>0 and the op-log is empty (hasMin==false), not just when since<MIN. After PruneAndApply wipes the entire op-log, MIN is undefined; the original predicate would have admitted the stale tab and let its on-open Y.encodeStateAsUpdate write resurrect the pre-prune document. 2. The +page.svelte onForceRefresh handler now also clears collabFlushTimer. Without this a 5s timer that armed before the force_refresh frame arrived can still fire AFTER the cleanup ran, PATCHing stale Y.Doc-derived markdown to items.content. New test: TestRoomManagerForceRefreshOnEmptyOpLogWithSince covers the empty-op-log branch. Per Codex round 2 [P1] of TASK-1319. * fix(collab): include forceRefreshNonce in Editor key so it remounts on force_refresh per Codex review (round 3) The collab $effect cleanup runs on forceRefreshNonce bump, but the <Editor> {#key} was `${item.id}:true` — itemID doesn't change, so the keyed Editor wasn't unmounting. The Tiptap Collaboration extension only binds in onMount, so the editor stayed wired to the stale (destroyed) Y.Doc while a fresh provider+doc were set up in parallel. Edits would either be unsynced or eventually flush stale markdown again. Adding forceRefreshNonce to the key forces the Editor to remount in lockstep with the doc swap. Per Codex round 3 [P1] of TASK-1319. * fix(collab): refetch item.content before lazy-seed on force_refresh per Codex review (round 4) After force_refresh the collab $effect rebuilds the Y.Doc and the lazy-seed (TASK-1261) seeds it from item.content. But item.content was the cached page-state copy — possibly stale relative to the server (the WS force_refresh can beat the SSE/visibility refresh that would otherwise update it). Lazy-seeding stale content into a fresh op-log re-introduces exactly the staleness force_refresh was supposed to clear: the next 5s flush PATCHes that stale view back to canonical items.content. onForceRefresh now does an api.items.get() before bumping the nonce so the rebuild's lazy seed reads server-fresh content. A failed fetch falls through to the bump anyway (an editor on possibly-stale content is still better than a broken editor). Per Codex round 4 [P1] of TASK-1319. * fix(collab): suppress cursor during replay + move force_refresh check before getOrCreate per Codex review (round 5) Two more findings: 1. [P1] writeLoop sends op_log_cursor frames for live ops broadcast during the replay window. A client disconnecting after one of those cursors lands but BEFORE the rest of replay completes would persist a cursor pointing past unreplayed rows. On reconnect with since=that-cursor, server replays nothing — the client's Y.Doc would be missing causally-required ops. Fix: per-roomConn replayDone atomic.Bool. writeLoop suppresses cursor frames while it's false. runConn flips it after the post-replay initial cursor is on the wire. Live binary frames continue to flow during replay (Yjs CRDT commutativity); only the cursor metadata is gated. 2. [P2] Force-refresh path leaked an empty room. getOrCreate inserted into m.rooms before the force_refresh bail-out left an orphan entry that PruneSweep would later treat as 'active' and skip indefinitely. Fix: schema-rebuild + force_refresh checks now run BEFORE getOrCreate. Both are store-only mutations and the per-item lock is held throughout, so concurrency is unchanged. New test: TestRoomManagerCursorSuppressedDuringReplay regression- guards the cursor-suppression behaviour. Per Codex round 5 [P1+P2] of TASK-1319. * fix(collab): tighten initial cursor + sync-destroy provider on force_refresh per Codex review (round 6) Two more P1 fixes: 1. runConn's empty-replay fallback used MaxOpLogID() to anchor the initial cursor. A live op landing between replayTo returning and the cursor write would be reflected in MAX but its binary frame might not have flowed through this conn's writeLoop yet — the cursor would advertise an id the client hasn't received. Initial cursor is now strictly max(highestReplayed, since); MaxOpLogID is removed from the opLogStore interface. 2. Provider.handleControlMessage's force_refresh branch now calls this.destroy() SYNCHRONOUSLY before invoking the onForceRefresh callback. Previously the consumer's recovery path (async items.get refetch) would race the provider's own onClose-triggered reconnect, which would re-open with since=0 and push Y.encodeStateAsUpdate of the stale Y.Doc — recreating the corruption force_refresh was meant to prevent. destroy() sets destroyed=true so scheduleReconnect short-circuits. Per Codex round 6 [P1] of TASK-1319. * fix(collab): block flush scheduling during force_refresh recovery per Codex review (round 7) Previously, after onForceRefresh fires: 1. Provider is destroyed synchronously. 2. Async items.get refetch is in flight. 3. forceRefreshNonce bumps after refetch resolves. 4. $effect cleanup runs, then rebuild. But during steps 2-3 the editor component is still mounted with the stale Y.Doc, and a local edit fires handleContentUpdate which calls scheduleCollabFlush. clearTimeout earlier in onForceRefresh only canceled the timer at THAT moment; a new edit during the refetch window arms a fresh timer that fires before cleanup. That PATCHes stale Y.Doc-derived markdown back to canonical content, recreating the corruption force_refresh was meant to prevent. Fix: forceRefreshInFlight flag set in onForceRefresh, blocks scheduleCollabFlush, resets after the fresh provider is wired (end of $effect run). Per Codex round 7 [P1]. * fix(collab): gate runCollabFlush itself on force_refresh in-flight per Codex review (round 8) scheduleCollabFlush blocked the 5s timer path, but direct callers of flushCollabNow / runCollabFlush (beforeunload handler, rich-to-raw toggle) bypassed the guard. A page reload or raw toggle DURING the force_refresh recovery window still PATCHed stale Y.Doc-derived markdown to canonical items.content. Pulling the guard into runCollabFlush covers every caller in one spot and returns 'deduped' so the result-shape contract holds. Per Codex round 8 [P1] of TASK-1319. * fix(collab): distinct 'skipped' result for force_refresh path; raw-toggle aborts per Codex review (round 9) runCollabFlush returning 'deduped' on the force_refresh-blocked path was indistinguishable from a legitimate same-content dedupe. The rich→raw toggle treats 'deduped' as 'server already has this markdown' and seeds rawSeedMarkdown from it — letting the user's next raw edit overwrite canonical items.content with content derived from the stale Y.Doc. Add a distinct 'skipped' result for the force_refresh path. Raw toggle aborts on it (with a 'try again in a moment' toast); other callers fall through unchanged because no other call site behaviorally depends on 'deduped' vs 'skipped'. Per Codex round 9 [P1] of TASK-1319. * fix(collab): server-side gate + post-await client guard against stale collab-snapshot per Codex review (round 10) A force_refresh frame can arrive WHILE a collab-snapshot PATCH is already mid-flight to the server. The client-side forceRefreshInFlight check at PATCH-start can't catch this race; the request lands at the server with stale Y.Doc-derived markdown. Two-pronged fix: 1. Server: handler now checks op_log_cursor against MIN(op-log.id) for collab-snapshot PATCHes and returns 409 Conflict when cursor < MIN. Such cursors prove the flushing tab's Y.Doc was built on rows that have been pruned (PruneAndApply, schema rebuild, dormant GC). The markdown is, by construction, stale. 2. Client: post-await check on forceRefreshInFlight returns 'skipped' instead of 'flushed' so saveStatus / lastFlushedContent don't seed from a known-stale base even if the server happened to accept the PATCH (e.g. MIN advanced after handler validation). New tests: TestCollabSnapshotRejectsCursorBelowMin (gate fires), TestCollabSnapshotAcceptsCursorAtOrAboveMin (negative path). Also de-leak an unused slice in the round-5 cursor-suppression test so staticcheck stays clean. Per Codex round 10 [P1] of TASK-1319. * fix(collab): reject collab-snapshot when cursor>0 and op-log empty per Codex review (round 11) The HTTP-layer gate I added in round 10 mirrored only PART of the WS-upgrade force_refresh predicate. Round 5 had already taught us that 'op-log entirely pruned' is a separate stale path from 'cursor below MIN' (PruneAndApply, schema rebuild, dormant GC all leave hasMin=false), and the WS check now uses `since > 0 && (!hasMin || since < minID)`. The HTTP gate had only the second clause. Mirror the WS predicate at the handler so a stale collab-snapshot PATCH against an empty op-log gets a 409 too. New regression: TestCollabSnapshotRejectsCursorOnEmptyOpLog. Per Codex round 11 [P1] of TASK-1319. * fix(collab): reject collab-snapshot cursor=0 on non-empty op-log per Codex review (round 12) Round-11 gate accepted cursor=0 unconditionally. But a stateful tab whose previous session disconnected BEFORE receiving the post-replay cursor frame (network blip during the writeMu burst between replay binaries and the cursor) ends up with sessionStorage cursor=0 + a non-empty Y.Doc populated by prior replay binaries. On reconnect with since=0 the server treats it as fresh, replays nothing if the op-log was meanwhile pruned, and the client's on-open Y.encodeStateAsUpdate resurrects pre-prune ops. The next flush carries cursor=0 + stale-derived markdown. The gate now refuses any incompatible cursor: - cursor>0 + empty op-log (prior rule) - cursor<MIN + non-empty op-log (prior rule, now naturally catches cursor=0 too because 0 < any positive MIN) The WS replay path is unchanged — full replay from since=0 is the recovery for clients that genuinely lost their cursor; the corruption manifested through the flush PATCH which we now gate. New test: TestCollabSnapshotRejectsCursorZeroOnNonEmptyOpLog. Per Codex round 12 [P1] of TASK-1319. * fix(collab): close cursor=0 client/server gaps + lock validation+write atomically per Codex review (round 13) Four P1 issues addressed: 1. Client always sends op_log_cursor (including 0) so the server gate sees the field. Previously cursor=0 was omitted, which silently bypassed the server's stale-snapshot rejection. 2. Provider construction now resets sessionStorage cursor to 0 when the Y.Doc is empty. The Y.Doc isn't persisted across page reload, so a stored cursor=N + fresh empty Y.Doc would announce since=N to the server and miss rows 1..N from replay (server only replays id > N). 3. onOpen skips Y.encodeStateAsUpdate when lastOpLogID === 0. A populated Y.Doc + cursor=0 is the network-blip-during-cursor- write failure mode; pushing that state can resurrect ops the server has pruned. Server replay + lazy-seed handle recovery without our push. 4. Server gate now runs INSIDE the per-item collab setup lock (new RoomManager.UnderItemLock helper) so a concurrent prune (PruneAndApply, schema rebuild, dormant GC) cannot land between the MIN check and the items.content write. Without this, a tight race let stale snapshots overwrite canonical content the prune just installed. Per Codex round 13 [P1] of TASK-1319. * fix(collab): gate handleDocUpdate on cursorAnchored to close stale-Ydoc edit path per Codex review (round 14) Round 13 fix skipped on-open send for lastOpLogID===0, but local edits via handleDocUpdate still propagated. A populated Y.Doc + no-cursor-yet client could type, the edit would land in the op-log with id N, server would send originator cursor=N, and the next 5s flush would carry an 'anchored' cursor that passed the server's MIN check — overwriting items.content with stale- Y.Doc-derived markdown. Add a cursorAnchored boolean. Set on first op_log_cursor frame receipt (including cursor=0 against an empty op-log — that's a legitimate 'server has nothing' signal). handleDocUpdate refuses to send before this. Local edits buffer in the editor; once the cursor arrives (or force_refresh rebuilds the provider), the existing reconnect/edit paths catch them up. Per Codex round 14 [P1] of TASK-1319. * fix(collab): buffer + flush pre-anchor local updates per Codex review (round 15) Round 14 silently dropped local Yjs updates fired before the first op_log_cursor frame anchored the session. Yjs updates are incremental: a dropped keystroke leaves later ops referencing structs no peer can resolve, breaking convergence. Buffer pre-anchor updates in a Uint8Array[] (capped at 1000 to prevent unbounded growth in pathological 'anchor never arrives' scenarios — overflow triggers force_refresh-style recovery). On the first cursor frame, flush the buffer in order so the server gets every causally-required struct before any post- anchor updates land. Per Codex round 15 [P1] of TASK-1319. * fix(collab): destroy provider before force_refresh on pre-anchor buffer overflow per Codex review (round 16) Round 15 overflow path called onForceRefresh but didn't destroy the provider synchronously. A late op_log_cursor arriving before the page-level rebuild (the recovery callback is async — refetches items.content) would flip cursorAnchored=true, the partially- populated buffer would flush, but the DROPPED prefix (the overflowed entries) would leave server-side ops causally incomplete — exactly the bug the buffer was supposed to prevent. destroy() sets destroyed=true, removes message listener, short-circuits scheduleReconnect, closes the socket. Late cursor frames can no longer anchor a doomed provider. Per Codex round 16 [P2] of TASK-1319. * fix(collab): refuse rebuild on refetch fail + broaden on-open gate to cursorAnchored per Codex review (round 17) Two findings: [P1] force_refresh recovery bumped forceRefreshNonce in finally even when the item.content refetch failed. The rebuild then lazy-seeded from the cached (possibly-stale) item.content, and the next flush would PATCH that stale view back to the server. Move the bump into .then() so a failed refetch surfaces a 'please reload' toast and leaves the editor effectively read-only (forceRefreshInFlight stays true, blocking flushes). [P2] Send-on-open gate was lastOpLogID > 0, which silently dropped local edits made during a brief offline window after a legitimate 'cursor=0' anchor (empty op-log session). Switch to cursorAnchored — the boolean specifically distinguishes 'unanchored' (stale Y.Doc + no server confirmation) from 'anchored at cursor=0' (legitimate empty op-log). Per Codex round 17 [P1+P2] of TASK-1319. * fix(collab): force_refresh on cursor=0 against non-empty Y.Doc per Codex review (round 18) cursor=0 means the server's op-log is currently empty. A non-empty Y.Doc at first-cursor receipt implies the ops came from an earlier connection within this provider's life that never reached its post-replay cursor frame, followed by a server-side prune (PruneAndApply, schema rebuild, dormant GC) during our disconnect. Anchoring at cursor=0 in that state would mark a stale Y.Doc as authoritative; the next on-open state push or flush would resurrect pre-prune state and overwrite canonical items.content. Detect the configuration via Y.encodeStateVector length and invoke the same force_refresh-style recovery the explicit server frame triggers: destroy provider, clear sessionStorage, fire onForceRefresh so the page rebuilds from items.content. Per Codex round 18 [P1] of TASK-1319. * fix(collab): gate cursor=0 force_refresh on remoteSyncApplied per Codex review (round 19) Round 18 force_refreshed the provider whenever cursor=0 arrived against a non-empty Y.Doc. But local pre-anchor edits (user typed before the initial cursor=0 of a legitimate empty-op-log session arrived) ALSO populate Y.Doc — yet those edits live in preAnchorUpdates and were supposed to flush on anchor. The predicate spuriously triggered force_refresh, dropping the buffered local edits. Track remoteSyncApplied (set when readSyncMessage applies anything to Y.Doc — replay binary or live peer op). Only force_ refresh on cursor=0 when remoteSyncApplied is true: that's the true 'remote replay landed but server now reports empty op-log => mid-session prune' signature. Per Codex round 19 [P1] of TASK-1319. * fix(collab): repair brace mis-merge in wsProvider cursor=0 guard The round-19 patch overlapped the round-18 inner block, producing an extra brace + over-indented body. Collapsing into a single clean block restores parseability without changing semantics beyond what round 19 already documented. * fix(collab): gate syncStep2 reply on cursorAnchored per Codex review (round 20) readSyncMessage writes an inline syncStep2 reply when it receives a peer's syncStep1. That reply embeds our current Y.Doc state. If a peer's syncStep1 arrives before our first op_log_cursor (pre-anchor window), the reply path bypasses handleDocUpdate's cursorAnchored gate and lets potentially-stale Y.Doc state reach the server before the cursor=0 + remoteSyncApplied force_refresh recovery has a chance to fire. Suppress the reply while unanchored. Peer state propagation still works: the buffered preAnchorUpdates flush on anchor, and the lazy-seed rebuild after a force_refresh seeds canonical content from items.content. Per Codex round 20 [P1] of TASK-1319. * fix(collab): fold mid-replay live op ids into post-replay cursor + remoteSyncApplied only on apply per Codex review (round 21) Two more findings: [P1 server] writeLoop suppresses cursor frames during replay to prevent the client persisting a cursor past unreplayed rows. But binary frames for those live ops still go through (commutativity), so the client APPLIES them to its Y.Doc. The post-replay initial cursor only covered max(highestReplayed, since), leaving the cursor below the highest applied op. On empty-replay sessions this trips the client's 'cursor=0 + remoteSyncApplied' force_refresh path and discards buffered pre-anchor edits. Track maxLiveOpLogIDDuringReplay on the roomConn (atomic compare-and-swap) and fold it into the post-replay cursor. [P1 client] remoteSyncApplied was set on every MESSAGE_SYNC, including syncStep1 (which only carries a state vector — it doesn't apply state). A peer's syncStep1 arriving pre-anchor would falsely flag remote-sync-applied and trip the cursor=0 force_refresh on legitimate empty-op-log sessions. Set the flag only after readSyncMessage returns, and only for syncStep2 / update subtypes. Per Codex round 21 [P1] of TASK-1319. * fix(collab): widen writeMu critical section + drop omitempty on op_log_id per Codex review (round 22) Two more P1s: [P1 server] writeLoop's mid-replay record-max happened OUTSIDE writeMu, so runConn's post-replay read could race the record: runConn loads → writeLoop's atomic store of higher value → runConn sends cursor below the live id. Move the entire per-event sequence (binary write + replayDone observation + record-or-send) inside writeMu, and have runConn acquire writeMu around its read+cursor-write+replayDone-flip. The lock serializes the two paths cleanly: writeLoop events that ran first have already recorded; events that arrive after replayDone flips emit their own cursor frames. [P1 protocol] OpLogID had `omitempty` JSON tag — a legitimate cursor=0 (empty op-log session) serialized as `{"type":"op_log_cursor"}` with no op_log_id field. The client's strict-type check then rejected it as malformed, leaving the session unanchored and local edits buffered forever. Drop omitempty so 0 is wire-visible. Other control types (applier_request/ack) carry an extra op_log_id:0 in their JSON, which their client dispatches ignore. Per Codex round 22 [P1] of TASK-1319. * fix(collab): route originator cursor through writeLoop FIFO per Codex review (round 23) readLoop sent the originator's op_log_cursor directly via sendOpLogCursor right after AppendYjsUpdate, bypassing the bus/ writeLoop ordering. With a peer op already queued in rc.bus, the sequence on the wire could be: 1. originator cursor=N (newer local op) 2. peer binary (older op) 3. peer cursor=M < N (rejected by client's max-take logic) Client persists cursor=N. If the client then disconnects before applying the peer binary, reconnect with since=N replays nothing (server has nothing > N) and the older peer op is lost forever to this client's Y.Doc. Fix: writeLoop now processes self events too — skipping the binary echo (the originator already has Y.Doc state) but routing the cursor frame through the same FIFO bus channel as peer ops. The originator's cursor=N now arrives strictly AFTER all older-id peer events on the same channel. Per Codex round 23 [P1] of TASK-1319.	2026-05-09 21:45:46 -04:00
xarmian	9b1a91ab00	feat(collab): 5s-idle + on-disconnect markdown flush (TASK-1260) (#458) ... * feat(collab): 5s-idle + on-disconnect markdown flush (TASK-1260) Replaces the temporary handleContentUpdate suppression introduced in TASK-1259 (PR #457) with a proper flush mechanism. Under collab, the Y.Doc + op-log are canonical for live state but items.content needs to stay reasonably fresh for downstream consumers (search index, share-page, exports, plain API readers). ## Mechanism 1. **5s idle timer.** Every editor onUpdate (local OR remote) resets a 5s timer. On fire, PATCHes items.content via the new `?source=collab-snapshot` query param. 2. **Server-side bypass.** handleUpdateItem inspects the source query param. When set, skips the applyContentViaCollab routing entirely and writes directly. Without the bypass, the PATCH would loop back through the applier protocol (the same tab gets asked to apply, acks, server strips input.Content) and leave items.content unchanged forever. The flag is trustworthy because the caller already has edit access. 3. **Dedupe across peers.** Track lastFlushedContent. If our last successful flush already landed this exact markdown, skip the PATCH. Multiple connected tabs would otherwise each fire a redundant flush after every shared edit converges, multiplying server load by the peer count. 4. **On-disconnect flush.** $effect cleanup (item swap or page unmount) calls flushCollabNow(true) BEFORE provider.destroy(). A separate beforeunload listener catches close-tab / reload / external-nav. Both use fetch keepalive: true so the request outlives the page lifecycle. 5. **Item-id race guards.** runCollabFlush captures reqItemId before await; ignores response if item swapped. loadData() clears collabFlushTimer + lastFlushedContent on navigation. ## Files - internal/server/handlers_items.go — accept `?source=collab-snapshot` - web/src/lib/api/client.ts — add api.items.flushCollabContent - web/src/routes/.../[slug]/+page.svelte — handleContentUpdate gains scheduleCollabFlush + runCollabFlush + flushCollabNow; wired to $effect cleanup + beforeunload + loadData reset. Parent: PLAN-1248 * fix(collab): capture ws+itemId at provider mount + apply unescapeDocLinks per Codex review (round 1) Two findings from round 1: 1) [P1] runCollabFlush resolved item.id and wsSlug at execution time, not at schedule time. During item navigation the timer could fire (or $effect cleanup could run) AFTER `item` was already updated to the new item, causing the OLD editor's markdown to be PATCHed against the NEW item's URL — cross-item content corruption. Fix: introduce activeCollabContext = { wsSlug, itemId }, captured at $effect-body time (when the provider is minted). scheduleCollabFlush, runCollabFlush, and flushCollabNow all take their target identity from this captured context, never from live reactive state. Cleared in the $effect's own cleanup (defensive `=== ctx` slot guard so a fast-navigation churn doesn't clobber a successor context). 2) [P2] The disconnect flush read raw editor.storage.markdown .getMarkdown() without unescapeDocLinks, unlike the regular onUpdate path. Closing/navigating before the idle flush could persist escaped wiki links like \[\[TASK-1\]\] which then wouldn't be converted by markdownToWikiLinks. Fix: apply unescapeDocLinks() at the start of runCollabFlush (covers both the timer-driven idle path and the unmount path). * fix(collab): gate UI mutations on foreground+current-item per Codex review (round 2) [P2] runCollabFlush mutated page-scoped state (saveStatus, editorStore.lastSaveTime, lastFlushedContent) before checking whether the captured itemId still matches the foreground item. On item navigation, the cleanup-driven keepalive flush could stamp 'saving' onto the NEW page's saveStatus, leaving it pinned indefinitely (and pollute lastFlushedContent for the new item's dedupe state). Fix: introduce isForegroundCurrent() = !keepalive && item.id === itemId. Gate saveStatus / setLastSaveTime / showSaved on it so background cleanup flushes never touch UI state. Gate lastFlushedContent on item.id === itemId regardless of keepalive so a stale flush can't seed the wrong item's dedupe. * fix(collab): skip cleanup flush on rich→raw transition per Codex review (round 3) [P1] $effect cleanup fires the keepalive flushCollabNow on every provider teardown, including rawMode toggles. The raw-button onclick already pre-populated rawPendingMarkdown with the live editor markdown (which the 1.2s raw debounce will land), so the keepalive PATCH from cleanup is redundant — and worse, can land AFTER the raw save and clobber newer raw edits with the older Y.Doc snapshot. Fix: gate the cleanup flush on `!rawMode`. If rawMode is true at cleanup time, the user just toggled to raw and the raw-mode codepath owns items.content from here. The other cleanup triggers (item nav, canEdit flip, page unmount) all keep firing the flush as before. Note: rawMode === true at cleanup time unambiguously means "transitioning into raw" — the inverse case (already in raw and the cleanup fires for some other reason) is impossible because collabKey gates on !rawMode, so the provider $effect never runs while rawMode is true. * fix(collab): synchronously flush Y.Doc state on rich→raw toggle per Codex review (round 4) [P1] Rich → raw → navigate-without-typing-or-toggling-back never PATCHed the live Y.Doc state to items.content. The previous seed mechanism only set rawPendingMarkdown, which only fires the 1.2s debounce on a subsequent handleRawContentUpdate call — which never happens if the user doesn't type. Fix: await runCollabFlush(ws, itemId, md, true) inside the raw button's async onclick BEFORE flipping rawMode = true. This: - Lands items.content with the live Y.Doc state synchronously (one PATCH, awaited, with keepalive: true so it survives a fast post-toggle navigation). - Seeds lastFlushedContent so any cleanup-driven re-flush is deduped. - Avoids populating rawPendingMarkdown — the raw debounce now only fires for actual user edits in raw mode, eliminating the race where a stale debounce fired after navigation could clobber state. The Round 3 cleanup-skip on rawMode is kept as defense-in-depth (also makes the no-op-when-already-flushed semantics explicit). * fix(collab): loop-flush until stable + cancel timer on rich→raw toggle per Codex review (round 5) Two HIGH findings from round 5: 1) Round 4's single-flush captured md BEFORE the await; concurrent peer edits (e.g. same user's other tab) during the await were lost from the seed and could be overwritten by subsequent raw-mode saves. Fix: loop-flush until stable. Re-read editor markdown after each PATCH; if it changed, flush again. Capped at 3 iterations to bound the transition under aggressive concurrent typing. 2) An onUpdate during the await could schedule a 5s collab flush timer that survived the rawMode flip. The cleanup skipped flushCollabNow on rawMode, but the timer fired its own runCollabFlush — which then PATCHed stale rich markdown on top of subsequent raw saves. Fix: explicitly clearTimeout(collabFlushTimer) at the end of the rich→raw onclick (after the loop-flush, before flipping rawMode). Belt-and-braces with the Round 3 cleanup skip. * fix(collab): seed raw mode from lastFlushed (not unflushed Y.Doc) per Codex review (round 6) [HIGH] Round 5's loop-flush could exit at the 3-iteration cap with md still differing from the last-PATCHed value, then seed rawSeedMarkdown with that unflushed md. An immediate navigation without typing would lose the unpersisted state. Fix: track lastFlushed inside the loop. After the loop, seed rawSeedMarkdown = lastFlushed (the markdown we actually PATCHed), NOT md (potentially a never-flushed in-memory value). If peer edits keep arriving past our cap, items.content lags Y.Doc briefly — but the peer's own 5s flush will catch up shortly, and at least raw mode shows state consistent with items.content rather than holding a value the server never received. * fix(collab): three corner-case fixes per Codex review (round 7) 1) [HIGH] lastFlushed = md was set unconditionally inside the loop-flush, even when runCollabFlush returned false (PATCH failed). rawSeedMarkdown could then be seeded with markdown the server never received. Fix: gate `lastFlushed = md` on runCollabFlush returning true. Failed PATCHes leave lastFlushed at its prior value. 2) [HIGH] lastFlushedContent (the collab-flush dedupe key) was never invalidated by raw-mode direct saves. Scenario: collab flushes A. Raw saves B. User returns to rich + edits back to A. Next collab flush dedupes (lastFlushedContent === A) and skips, leaving items.content stuck on B. Fix: reset lastFlushedContent = null after every successful raw save (both the regular handleRawContentUpdate path and the flushRawIfPending drain loop) so subsequent collab flushes always re-PATCH. 3) [MEDIUM] The async rich→raw onclick applied rawSeedMarkdown + rawMode = true after multiple awaits without verifying the user was still on the same item. A navigation during the loop-flush could let item A's handler resume and seed raw mode on item B. Fix: before mutating component state (rawSeedMarkdown, rawMode), check `item?.id === itemId` (the captured target). Bail with `return` if mismatched. * fix(collab): differentiate flush outcomes + foreground keepalive=false per Codex review (round 8) Two findings from round 8: 1) [P1] runCollabFlush returned `false` for both PATCH failure AND dedupe-skip. The rich→raw toggle treated `false` as "didn't flush" and didn't seed rawSeedMarkdown — but a dedupe means items.content already matches our markdown (the prior successful flush put it there). Raw mode then seeded from the page's stale `item.content` field, and a subsequent raw save could overwrite the current server content with the pre-collab snapshot. Fix: change runCollabFlush's return type to a discriminated string: 'flushed' | 'deduped' | 'failed'. The toggle treats 'flushed' and 'deduped' equivalently for seeding (both mean "server has this markdown") and only bails on 'failed'. 2) [P2] The toggle path used keepalive=true for the awaited flush. Browser keepalive requests can reject for bodies larger than the per-origin keepalive quota (~64KB). On reject, the catch silently fell through and raw mode activated with rawSeedMarkdown null. Fix: switch the toggle path to keepalive=false. The await is synchronous and user-initiated; navigation isn't imminent, so the keepalive escape hatch isn't needed (and risks losing the explicit save). Also added an `aborted` short-circuit so a 'failed' result returns early WITHOUT entering raw mode — user can retry. Cleanup-driven flushes (which DO need to survive page lifecycle) still use keepalive=true.	2026-05-08 22:48:56 -04:00
xarmian	40352a32e1	feat(auth): PAD_BYPASS_SETUP_TOKEN open-bootstrap escape hatch (#429) ... Adds an env-var that lets self-host operators on trusted networks (Unraid behind a firewall, Tailscale-only deployments, homelabs) claim the first admin via the web UI without copying a bootstrap token out of the container logs. Behavior when PAD_BYPASS_SETUP_TOKEN=true: - handleBootstrap accepts non-loopback first-admin POSTs without an X-Bootstrap-Token header. The UserCount==0 invariant is unchanged, so the bypass auto-closes the moment the first admin claims the seat (subsequent bootstrap requests get 409 regardless of bypass). - handleSessionCheck returns setup_method=open so the /setup page skips the paste-token UI and renders the form directly. - Token generation is skipped at startup (no .bootstrap-token file written). A distinct WARN-flavored banner makes the open-mode trade-off obvious in operator logs. - Cloud mode (PAD_CLOUD/PAD_MODE=cloud) ignores the flag entirely. Three layers of defense: cmd/pad masks the env-var with !cfg.IsCloudServer(), Server.openBootstrapEnabled() checks !s.cloudMode, and the cloud branch in handleBootstrap never reads the bypass field. Unraid template gets a new "Bypass Setup Token" field (default false, Display="always") with a description that calls out the trust-the- network trade-off. Tests pin all the security-critical contracts: bypass admits non- loopback, bypass off keeps existing 403, cloud mode hard-ignores, loopback works either way, post-bootstrap gate stays closed, bypass wins over logs_token in session payload, cloud mode never advertises 'open' setup method. Codex review: CLEAN (round 1).	2026-05-06 13:27:12 -04:00
xarmian	05a9665f50	feat(auth): first-run logs-token bootstrap flow (TASK-1167) (#424) ... One-time bootstrap token generated on first start with no users in self-host mode. Token is logged in a banner the operator can grab from `docker logs`, persists at <DataDir>/.bootstrap-token (mode 0600), and bypasses the loopback-only gate via the X-Bootstrap-Token header — letting the user claim the first admin from a remote browser at /setup#token=<x>. Header-only contract + URL-fragment (browser-only, never transmitted) + log-redaction middleware keeps the secret out of access logs, proxy logs, and browser history. Cloud mode unchanged: token never loaded, never honored. Validate → UserCount-check → CreateUser → consume sequence is mutex-serialized to prevent concurrent valid-token requests from creating multiple admins. Part of PLAN-1166 (Pad on Unraid — Community Apps launch).	2026-05-06 08:40:11 -04:00
xarmian	1ff6158468	feat(workspace): expose currentRole + resource-scoped permission helpers (TASK-1101) (#415) ... * feat(workspace): expose currentRole + resource-scoped permission helpers (TASK-1101) Foundation for PLAN-1100 (client-side permission audit). Lands the primitive that every other task in the plan consumes, with no UI behavior changes. Server: - new GET /api/v1/workspaces/{ws}/me — returns role, collection_access, visible_collection_ids (computed via VisibleCollectionIDs / GuestVisibleCollectionIDs so it covers system collections, member access, direct collection grants, and item-grant collections), plus the user's direct collection_grants and item_grants. - admins normalize to "owner"; legacy workspace-scoped tokens normalize to "editor"; non-members with no grants are rejected upstream by RequireWorkspaceAccess and never reach the handler. Frontend: - new $lib/utils/permissions module exporting pure cascade functions: canEditWorkspace / canViewCollection / canEditCollection / canViewItem / canEditItem. - cascade mirrors server's ResolveUserPermission exactly: owner → item grant → collection grant → membership role + visibility so item grant beats collection grant beats role even when less permissive (ItemGrant.view + CollectionGrant.edit on same item → effective view). - workspaceStore wraps the pure functions with currentMembership state fetched in setCurrent. New getters: currentRole, currentMembership, isOwner, canEditWorkspace; new methods: canViewCollection / canEditCollection / canViewItem / canEditItem. - WorkspaceMembership type added. - api.workspaces.me(slug) added. Refactor: - settings/+page.svelte, [collection]/+page.svelte, [collection]/[slug]/+page.svelte: drop open-coded role derivation (members.find + m.role open-codes), consume workspaceStore.isOwner. members.list calls remain — still needed for assignee dropdowns / member rows in settings — only the role-derivation path moves to the store. Tests: - server: handlers_me_test.go covers 6 scenarios (admin, editor with all-access, viewer with collection grant, restricted member, guest with item grant, non-member with no grants). - frontend unit tests deferred — web/ has no unit-test runner today. Pure-function module makes them trivial to add when the runner lands. Cascade is independently covered by store/permissions_test.go and store/grants_test.go on the server. Parent: PLAN-1100. * fix(workspace): per-item visibility uses strict full-access set + setCurrent race guard per Codex review (round 1) P1: canViewItem fell back to canViewCollection, which uses the broad nav set (visible_collection_ids — includes collections containing item-granted items so they appear in nav). This meant a guest with one ItemGrant on TASK-5 in Tasks would see canViewItem(any-other-task-in-Tasks) return true, while the server only allows direct item grants or full collection grants. Fix: /me now also returns full_access_collection_ids — the strict set of collections in which every item is accessible (collection grants + member_collection_access + system collections; item-grant collections intentionally excluded). This mirrors guestResourceFilter's fullCollIDs in handlers. canViewItem and canEditItem now consult full_access_collection_ids on the membership-fallthrough path, NOT the nav set. Test added: TestMe_GuestWithItemGrant now asserts the item-grant collection is in visible_collection_ids (nav) but NOT in full_access_collection_ids (strict). TestMe_RestrictedMember updated to check both sets. P2: workspaceStore.setCurrent had no guard against stale async /me responses. A slow /me for workspace A could clobber a freshly-fetched membership for workspace B if the user navigated mid-flight, briefly exposing permission-gated UI for the wrong workspace. Fix: monotonic membershipSeq counter incremented per setCurrent / create call. Each /me response only writes back if its captured token still matches at resolution time. Also clears currentMembership immediately on setCurrent so helpers don't briefly answer "yes" using the previous workspace's grants while /me is in flight. Parent: PLAN-1100. Refs TASK-1101 PR #415. * fix(workspace): canEditCollection uses strict full-access set per Codex review (round 2) Same nav-vs-strict bug pattern as round 1's canViewItem fix, but in canEditCollection. The editor-membership fallback path previously gated on canViewCollection (broad nav predicate using visible_collection_ids), which incorrectly returned true for a restricted editor whose only access to a collection was an item grant. The collection appears in nav (correct) but the editor must NOT see collection-wide write affordances like "+ New" because the server rejects collection-level writes there. Fix: editor membership fallback now requires either collection_access === "all" or the collection to be in full_access_collection_ids. canEditItem already used full_access_collection_ids on its fallback path (it was added in round 1) — verified unchanged. Parent: PLAN-1100. Refs TASK-1101 PR #415.	2026-05-05 08:52:05 -04:00
xarmian	92c05cb029	feat(auth): expose mcp_public_url on /auth/session (TASK-1113) (#393) ... Adds mcp_public_url to the /auth/session response (and the parallel setupStatePayload for the pre-bootstrap state). Sourced from the existing s.mcpPublicURL field that SetMCPTransport populates from PAD_MCP_PUBLIC_URL at startup. Empty string when unset — never null, never absent — so the web UI can branch on `mcp_public_url !== ''` as the gate for "this Pad instance exposes a Remote MCP server." Frontend gets a parallel `authStore.mcpPublicUrl` getter mirroring the existing `cloudMode` pattern. AuthSession.mcp_public_url is typed as required (string), since the server always emits it. Tests cover both shapes: empty string when PAD_MCP_PUBLIC_URL is unset (both pre-setup and post-bootstrap), and verbatim echo when configured. Unblocks TASK-1114 (banner two-mode refactor) which gates on this field. Parent: PLAN-1111. Note: AuthSession lives in web/src/lib/api/client.ts, not types/index.ts — the task description had the wrong file. Type was edited in client.ts.	2026-05-03 10:40:44 -04:00
xarmian	f9d3244660	feat(connected-apps): user-facing OAuth connection management page (TASK-954) (#390) ... * feat(connected-apps): user-facing OAuth connection management page (TASK-954) Adds /console/connected-apps where a logged-in user can see every OAuth grant chain they've authorized via the MCP consent flow (Claude Desktop, Cursor, …) and revoke any of them. Joins to the DCR client metadata for the display name + logo, and to the MCP audit log (TASK-960) for the "last used" + "30-day calls" columns. Pieces: - internal/store/connected_apps.go — ListUserOAuthConnections walks oauth_access_tokens + oauth_refresh_tokens, dedups by request_id, hydrates client metadata, parses session_data for the workspace allow-list, classifies granted_scopes into a coarse capability tier. RevokeUserOAuthConnection verifies ownership (ErrConnection NotFound for stranger's chains — anti-enumeration; same shape as for unknown chains) then calls the existing RevokeRefreshTokenFamily + RevokeAccessTokenFamily so the next /mcp call gets 401. - internal/models/connected_apps.go — OAuthConnection + CapabilityTier models. - internal/server/handlers_connected_apps.go — REST endpoints: GET /api/v1/connected-apps (list) + DELETE /api/v1/connected-apps/{id} (revoke, idempotent, 204). Wrapped in requireCloudMode group. List enriches with MCPConnectionStatsForUser (audit aggregates) — soft-fails on the audit lookup so a broken audit table degrades to "no last-used data" instead of a broken page. Revoke records an "oauth_connection_revoked" entry in audit_trail via the existing CreateActivity path. - web/src/routes/console/connected-apps/+page.svelte — list with per-app card (logo, name, capability badge, workspace chips with +N expander, connected/last-used relative times, 30-day count), Details expander showing scope_string + workspace list + redirect URIs, Revoke button → confirm modal → optimistic refresh, friendly empty state linking to /connect. - web/src/routes/console/+layout.svelte — Connected Apps nav link (cloud-mode-gated, between Settings and Billing). - web/src/lib/api/client.ts + types/index.ts — typed client + ConnectedApp interface. Tests cover: - Store: chain dedup across rotation siblings, subject filtering (Bob can't see Alice's), inactive chains excluded, ownership check on revoke, idempotent re-revoke, capability tier mapping, session-data allowed_workspaces parsing (both []string and JSON []interface{} round-trips). - Handler: cloud-mode gate (404 outside), owner-only filtering, DTO field shape + audit enrichment populating last_used_at + calls_30d, revoke ownership 404 (not 403 — anti-enumeration), idempotent 204, audit_trail row written. `make check` clean (lint + go test ./... + svelte-kit build). Parent: PLAN-943. * fix(connected-apps): point empty-state link at getpad.dev (Codex review round 1) Codex caught: the empty-state link to /connect 404s because /connect is a pad-web (marketing site) route, not a docapp route. From inside the authenticated console at app.getpad.dev, the right target is the absolute https://getpad.dev/connect URL — same pattern the +error.svelte page uses for its "Back to getpad.dev" + "/docs" links. * fix(console nav): exclude /console/connected-apps from Workspaces active match (Codex round 2) Codex caught: the Workspaces nav predicate `isActive('/console') && !isActive('/console/settings') && ...` was missing the new /console/connected-apps prefix, so both Workspaces AND Connected Apps lit up when viewing the connected-apps page. Same shape as the existing exclusions for settings / billing / admin.	2026-05-02 23:21:07 -04:00
xarmian	89ae5369ae	feat(web): settings page exports .tar.gz bundle (TASK-892) (#309) ... * feat(web): settings page exports .tar.gz bundle (TASK-892) Replace the legacy "Download JSON" button on the workspace settings page with a single "Download .tar.gz" link that hits the existing ?format=tar dispatch on handleExportWorkspace. The bundle ships items + comments + version history + attachment blobs + manifest in a single archive — same shape the CLI's 'pad workspace export' command produces. Behavior: - Field label changed from "Export" to "Export bundle" - Button text changed from "Download JSON" to "Download .tar.gz" - href appended ?format=tar - download attribute changed from {slug}-export.json to {slug}-export.tar.gz - Added a title= tooltip explaining the bundle contents and that it's re-importable via the Create Workspace dialog No JSON-export UI surface remains in the settings page. The legacy JSON path on the server side stays for back-compat (any operator still hitting /export with no query keeps getting JSON). Parent: PLAN-890. Sibling task TASK-893 will flip the import modal to consume .tar.gz so the round-trip closes. * feat(web): import workspace bundle (.tar.gz) in CreateWorkspaceModal (TASK-893) Folded into the same PR as TASK-892 because Codex (correctly) flagged that exporting .tar.gz while still importing JSON ships a half-baked state — the settings page tooltip even tells users the bundle is re-importable via this modal. Now it actually is. Changes in CreateWorkspaceModal.svelte: - importWorkspace() now calls api.workspaces.importBundle(file, name) instead of reading + JSON.parse-ing the file and POSTing through api.raw.post. The new method sets Content-Type: application/gzip and posts the raw File body, which the server's existing dispatch in handleImportWorkspace routes to the bundle path (handlers_workspaces.go:361). - File picker accept attribute changed from ".json" to ".tar.gz,.tgz,application/gzip,application/x-gzip" — UI advertises only the new format. - Drag-drop guard accepts .tar.gz, .tgz, AND .json (legacy back-compat — server still supports JSON imports for any operator with an old archive lying around, even though we don't advertise it). - Drop-zone hint and import explanatory text updated to mention the bundle format and what's preserved (items, comments, attachments, version history). - Auto-fill regex strips -export.tar.gz, .tar.gz, .tgz, AND .json suffixes when seeding the workspace name from the filename. New api.workspaces.importBundle method in web/src/lib/api/client.ts: - Bypasses the JSON-only `request` helper — sets Content-Type: application/gzip and posts the File body raw. - Handles CSRF token, 401 redirect, and shaped error responses the same way `request` does. - Mirrors the CLI's `pad workspace import <bundle.tar.gz>` flow. Server-side: no changes — handleImportWorkspace dispatches on Content-Type and the bundle path was already audited + hardened in PR #308. Parent: PLAN-890. Closes the import/export round-trip alongside TASK-892. TASK-894 (Playwright e2e) covers the round-trip. * fix(web): drop .json from import accept list per Codex review (round 2) Codex P2 on PR #309: I left .json in the drag-drop guard isAcceptedBundleFile, intending to be lenient for users with legacy JSON exports. But api.workspaces.importBundle always POSTs as Content-Type: application/gzip — so a dropped .json file would route to the server's bundle path and fail with a gzip decode error. Confusing UX. Make the modal strictly tar.gz-only: - isAcceptedBundleFile regex narrowed to /(\.tar\.gz|\.tgz)$/i - name auto-fill regex narrowed to strip only -export.tar.gz, .tar.gz, .tgz suffixes - Comment documents that operators with legacy JSON exports can still curl them against POST /workspaces/import directly — the server keeps the JSON dispatch for back-compat. The file picker accept attribute was already strict (.tar.gz, .tgz, application/gzip, application/x-gzip) — this commit makes the drag-drop path consistent with it. Parent: PLAN-890.	2026-04-29 20:34:42 -04:00
xarmian	504d348917	feat(attachments): Settings → Storage tab with attachment list (TASK-882) (#303) ... * feat(attachments): Settings → Storage tab with attachment list (TASK-882) Adds the Settings → Storage tab and the underlying list/delete API endpoints so workspace owners can audit and reclaim attachment bytes. Backend (TASK-882 needs this — there was no list/delete API yet): - store.WorkspaceAttachments: paginated list with filter (category, attached/unattached, collection_id) + sort allowlist (size, filename, created_at — each with desc variant). LEFT JOIN to items + collections enriches each row with item_title/slug + collection_slug for the "in [[Item]]" link. Hides derived (thumbnail) rows by default — they count toward quota but are managed automatically and would clutter the user-facing list. - store.SoftDeleteAttachment: tombstones the row + every variant. Blob on disk stays put; orphan GC reclaims past the grace period (TASK-886). - GET /workspaces/{ws}/attachments — viewer+, returns {attachments, total, limit, offset}. - DELETE /workspaces/{ws}/attachments/{id} — editor+. Refuses to delete derived rows directly (returns 400 with derived_attachment code) and invalidates the storage-usage cache. Frontend: - StorageTab.svelte component (lib/components/settings) with usage bar (color thresholds at 80%/100%, override badge), 5-select filter row (category, item, collection, sort, page size), attachment list with thumbnails (image variants via thumb-sm, emoji icon otherwise), item link, MIME, size, date, and per-row delete with confirm() dialog. Pagination footer with Prev/Next + "showing X–Y of Z". - TS api.attachments.list() / delete() + types. - Wired as a new "Storage" tab on the workspace settings page. Tests: - TestListAttachments_Pagination: 3 uploads, default + size-asc sort, limit/offset paging. - TestListAttachments_HidesDerived: synthetic thumbnail row, asserts the list excludes parent_id != NULL rows. - TestDeleteAttachment_HappyPath: upload → delete → list empty → storage usage drops to 0 (cache invalidation hook fires) → second delete returns 404. - TestDeleteAttachment_DerivedRefused: thumbnail rows can't be deleted directly via the API. Parent: PLAN-866. * fix(attachments): collection visibility + category gaps + item ref shape per Codex (round 1) Three findings from Codex on PR #303 round 1: P1 — Collection visibility leak. The storage list returned all workspace attachments without applying per-user collection access, so a member with collection_access=specific would receive hidden collections' attachment IDs/filenames/item titles and could then pull the bytes via the existing download endpoint. Fixed by threading visibleCollectionIDs(r, workspaceID) through to the store filter. nil = admin/no restriction; empty slice = zero visible collections (zero rows by design); explicit set = restrict i.collection_id IN (...). Orphans (item_id IS NULL) are excluded for restricted users since their filenames would still leak. P2 — item_ref shape didn't match the route. The store synthesized "<collection_slug>/<item_number>" and the UI inserted it verbatim into the URL, producing /user/ws/tasks/tasks/5. Dropped item_ref entirely; UI now builds URLs from item_slug + collection_slug which is the actual route shape. P2 — Category filter coverage. mimePrefixForCategory only handled image/video/audio. Selecting Documents/Text/Archive/Other in the UI silently passed through with no MIME predicate so the list showed everything. Replaced with mimePredicateForCategory which emits the right SQL fragment per bucket: prefix LIKE for the type/ buckets, explicit IN list for document/text/archive (mirroring the allowlist in internal/attachments/mime.go), and a NOT-IN composite for "other". Tests: - TestWorkspaceAttachments_VisibilityFilter: admin sees all 3 rows; restricted to one collection sees only that collection's row + orphan suppressed; empty visibility yields zero rows. - TestWorkspaceAttachments_CategoryFilters: image/document/text/ archive/other each return exactly the matching MIME types. * fix(attachments): item-level visibility on list + delete per Codex (round 2) Two more findings from Codex on PR #303 round 2: 1. The list filter used VisibleCollectionIDs alone — but that set includes collections containing any item-level grant for the user. A guest with one item granted in collection B would still receive attachment metadata for every item in collection B. Replaced with the (fullCollIDs, grantedItemIDs) tuple from guestResourceFilter so the SQL ORs collection-level full access against per-item grants, matching how handlers_search / handlers_activity narrow lists. 2. The delete endpoint validated workspace membership but never checked the attachment's parent item is visible to the caller. An editor with restricted collection access could delete attachments in hidden collections by guessing/obtaining the attachment ID. Added requireItemVisible after fetching the parent item, plus a fallback gate for orphan attachments (item_id IS NULL) so restricted users get 404 there as well. Store-level filter renamed: VisibleCollectionIDs → Restricted + FullCollectionIDs + GrantedItemIDs. Tests cover the collection-only, item-grant-only, and zero-visibility paths. * fix(attachments): allow deleting attachments when parent item is soft-deleted (round 3) Codex P2 from PR #303 round 3: the storage list intentionally surfaces attachments whose parent item has been soft-deleted (so the user sees what's still consuming quota), but the delete handler used GetItem, which filters soft-deleted out and returned 404 before SoftDeleteAttachment could run — turning every Delete button on those rows into a no-op. Fixed by adding store.GetItemIncludeDeleted (mirroring the existing GetItemBySlugIncludeDeleted) and switching the delete path to use it. The visibility check still keys off the (still-set) collection_id, so soft-deleting an item doesn't escalate access — restricted users still hit requireItemVisible's 404 if they couldn't see the parent. Regression test: create item → attach → soft-delete item → list still returns the row → delete returns 204. * fix(attachments): list surfaces attachments under soft-deleted parents (round 4) Codex round-4 finding: WorkspaceAttachments still LEFT JOIN'd items with AND i.deleted_at IS NULL, so attachments whose parent item was soft-deleted disappeared from the list — even though the previous round wired GetItemIncludeDeleted on the delete path. Net effect: restricted editors with access to that collection couldn't discover the row in the UI; only full-access users saw it as an orphan-looking entry. Fix: drop the deleted_at filter from the JOIN. The collection ACL predicate (i.collection_id IN ...) now sees the (still-set) collection_id from the soft-deleted item, so visibility behaves consistently for live and tombstoned parents. Soft-deleted items don't escalate access — the collection_id stays put. UX: response now carries item_deleted=true when the parent is soft-deleted; the StorageTab renders the title with strike-through + a small "deleted" badge instead of a clickable link (which would 404). Tests: - store-level: admin/full-access sees the row + ItemDeleted flag, restricted-to-correct-collection sees it, restricted-to-other- collection does not. - (existing TestDeleteAttachment_AfterParentSoftDeleted continues to pass on the handler side.)	2026-04-29 17:44:12 -04:00
xarmian	335762c2bf	feat(attachments): storage usage API + effective-limit computation (TASK-881) (#302) ... * feat(attachments): storage usage API + effective-limit computation (TASK-881) Adds GET /api/v1/workspaces/{ws}/storage/usage returning {used_bytes, limit_bytes, plan, override_active}. Resolves the effective limit through the existing three-tier chain (per-user override → platform setting → hardcoded plan default) and surfaces the override flag for the upcoming Settings → Storage and admin user-detail UIs. Implementation: - store.WorkspaceStorageInfo consolidates SUM(size_bytes) + owner-plan resolution in one call; WorkspaceStorageLimit is now a thin wrapper so the upload-time quota check and the API path stay consistent. - Server.storageInfoCache is a 30s TTL memoizer to absorb repeated Settings → Storage page loads. Invalidation hooks fire on upload, thumbnail derivation, and transform — the ~30s eventual-consistency window is bounded by TTL only when invalidation isn't reachable. - Defensive copy on cache read so a caller mutating the returned struct can't poison subsequent reads. - New CLI command `pad workspace storage` prints "X used of Y (Z%)" with IEC units (humanBytes helper) and surfaces the override flag. - TS api.attachments.storageUsage() + WorkspaceStorageInfo type ready for TASK-882's Settings → Storage page consumer. Tests: - Store-level: no-owner fallback, free-plan resolution chain, override flip, pro-plan override-active visibility, soft-delete exclusion. - Server-level: empty-workspace happy path, two uploads with cache invalidation between, dedicated cache TTL/invalidate/copy-safety test. Parent: PLAN-866. * fix(attachments): gate storage usage on viewer+ per Codex review (round 1) Codex correctly flagged that the storage/usage handler relied solely on RequireWorkspaceAccess, which admits item-grant guests with workspaceRole=="guest". Workspace-wide quota numbers (used_bytes, plan, override status) shouldn't surface to guests — every other workspace- level read handler uses requireMinRole("viewer") for exactly this case. Adds the explicit gate + a regression test that calls the handler with a guest-role context and asserts 403.	2026-04-29 17:05:19 -04:00
xarmian	f93b0ee4ce	feat(attachments): server-side rotate transform + editor toolbar (TASK-879) (#297) ... * feat(attachments): server-side rotate transform + editor toolbar (TASK-879) Adds the POST /transform endpoint and the editor's rotate toolbar on top of TASK-878's Processor abstraction. Rotation produces a NEW content-addressed attachment row; the editor swaps the AttachmentImage node's UUID via setNodeMarkup and the original ages into orphan GC. Server (internal/server/handlers_attachments_transform.go): POST /api/v1/workspaces/{slug}/attachments/{id}/transform with body {operation, ...params}. Phase 1 wires the "rotate" branch (degrees: 90 | 180 | 270 only — pixel-exact reorderings, no resampling, matches what the editor emits). The "crop" branch is parsed and validated but the transform path is wired in TASK-880; defining the wire format here keeps both PRs aligned. Auth: editor+ on the workspace. Cross-workspace and deleted-parent probes return 404 (not 403) so the new endpoint can't become a side-channel for ID enumeration. Unsupported MIME → 415; oversized image → 413; bad params → 400; missing processor → 503. Output format follows the same PNG-stays-PNG / else-JPEG policy as the thumbnail pipeline so derived blobs deduplicate cleanly. Tests (10): rotate 90 swaps WxH, rotate 180 keeps WxH, bad degrees → 400, unknown op → 400, non-existent attachment → 404, cross- workspace → 404, no processor → 503, derived row has fresh hash + inherits workspace/uploader/item, served bytes decode at the new dimensions, deleted-parent → 404. Web client (web/src/lib/api/client.ts + types): api.attachments.transform(slug, id, payload) hits the new endpoint with a discriminated AttachmentTransformRequest type. New api.server.capabilities() reads the public capability profile added in TASK-878. Both surface PadApiError on failure so the editor can show actionable messages. Editor: - attachment-metadata.ts (new): shared HEAD-probe cache extracted from attachment-chip.ts so AttachmentImage's toolbar can probe the image's MIME with the same zero-extra-network-cost deduplication. Adds mimeToFormat() — maps MIME to the canonical short format name the server's Capabilities reports. - attachment-chip.ts: swapped to use the shared cache. Behavior unchanged. - attachment-image.ts: NodeView now wraps the <img> in a positioned <span> and lazy-builds a 3-button rotate toolbar (rotate left 90°, rotate 180°, rotate right 90°). selectNode shows it; deselectNode hides it. On click → calls options.transform → setNodeMarkup with the returned UUID at getPos(); cached metadata for the OLD UUID is invalidated. Per-button gating via refreshToolbarState: empty supportedFormats list (degraded build) → all disabled with a "this build doesn't have image processing" tooltip. MIME probed and not in supportedFormats → disabled with a format- specific tooltip ("Image editing for image/webp requires libvips"). Otherwise → enabled with the action tooltip. - Editor.svelte: configures AttachmentImage with the workspace slug, the supportedFormats list (initially empty, populated asynchronously after capabilities resolve), and the transform callback wired to api.attachments.transform. Errors surface via console.error + window.alert — same fallback as the upload plugin until a centralized toast system lands. - app.css: wrapper + toolbar styles. Toolbar pinned top-right with absolute positioning; selected-state ring on the image; disabled button state at 40% opacity. Parent: PLAN-866. Unblocks TASK-880 (crop) — the /transform endpoint already accepts the crop op shape, the editor's toolbar pattern is the same, and the supportedFormats gating composes cleanly. * fix(attachments): rotate attribution + toolbar refresh per Codex review (round 1) Two findings from the round-1 Codex review: 1. The transform handler set UploadedBy = currentUserOrSystem(r), contradicting the comment that said "inherit attribution from the parent" and creating an audit-attribution drift whenever a user rotated/cropped someone else's upload. Inherit parent.UploadedBy instead — same policy as the thumbnail pipeline. Added TestTransform_DerivedRowInheritsUploadedByFromParent to lock in the contract. Removed the now-unused currentUserOrSystem helper. 2. The rotate toolbar's per-format gating could permanently stick in "all-disabled" state if the user selected an image before the async capabilities fetch resolved. supportedFormats started as [] (matching "no processor"), refreshToolbarState ran once in that state, and the later mutation of ext.options. supportedFormats had no observer to push the change down to already-open toolbar DOM. Fix: module-level toolbarRefreshers set, populated by each NodeView at ensureToolbar() and torn down in destroy(); a new notifyAttachmentImageCapabilitiesChanged() export iterates the set and re-runs each toolbar's refresh hook. Editor.svelte calls it after the capabilities fetch updates ext.options.supportedFormats, so any toolbar opened during the in-flight request snaps to its correct state the moment caps arrive. Verification: go test ./internal/server -run TestTransform passes (11 cases now); npm run check passes with the existing 6 warnings.	2026-04-29 14:54:48 -04:00
xarmian	fc1c47f124	feat(attachments): CLI + TypeScript clients + types (TASK-873) (#290) ... * feat(attachments): CLI + TypeScript clients + types (TASK-873) Rounds out the API surface with Go and TS client methods + a \`pad attachment\` Cobra subcommand for ops debugging. internal/cli/client.go AttachmentUploadResult struct mirrors POST /attachments JSON. UploadAttachment streams a multipart file part via io.Pipe — never buffers the upload in memory. itemRef is optional. Uses a fresh http.Client with a 5-minute timeout per request so a 25 MiB upload over a constrained link doesn't trip the package-shared 10s default. DownloadAttachment streams the bytes into the caller's writer, returning Content-Type + total bytes copied. Optional ?variant= parameter for thumbnails (server falls back to original silently per TASK-872). cmd/pad/main.go pad attachment upload <item-ref|-> <path> [--filename NAME] pad attachment download <id> <out|-> [--variant thumb-sm|thumb-md] Item arg accepts an issue ref (TASK-5) or slug; "-" means no parent. Out arg "-" streams to stdout (with status messages on stderr) so callers can pipe into image viewers etc. Resolves the item via GetItem first so a typo'd ref fails fast with a useful error. List + delete subcommands intentionally omitted — those endpoints ship with TASK-881 (storage usage) and the future GC task. Adding client methods that hit 404s would mislead callers; same logic kept the upload response's "url" out of TASK-871 until TASK-872 wired GET. web/src/lib/types/index.ts Attachment interface mirroring the Go model (pointer types → optional). AttachmentUploadResult interface for the upload response shape. web/src/lib/api/client.ts api.attachments.upload(workspaceSlug, file, itemId?) — multipart POST via direct fetch (skips shared request() because that helper hard-codes Content-Type: application/json). Carries CSRF, cookies, and the same 401 → /login redirect. api.attachments.downloadUrl(workspaceSlug, attachmentId, variant?) is a pure URL builder so callers can wire <img src> directly without going through fetch. End-to-end smoke verified: pad attachment upload TASK-869 /tmp/tiny.png # uploads PNG pad attachment download <id> /tmp/dl.png # bytes are identical cmp /tmp/tiny.png /tmp/dl.png # PASS Verification go build ./... — clean go vet ./... — clean go test ./... — all packages pass cd web && npm run build — clean make install — server restarts on the new binary Parent: PLAN-866. * fix(cli): atomic download — write to temp + rename so a failed download doesn't truncate the destination per Codex review (round 1) P2: pad attachment download <bad-id> /existing/file used to wipe the existing file on auth/network/404 errors because os.Create truncated before the request was even attempted. The bytes were never written because DownloadAttachment errored out, but the destination was already 0 bytes — a footgun for anyone running the CLI in scripts. Fix: for the file-path case, write to a sibling .tmp via os.CreateTemp in the destination directory, fsync, close, then os.Rename only on success. Same atomic-write pattern as FSStore.Put. The defer cleans up the .tmp on any error path. The stdout case (outPath == "-") is unchanged — bytes already streamed to stdout can't be rolled back, so any partial write is just visible to the caller as a short payload. Verified end-to-end: echo X > /tmp/existing.png pad attachment download not-a-real-id /tmp/existing.png # errors cat /tmp/existing.png # still "X" — file untouched * docs(cli): clarify os.Rename atomic-replace behavior on Windows (Codex round 2 disagreement) Round 2 flagged this as P2: "os.Rename does not replace an existing destination on Windows." That is technically incorrect for modern Go. Verified directly against the Go stdlib source: src/internal/syscall/windows/syscall_windows.go: func Rename(oldpath, newpath string) error { ... return MoveFileEx(from, to, MOVEFILE_REPLACE_EXISTING) } MoveFileEx with MOVEFILE_REPLACE_EXISTING atomically replaces an existing destination on Windows. This has been the behavior since Go 1.5 (2015), so every version of Go this codebase supports already gets the desired replace-on-rename semantics on every platform. Added an inline code comment so future readers don't worry about the same false alarm. No code-path change.	2026-04-29 12:48:57 -04:00
xarmian	8e067c19db	feat(admin): add /api/v1/admin/billing-stats proxy + cloud client (TASK-827) (#266) ... * feat(admin): add /api/v1/admin/billing-stats proxy + cloud client (TASK-827) New admin endpoint that powers the upcoming Pad Cloud Billing dashboard: GET /api/v1/admin/billing-stats merges Stripe-derived metrics from pad-cloud (active subs, MRR, ARR, churn, 30-day cancellations) with locally-computed aggregates from the users table (customers_by_plan, new_signups_30d in the last 30 days for plan='pro'). Architecture (PLAN-825 Option B): - pad-cloud (TASK-826, already merged) hosts the Stripe API access in one place; this PR adds the reverse pad → pad-cloud client method. - Existing internal/billing.CloudClient gains GetBillingMetrics(): GET on /admin/metrics/billing with the X-Cloud-Secret header (the same secret pad-cloud already validates inbound calls with). - New CloudSidecar.GetBillingMetrics() interface method keeps the server package free of HTTP/Stripe dependencies and lets tests inject fakes. - Existing fakeSidecar in handlers_account_test.go grows a no-op stub so the account-delete tests still satisfy the extended interface. Degradation contract: - The endpoint always returns 200. Two booleans tell the UI which fallback to render: cloud_unreachable=true (sidecar errored or unwired) and stripe_configured=false (sidecar reachable but no STRIPE_SECRET_KEY yet). - requireCloudMode + requireAdmin gate the route. Self-host gets 404, non-admin gets 403. Web glue: - Added AdminBillingStats type to web/src/lib/types/index.ts. - Added api.admin.getBillingStats() to web/src/lib/api/client.ts. The Billing tab and metric cards land in TASK-828. Tests: - Billing package: GetBillingMetrics happy path (verifies method, path, X-Cloud-Secret header, Accept header), Stripe-not-configured pass-through, non-200 → SidecarError, transport error stays bare, malformed JSON, nil/unconfigured client guards. - Server package: self-host 404, non-admin 403, admin happy path (merges local + remote correctly, handles plan="" → "free", filters new_signups_30d to plan='pro' AND created_at >30d ago), no-sidecar degrades to local-only, transport error degrades, sidecar 5xx degrades, stripe_configured=false propagates verbatim with cloud_unreachable=false. Part of PLAN-825 (Pad Cloud Admin Billing Dashboard). * fix(admin): address Codex review (round 1) on billing-stats proxy - Replace handler-side ListUsers walk with store.CountBillingAggregates (two scalar SQL queries: COUNT(*) GROUP BY plan + a single COUNT(*) for new pro signups). Removes the per-row TOTP decrypt overhead that ListUsers performs and bounds CPU/bandwidth as the user table grows. - Fix misleading TS comment on AdminBillingStats: clarify that "fully healthy" requires cloud_unreachable=false AND stripe_configured=true, not "both flags false" as previously stated. Adds TestCountBillingAggregates exercising empty store, mixed plans, empty-plan → "free" bucketing, and the 30-day cutoff filter for new pro signups. * fix(store): GROUP BY normalised plan expression in CountBillingAggregates Codex round 2 caught a real bug: SELECT projected the COALESCE'd plan but GROUP BY operated on the raw `plan` column, so users with plan='' and plan='free' produced two distinct result rows that both scanned as "free" in Go — the second iteration overwrote the first in CustomersByPlan, silently underreporting the free-tier count. Fix: GROUP BY COALESCE(NULLIF(plan, ''), 'free') so the grouping matches the projection. Test updated: insertWithPlanAndDate now seeds an explicit '' plan alongside two explicit 'free' rows and asserts the aggregate rolls them up to 3 — the previous test only used CreateUser which always inserts the column default ('free') and never exercised the empty-string path.	2026-04-27 14:42:53 -04:00
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.	2026-04-14 23:40:23 -04:00
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.	2026-04-14 22:31:18 -04:00
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.	2026-04-14 19:27:52 -04:00
xarmian	ba01d95111	feat: add web UI for TOTP 2FA setup in user settings (#109) ... * feat: add web UI for TOTP 2FA setup in user settings Add a Two-Factor Authentication section to the console settings page so users can enable/disable TOTP 2FA from the browser. The backend API already existed (PR #77); this wires up the frontend. - Add 2FA section to console settings with enable/disable flows - Enable flow: QR code + manual secret + verification code input - Recovery codes displayed with copy/download after setup - Disable flow: password confirmation modal - Add totp.setup/verify/disable methods to API client - Add TOTP types (TOTPSetupResponse, TOTPVerifyResponse, etc.) - Add totp_enabled to User type and /auth/me response - Add qrcode npm dependency for rendering otpauth:// URIs Closes TASK-402 * fix: address codex review — separate QR rendering from setup, use clipboard util - Separate QR code rendering from TOTP setup API call so a QR failure doesn't abort setup when manual entry is still available - Use existing copyToClipboard utility with legacy fallback instead of raw navigator.clipboard.writeText	2026-04-14 09:04:37 -04:00
xarmian	7ca0463e70	feat: browser-based CLI authentication flow (#97) ... Replace the email/password terminal prompt in `pad auth login` with a browser-based auth flow. The CLI creates a pending session, prints a URL the user opens in their browser (works for localhost, remote VPS, or Pad Cloud), and polls until the session is approved. - Add CLI auth session endpoints (create, poll, approve) - Add browser approval page at /auth/cli/{code} - Rewrite `pad auth login` to use browser flow by default - Keep `pad auth login --interactive` as email/password fallback - Add login page redirect param support for post-login bounce-back - Add SQLite and PostgreSQL migrations for cli_auth_sessions table Closes PLAN-539, IDEA-404	2026-04-13 10:11:16 -04:00
xarmian	92580905bb	feat: cloud hardening and security follow-ups (PLAN-503) ... Address 11 issues identified during the PLAN-427 security review: Critical/High: - Stripe customer-to-user mapping with indexed lookup (TASK-505) - OAuth provider linking with explicit consent model (TASK-504) - CSRF tokens on admin console mutations (TASK-506) - Rate limiting on cloud admin and OAuth endpoints (TASK-507) Medium: - __Host- cookie prefix for subdomain protection (TASK-510) - Billing portal verifies customer ownership server-side (TASK-515) - Transactional account deletion with rollback (TASK-509) - Streaming data export with 60s timeout (TASK-508) - Migration registration for new columns (TASK-514) Low: - Billing page fetches actual plan limits from API (TASK-511) - Admin user search/filter pushed into SQL with pagination (TASK-512)	2026-04-13 01:03:12 +00:00
xarmian	d0518216c5	feat: add cloud infrastructure for hosted Pad (PLAN-427) ... Add the foundation for running Pad as a hosted service at app.getpad.dev. Same binary in cloud mode with a thin sidecar for OAuth and Stripe. Cloud mode (PAD_CLOUD=true): - PAD_CLOUD flag with cloud secret for sidecar communication - Account-level billing: plan field on users, CheckLimit enforcement - Free/Pro tiers with configurable limits stored in platform_settings - Three-tier limit resolution: user overrides → DB defaults → hardcoded fallback - Plan enforcement on workspace, item, member, webhook, and token creation Authentication & security: - OAuth login endpoint (POST /api/v1/auth/oauth-login) with cloud secret gate - Verified email requirement for OAuth, 2FA bypass protection - Cloud secret rotation support (comma-separated keys) - TOTP secret encryption at rest (AES-256-GCM via PAD_ENCRYPTION_KEY) - Rate limiting on OAuth login endpoint - Bootstrap disabled in cloud mode - Password max length enforcement (128 chars) - Config file written with 0600 permissions Admin & billing: - Admin user management API (list, detail, update plan/overrides) - Configurable plan limits API (GET/PATCH /api/v1/admin/limits) - Platform stats endpoint - Admin plan endpoint for sidecar to set user plans - GDPR: account deletion and data export endpoints Console UI (cloud mode only): - /console — workspace list with owned/shared sections - /console/new — create workspace wizard with slug preview - /console/settings — profile, password, API tokens - /console/billing — plan status, upgrade/manage links - /console/admin — user management, plan overrides, limits editor - OAuth buttons (GitHub/Google) on login page in cloud mode Auto-create default workspace on signup in cloud mode. Migration 035: plan, plan_expires_at, stripe_customer_id, plan_overrides on users.	2026-04-12 17:43:40 +00:00
xarmian	94d35509a4	feat: share links with hardened security, anonymous access, and analytics (#88) ... * feat: share links with hashed tokens and /s/{token} route Add share_links and share_link_views tables with CRUD API and anonymous resolution route (TASK-421). Data model: - share_links: token_hash (SHA-256), target_type/id, permission, password_hash, expires_at, max_views, require_auth, view tracking - share_link_views: per-view records with fingerprint/user tracking Token security: - 192-bit entropy (crypto/rand), URL-safe base64 encoding - SHA-256 hashed at rest, raw token returned only once on creation - Generic 404 for invalid tokens (no info leakage) - /api/v1/s/ exempt from auth middleware for anonymous access API endpoints: - POST /items/{slug}/share-links — create item share link - POST /collections/{coll}/share-links — create collection share link - GET /items/{slug}/share-links — list share links for item - GET /collections/{coll}/share-links — list for collection - DELETE /share-links/{id} — revoke share link - GET /s/{token} — resolve share link, return shared content D8: Anonymous users are ALWAYS read-only. View count and unique viewers tracked on each resolution. * feat: anonymous share page + share link management UI Add minimal-chrome share link viewer page and share link CRUD in the share dialog (TASK-422 + TASK-425). Share page (/s/{token}): - New SvelteKit route at /s/[token] for anonymous viewing - Renders item (title, fields, markdown content) or collection (name, item list) with no app chrome (no sidebar/topbar) - Handles require_auth links with "Sign in to view" prompt - Root layout bypasses auth checks for /s/ routes - "Powered by Pad" footer Share dialog updates: - "Share links" section below existing grants - Create/list/revoke share links for items and collections - Copy-to-clipboard for share URLs - Newly created links highlighted with "only shown once" notice - View count and auth-required badges API client: - ShareLink type added - shareLinks.* methods for CRUD - share.get(token) for anonymous resolution * feat: share link constraints + view analytics Add password protection, expiry, max views, and view history endpoints for share links (TASK-423 + TASK-424). Constraints (TASK-423): - CreateShareLink accepts ShareLinkOptions: password, expires_at, max_views, require_auth, restrict_to_email - Password hashed with bcrypt, verified on /s/{token} resolution - Password-protected links return {require_password: true} prompt - Expiry and max_views already validated by ValidateShareLink Analytics (TASK-424): - GET /share-links/{id}/views returns view history with fingerprint, user ID, and timestamp - Response includes total_views, unique_viewers, last_viewed_at - View history stored per-view in share_link_views table * fix: harden share links — XSS, access control, data leakage, and UX gaps - Sanitize rendered markdown with DOMPurify before {@html} injection (XSS) - Force require_auth=true when restrict_to_email is set (access bypass) - Reject malformed non-empty JSON bodies with 400 instead of failing open - Return public DTOs on share endpoints to prevent leaking internal IDs, creator info, assignees, schemas, and other sensitive fields - Enforce max_views atomically via conditional UPDATE to prevent races - Fix collection share rendering: read items from top-level response key and map ref/status fields correctly - Add password prompt UI and X-Share-Password header support so password-protected links can actually be unlocked by the frontend * fix: follow-up hardening for share links - Sanitize catch fallback in rendered markdown (XSS edge case if marked throws) - Remove query-string password fallback; accept only X-Share-Password header to avoid leaking passwords in logs, browser history, and referrers - Return 500 on ListItems DB failure instead of swallowing as empty collection - Normalize restrict_to_email with ToLower/TrimSpace on create and compare - Fix malformed JSON check for chunked bodies (ContentLength == -1) by checking for io.EOF instead of ContentLength > 0 - Remove internal share_link.id from public DTO responses - Use clientIP(r) helper for consistent fingerprinting instead of raw X-Forwarded-For which is spoofable and includes port in RemoteAddr - Distinguish DB errors from not-found in share link delete handler * fix: final hardening pass for share links - Move auth/email gate before password check to prevent unauthenticated callers from probing passwords and burning bcrypt CPU - Wrap view recording (counter increment, unique-viewer accounting, view insert) in a single transaction so a failed insert rolls back the consumed view count instead of silently losing it - Add X-Share-Password to CORS AllowedHeaders so cross-origin deployments can send the custom header without preflight rejection - Validate expires_at (RFC3339) and max_views (> 0) on share link creation; return 400 for invalid constraints instead of creating immediately-unusable links - Cap view-history endpoint limit to 1000 to prevent unbounded queries	2026-04-11 16:40:18 -04:00
xarmian	c6d19837c8	feat: collection & item grants, guest access, share dialog (PLAN-407 Phase 3) (#87) ... * feat: collection and item grants tables + permission resolution Add grant tables, CRUD operations, and permission resolution for guest access and member overrides (TASK-417). Data model: - collection_grants table (id, collection_id, workspace_id, user_id, permission, granted_by) with CASCADE on collection/user delete - item_grants table (same structure, references items) - Indexes for user/collection/item lookups Store methods: - Create/Get/List/Delete for both collection and item grants - ListUserGrants: all grants for a user across a workspace - RevokeAllUserGrants: bulk delete for member removal - ResolveUserPermission: full 5-step resolution per DOC-406 (owner → item grant → collection grant → membership → deny) API endpoints: - GET/POST/DELETE /collections/{coll}/grants — collection grant CRUD - GET/POST/DELETE /items/{slug}/grants — item grant CRUD - GET /users/{userID}/grants — all grants for a user in workspace All grant endpoints are owner-only for creation/deletion. * feat: grant revocation + member removal with grant choice Update member removal to support D4: owner chooses whether to revoke all grants when removing a member (TASK-489). - DELETE /members/{userID}?revoke_grants=true → remove membership AND all collection/item grants (full removal) - DELETE /members/{userID} (or revoke_grants=false) → remove membership but keep grants (user becomes a guest with existing access) - Audit log records whether grants were revoked - CASCADE DELETE on collection/item deletion already handles cleanup (via ON DELETE CASCADE in the grants migration) * feat: share dialog UI for items and collections + grant types Add a share dialog component for managing grants on items and collections, plus TypeScript types and API client methods (TASK-419). Frontend: - ShareDialog.svelte: reusable modal for listing/creating/revoking grants, with email input, permission select, and revoke buttons - Item detail page: "Share" button in meta-actions (owner-only) - Collection page: "Share" button in header actions (owner-only) TypeScript: - CollectionGrant and ItemGrant types added - API client: grants.listCollectionGrants, createCollectionGrant, deleteCollectionGrant, listItemGrants, createItemGrant, deleteItemGrant, listUserGrants Guest home screen (TASK-418) deferred — requires layout-level guest detection which will be implemented when guest routing is built. * feat: guest access — grants-based workspace access for non-members Allow authenticated users with grants (but no workspace membership) to access workspaces as guests (TASK-418). Backend: - UserHasGrantsInWorkspace: checks if user has any collection/item grants in a workspace - GuestVisibleCollectionIDs: returns collections visible to a guest via collection grants + collections containing granted items - RequireWorkspaceAccess: after member-nil check, falls through to grant check; sets role to "guest" if grants exist - VisibleCollectionIDs: non-members now checked for guest grants instead of returning empty - GetUserWorkspaces: includes guest workspaces (is_guest flag) - GetWorkspacesBySlugForUser: JOINs on grants tables so workspaces resolve for guests - roleLevel: "guest" = 0 (below viewer, blocks role-gated actions) Frontend: - Workspace.is_guest field in TypeScript type - Sidebar: hides Dashboard, Roles, Activity, Settings, and "New collection" button for guests; shows "Shared with you" header * feat: wiki-link rendering with locked icon for hidden items Update wiki-link rendering to show a 🔒 locked icon when the linked item is in a collection the user can't see (TASK-420). - renderMarkdown accepts optional visibleCollectionSlugs parameter - Items in hidden collections render as "🔒 Title" with tooltip - Unresolved links still render as broken (no change) - Username param added to renderMarkdown for correct URL construction - TimelineCommentCard and CommentThread accept username prop * fix: harden grant security — 9 findings from Codex review - Item grants no longer leak collection-wide read access; guests with item-level grants see only their granted items, not the full collection (GuestVisibleResources two-level filter + ItemIDs in ListItems SQL). - Edit grants are now enforced: mutating handlers (create/update/delete items, comments, reactions, links, versions) resolve grant-based permissions for guests via requireEditPermission + ResolveUserPermission. - Grant list endpoints restricted to owners (collection/item grants) or owner-or-self (user grants) to prevent metadata/email enumeration. - Guests blocked from listing workspace members; invitation details restricted to owners only. - Grant deletion scoped to workspace_id to prevent cross-workspace deletion by guessing grant IDs. - Member removal now revokes grants by default (opt-out with ?revoke_grants=false) and propagates revocation errors instead of silently discarding them. - Guest workspace listing properly propagates DB errors instead of swallowing them. - PostgreSQL subquery alias added to UserHasGrantsInWorkspace to fix silent guest-access failures on Postgres deployments. * fix: harden item-level grant isolation — 7 findings from Codex re-review - /changes endpoint now filters by item-level grants so guests with one item grant no longer receive updates for every item in that collection. - Search results filtered by item-level grants (new ItemIDs field in SearchParams) so guests can't discover other items via search. - Relationship/summary endpoints (item links, children, progress, activity, dashboard) all apply item-level visibility checks via isItemVisibleToGuest(), preventing metadata leakage through related item titles, statuses, and counts. - Grants now work as member overrides: a viewer with an edit grant can edit the granted item (requireEditPermission falls back to ResolveUserPermission for members below editor role). - handleMoveItem now requires edit permission on the target collection, not just visibility, preventing guests from moving items into view-only collections. - Member removal + grant revocation is now atomic via RemoveWorkspaceMemberAndRevokeGrants() which wraps both operations in a single database transaction. - Guest-access DB errors in middleware now return 500 with slog.Error instead of being silently collapsed into a 403 forbidden response. * fix: close remaining grant isolation gaps — 10 findings from Codex round 3 - Workspace token endpoints (create/list/delete) now require owner role, preventing guests from enumerating or revoking API tokens. - Legacy document endpoints (list, get, context, bulk-read, backlinks, links) now require at least viewer role, blocking guests entirely since documents are outside the grants model. - Global search no longer relies on workspaceRole() (which is unset outside RequireWorkspaceAccess); detects guests via IsWorkspaceMember and applies item-level filtering. Multi-workspace search now uses GuestVisibleResources for guest workspaces. - SSE event filtering now checks item IDs for guests with item-level grants, not just collection slugs, preventing live event leaks. - Role board passes ItemIDs through RoleBoardParams so guests only see items they have grants on, not the entire collection. - VisibleCollectionIDs for members with "specific" collection access now merges direct grants (collection + item grants), so grant overrides work for restricted members. - Plans-progress endpoint filters plan items and children by item-level grants for guests, preventing one plan grant from exposing all plans. - Webhook listing now requires owner role since URLs may contain secrets. - Agent role item counts use item-level filtering for guests. - Link deletion checks item-level visibility on both endpoints, not just collection-level. * fix: close member grant escalation and remaining edge cases — round 4 - Item grants for restricted members no longer escalate to collection- wide visibility. VisibleCollectionIDs now merges only direct collection grants (not item-derived collections) into member access. Item-level filtering (guestResourceFilter, isItemVisibleToGuest, requireItemVisible) now applies to both guests AND restricted members with item grants, closing the gap where a member with specific collection access plus one item grant could see/edit all items in that collection. - Guests blocked from workspace-level activity feed (/activity) which exposed audit events (member invites, role changes) with operational metadata. Requires at least viewer role. - Global search no longer returns zero results for item-only guests. Store.Search early-return now checks both CollectionIDs and ItemIDs are empty before short-circuiting, so item-level grants work in global (multi-workspace) search. - UserHasGrantsInWorkspace now excludes item grants on soft-deleted items, preventing phantom guest access to a workspace shell with no visible content when the only granted item is archived. * fix: prevent grant filter from overriding member access, close SSE/dashboard/collection leaks — round 5 - guestResourceFilter now returns nil/nil for members with "all" collection access, preventing item grants from accidentally replacing their full visibility. Only guests and members with "specific" collection access get item-level filtering applied. This fixes a regression where a normal member receiving one item grant would lose access to all other items. - requireItemVisible uses guestResourceFilter (with the same scoping) instead of raw GuestVisibleResources, so the member-access check is consistent throughout all code paths. - SSE event filtering now denies collection-less events (workspace updates, legacy document events) for guests, preventing metadata leakage through realtime event payloads. - Dashboard recent activity filters out workspace-level entries (no DocumentID) for guests, preventing audit metadata leakage. - All grant visibility queries (UserHasGrantsInWorkspace, GuestVisibleCollectionIDs, GuestVisibleResources) now join the collections table and require deleted_at IS NULL, so grants on soft-deleted collections no longer provide phantom access. * fix: make item grants additive for restricted members, close write/search/SSE gaps — round 6 - guestResourceFilter now merges member_collection_access + system collections + collection grants into fullCollIDs for restricted members, making item grants additive to existing access. Previously, item grants replaced the member's normal collections, causing members with one item grant to lose all their other collection visibility. - Added ListSystemCollectionIDs store method for system collection lookup. - Search (both global and workspace-scoped) now applies item-level filtering for restricted members with item grants, not just guests. Previously VisibleCollectionIDs included item-granted collections as full-access, leaking all items in those collections via search. - SSE event filtering now builds item-level filters for restricted members with item grants (previously only for non-members/guests), and merges member collections into the full-access set. - Role board reorder now uses requireItemVisible + requireEditPermission per item instead of collection-only visibility check, preventing restricted editors from reordering items in item-granted collections. - View create/update/delete now check requireEditPermission on the collection (via requireViewEditable), not just collection visibility. - GetUserWorkspaces guest query now joins collections/items tables to exclude grants on soft-deleted resources, matching the behavior of UserHasGrantsInWorkspace. * fix: block guests from legacy doc versions/activity, fix ListItems early return, SSE fail-closed — round 7 - Legacy document version handlers (handleListVersions, handleGetVersion) and document activity handler (handleListDocumentActivity) now require at least viewer role, blocking guests from reading version history and activity for unrelated legacy documents. - ListItems early return now checks both CollectionIDs and ItemIDs are empty before short-circuiting, matching the fix already applied to Search. This fixes item-only guests seeing zero results from /items, dashboard, role board, and agent-role counts. - SSE item-grant filtering now fails closed on GuestVisibleResources errors: installs empty item/collection filter sets instead of falling through with nil (which would pass all events through). - Role board reorder removed top-level requireMinRole("editor") so the per-item grant-aware requireEditPermission checks can run for guests and viewers with edit grants, consistent with other mutating handlers.	2026-04-11 14:46:24 -04:00
xarmian	0587deba41	feat: UI for managing member collection visibility ... Add API endpoints and settings UI for managing per-member collection access (TASK-416). Backend: - GET /members/{userID}/collection-access — returns mode + granted IDs - PUT /members/{userID}/collection-access — sets mode + collection IDs (owner-only) Frontend: - API client: getMemberCollectionAccess, setMemberCollectionAccess - Settings Members tab: "Manage access" button per member (owner-only) - Expandable inline panel with all/specific toggle - Collection checkbox list: non-system collections toggleable, system collections always checked + disabled with "system" tag - Save/cancel with optimistic update	2026-04-11 01:35:51 +00:00
xarmian	b1357799a9	feat: username validation, reserved words, and registration flow ... Add username support to registration with validation, reserved words, and real-time availability checking (TASK-409). Backend: - ValidateUsername() with format/length/reserved word checks - 35+ reserved usernames (route conflicts, system terms) - GET /auth/check-username endpoint for real-time validation - handleBootstrap auto-generates username from name (D1) - handleRegister accepts optional username, auto-generates if omitted Frontend: - Register page: username field with auto-generation from name - Join/invite page: same username field in register mode - Debounced availability checking (400ms) via /auth/check-username - Inline status indicators (checking/available/taken) - API client: register() accepts username, new checkUsername() method	2026-04-10 23:12:59 +00:00
xarmian	f80876a52e	feat: add username column to users table ... Add username field to the user data model as the foundation for the multi-user permissions system (PLAN-407, TASK-408). - SQLite migration 029 and Postgres migration 009 add username column with partial unique index (WHERE username != '') - User, UserCreate, UserUpdate Go structs updated - Store: CreateUser, UpdateUser, scanUser, userColumns updated - New GetUserByUsername store method (case-insensitive lookup) - All auth handler JSON payloads include username field - WorkspaceMember struct and ListWorkspaceMembers query include username - TypeScript User type and API client inline types updated Column is empty string by default; TASK-482 will backfill existing users and TASK-409 will add validation/registration flow support.	2026-04-10 22:40:07 +00:00
xarmian	1d26c2b542	feat: add workspace top bar with drag-to-reorder (#80) ... * feat: add workspace top bar with drag-to-reorder Replace the sidebar WorkspaceSwitcher dropdown with a dedicated top bar that provides fast workspace switching and a user menu. Desktop: - Horizontal bar above sidebar + content with workspace icons (colored first-letter circles) and names as real <a> links - Drag-and-drop reorder via svelte-dnd-action - User avatar on right with dropdown (settings, theme toggle, sign out) - "+" button to create new workspaces Mobile: - Full-width fixed bar at top when sidebar opens (above sidebar/backdrop) - Tap workspace to navigate and close sidebar - Reorder button opens full-screen vertical list with drag handles - Sidebar starts below the top bar with adjusted positioning Backend: - Migration 028: add sort_order to workspace_members (per-user ordering) - GET /workspaces now returns workspaces in user's sort order - PUT /workspaces/reorder endpoint for persisting order Sidebar simplified: - Removed WorkspaceSwitcher component, user section, theme toggle - Theme initialization moved to root layout - Cleaner footer with search, settings, and notification bell Implements IDEA-129, relates to IDEA-126. * fix: address codex review findings (P1+P2) - Remove unsupported `direction` option from svelte-dnd-action dndzone - Add Postgres migration 008 for workspace_members.sort_order - Handle sql.ErrNoRows gracefully in reorder endpoint for admins who aren't members of all workspaces - Restore mobile sign-out: add user name + logout button to sidebar footer on mobile (was only in desktop TopBar user menu)	2026-04-10 01:22:49 -04:00
xarmian	7ef4506cfa	fix: replace scattered tab-resume refetches with layered sync system ... When the browser tab lost focus and regained it, 5 independent onTabResume callbacks all fired simultaneously, flooding the server with redundant requests. This replaces that pattern with a 4-layer sync architecture: 1. Replay buffer — per-workspace ring buffer stores recent events with monotonic IDs. On SSE reconnect, missed events are replayed via Last-Event-ID so the client is already caught up. 2. Last-Event-ID support — SSE handler reads the header, replays from buffer, or sends sync_required if the gap is too large. 3. Incremental sync — new /changes?since=<ms> endpoint returns only modified/deleted items since a timestamp, including archived items for view consistency. 4. Centralized sync coordinator — single decision tree replaces 5 scattered callbacks. Short absences skip sync entirely, SSE-covered gaps need no API calls, and full refresh is a last resort. Key robustness details: - Global event IDs via Redis INCR for multi-instance safety - Server-time cursors to avoid client clock skew - Safe cursor management (only advances on confirmed sync) - 9 new tests for replay buffer and event ID behavior Fixes BUG-26.	2026-04-10 04:15:43 +00:00
xarmian	1ac0abc305	fix: resolve 2FA Codex review findings (Postgres bools, recovery code race, web login flow) ... - Use dialect.BoolToInt() for totp_enabled updates instead of hardcoded 1/0 integers that fail on PostgreSQL BOOLEAN columns - Add optimistic locking to ConsumeRecoveryCode to prevent double-spend under concurrent requests - Add 2FA challenge step to web login and join pages so browser login works for accounts with TOTP enabled	2026-04-08 20:30:39 +00:00
xarmian	bde15d45ca	Rename Phases to Plans, clean up deprecated aliases (#71) ... * Rename "Phases" to "Plans" and clean up deprecated phase aliases Renames the default "Phases" collection to "Plans" across the full stack: - DB migration renames existing collections in-place (name, slug, prefix PLAN, icon 🗺️) - Removes all deprecated Phase* backward-compat aliases from models and store - Removes --phase CLI flag (use --parent instead) - Updates convention triggers: on-phase-start/complete → on-plan-start/complete - Updates dashboard API: active_phases → active_plans, /phases-progress → /plans-progress - Updates all frontend components, types, and documentation Closes IDEA-124 * Fix CSRF cookie not being cleared on logout The SessionAuth middleware was re-issuing a CSRF cookie before the logout handler could clear it, resulting in two Set-Cookie headers. Skip CSRF re-issue for /api/v1/auth/ paths since auth endpoints manage their own CSRF cookies (login sets, logout clears). * Fix migration issues found in Codex review - P1: Move doc_type UPDATE from migration 024 into 025, which recreates the table with the new CHECK constraint first (SQLite enforces CHECK on UPDATE, so the old constraint would reject 'plan') - P1: Add PostgreSQL migration 005 for the collection rename (phases → plans) — previously only existed on the SQLite path - P2: Recreate FTS triggers, indexes, and rebuild FTS after the table swap in migration 025 (DROP TABLE drops associated objects in SQLite) * Fix parent filter field name and sync .agents skill copy Codex review round 2 findings: - P1: Parent filter compared against `parent_id` (wrong) instead of `parent_link_id` — plan filtering in collection view was broken - P1: .agents/skills/pad/SKILL.md still had old --phase flags and "Phases" references — synced from the updated .claude copy - P2: Accept legacy 'phase' filter key for backward compat with existing saved views that serialized the old key name * Fix PG migration JSONB casting and add slug collision guards Codex PR review bot findings: - P1: PostgreSQL REPLACE/LIKE don't work on JSONB columns — cast schema::text and fields::text before string ops, then back to ::jsonb - P1: If a workspace already has a custom 'plans' collection, the rename hits UNIQUE(workspace_id, slug) — added NOT EXISTS guard to both SQLite and PostgreSQL migrations	2026-04-07 14:55:23 -04:00
xarmian	063ff92d00	feat: generalized parent/child items with progress tracking (#70) ... * feat: generalize parent/child items — any item can have children with progress tracking Replaces the phases-only task widget with a generalized parent/child system. Any item (Phase, Idea, Doc, Task, etc.) can now be a parent of child items, getting automatic progress bars, burndown charts, status grouping, drag-drop reordering, and recursive expand/collapse up to 3 levels deep. DB: migrate link_type 'phase' → 'parent' (migration 023) Store: generalized methods (GetChildItems, GetItemProgress, SetParentLink with cycle detection), drop collection filters, per-child terminal status API: new /items/{slug}/children and /items/{slug}/progress endpoints Frontend: ChildItems, ChildChart, NestedChildren components replace PhaseTasks CLI: --parent flag (--phase kept as hidden alias), list/show/changelog updated Docs: CLAUDE.md, SKILL.md, pad-web updated for parent/child model Full backward compatibility: old 'phase' link_type, --phase flags, phase_id/ phase_ref JSON fields all still work as deprecated aliases. Closes PHASE-16 (9 tasks). * fix: update collection list page to use item_id from phasesProgress response The TS client return type changed from phase_id to item_id but the collection list page still referenced p.phase_id, causing svelte-check type errors in CI. * fix: address Codex review findings — PG migration, terminal statuses, metrics, CSRF resilience - Add PostgreSQL migration 003 to rename 'phase' links to 'parent' - Use schema-defined terminal statuses in GetAllItemProgress instead of hardcoded defaults - Pass computed terminal statuses from page to ChildItems component - Only special-case 'parent' field key when not defined in collection schema - Move MetricsMiddleware before Recoverer so panics are counted - Always mount ChildItems for SSE subscriptions even with 0 children - Exclude soft-deleted children from has_children enrichment query - Re-issue CSRF cookie when session is valid but cookie is missing - Show actual API error messages in create-item toasts	2026-04-07 09:52:31 -04:00
xarmian	8aa6481421	PHASE-12: Security Hardening for Pad Cloud (#67) ... * feat: enforce RBAC role checks on all mutation endpoints (TASK-150) Add requireMinRole helper and role enforcement to 30+ mutation handlers. Viewers are now blocked from all state-changing operations, editors can mutate items/docs/comments/views but not collections/webhooks/workspace settings, and only owners can perform administrative operations. Includes 11 integration tests with real auth covering viewer/editor/owner access across items, collections, documents, comments, agent roles, item links, and workspace operations. * fix: scope search results to user's workspaces (TASK-151) Search without a ?workspace= param previously returned results from all workspaces in the database. Now the handler resolves the authenticated user's workspace memberships and passes their IDs to the store query, ensuring results only include items from workspaces the user belongs to. Fresh installs (no users) retain unscoped search for backward compat. Includes integration test proving cross-workspace isolation. * fix: add webhook URL validation and SSRF protection (TASK-152) Webhook creation now validates URLs before accepting them: only HTTP(S) schemes allowed, embedded credentials rejected, private/reserved IPs blocked (loopback, RFC1918, link-local, cloud metadata 169.254.169.254), and hostnames are DNS-resolved to verify they don't point to private IPs. Defense-in-depth check also added to the dispatcher's deliver function so existing webhooks with unsafe URLs are blocked at delivery time. * feat: add CSRF protection with double-submit cookie pattern (TASK-153) Implements CSRF middleware that validates X-CSRF-Token header matches the pad_csrf cookie on all state-changing API requests. Bearer token auth, auth endpoints, and fresh installs are exempt. The frontend client reads the CSRF cookie and attaches the header on mutations. * feat: add per-endpoint rate limiting middleware (TASK-154) Adds IP-based rate limiting for auth endpoints (5/min login, 3/hr password reset, 5/hr registration) and user-based limits for API (100/min) and search (30/min). Uses golang.org/x/time/rate with automatic stale-entry cleanup. Adds chi RealIP middleware for correct client IP behind proxies. Returns 429 with Retry-After. * fix: sanitize error responses and remove PII from logs (TASK-155) Replace all writeError(500, err.Error()) calls with writeInternalError that logs the real error server-side and returns a generic message to clients. Remove email addresses, user IDs, and password reset tokens from log output to prevent PII leakage. * feat: add security headers, configurable CORS, and secure cookies (TASK-160) Add SecurityHeaders middleware (CSP, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy). Make CORS origins configurable via PAD_CORS_ORIGINS env var. Add PAD_SECURE_COOKIES for TLS deployments (sets Secure flag on session/CSRF cookies and enables HSTS). Also adds X-CSRF-Token to CORS allowed headers. * fix: address PR review — lazy router init and trusted IP for rate limits Fix two issues flagged by Codex: 1. CORS/HSTS config was ignored because setupRouter() ran in New() before SetCORSOrigins/SetSecureCookies were called. Now uses sync.Once to lazily build the router on first ServeHTTP/Listen. 2. Rate limiter read X-Real-IP directly from untrusted headers, allowing clients to spoof IPs. Now uses RemoteAddr only (which chimiddleware.RealIP already sanitizes from trusted proxy headers).	2026-04-05 10:26:00 -04:00
xarmian	367116b3a0	Unify relation fields and item links into single dependency system (#66) ... * feat: unify relation fields and item links into single dependency system Phase membership (Task→Phase) was previously stored as a UUID in the item's fields JSON, separate from the item_links table used for blocks/related/implements relationships. This unifies both into the item_links table so all item relationships use one system. Backend: - Add 'phase' link type to item_links constants - Migration 021: migrate existing phase field values to item_links, strip phase from fields JSON, remove phase field from tasks schema - Rewrite GetPhaseProgress, GetAllPhasesProgress, GetTasksForPhase to JOIN on item_links instead of json_extract(fields, '$.phase') - Add SetPhaseLink, ClearPhaseLink, GetPhaseForItem, GetTaskPhaseMap store helpers with single-phase constraint enforcement - Create/update handlers intercept 'phase' in fields and route through links system; enrich item responses with phase_id/ref/title - Dashboard orphan detection uses batch GetTaskPhaseMap lookup - Add PhaseID filter to ItemListParams for link-based list filtering Frontend: - Remove relation field type from FieldEditor (no longer needed) - Add link CRUD UI to item detail page: "Add relationship" inline form with link type picker + item search, delete buttons on existing links - Phase links appear in Relationships section as "In phase"/"Phase" - ItemCard reads phase from item.phase_title instead of fields.phase - FilterBar phase filter uses item.phase_id for client-side filtering - Add api.links.delete to frontend API client - Fix duplicate {#each} key on dashboard attention list Implements IDEA-106. * fix: remove relationLabels prop from BoardView, ListView, TableView ItemCard no longer accepts relationLabels (phase info now comes from item.phase_title), so remove the prop from all parent view components that were passing it through. Also remove unused .cell-relation CSS. * fix: address PR review — atomic SetPhaseLink, migration safety, error handling 1. Migration 021: remove deleted_at filters so archived tasks and tasks pointing to archived phases also get their phase links migrated. 2. SetPhaseLink: wrap delete+insert in a transaction so a failed insert doesn't leave the item with no phase link (previously non-atomic). 3. Create/update handlers: return proper HTTP errors when phase link operations fail instead of logging warnings and returning 200 OK.	2026-04-04 19:47:57 -04:00
xarmian	edcf2ae8b0	Board view improvements: independent scrolling, unified cards, lane reorder, new-item modal (#61) ... * feat: independent board scrolling, unified card style, lane reordering, and new-item modal - BoardView: switch from CSS grid to flex layout with independent per-column scrolling, matching the Roles board UX - ItemCard: redesign to match Roles board card style — top row with optional collection badge + ref, compact meta row with colored status/priority text - Roles board: replace inline card markup with shared ItemCard component, add HTML5 drag-and-drop lane reordering (persisted via new API endpoint), rename "Highlight Mine" to "Mine", add "+ New" button with collection picker modal - Backend: add PUT /roles/board/lane-order endpoint and UpdateAgentRoleOrder store method for batch role sort_order updates - Collection page: board view now fills viewport height so columns have bounded scroll areas * fix: resolve svelte-check type error and remove unused CSS selectors - Add null guard on lane.role in openEditModal onclick - Remove unused .role-edit-actions, .role-btn-create, .role-btn-cancel CSS * fix: correct lane reorder insert index when dragging forward After splicing out the source lane, downstream indices shift left by one. Adjust the insert index when srcIdx < dstIdx to place the lane at the correct drop target position.	2026-04-04 13:02:12 -04:00
xarmian	8b1b46ef22	feat: persistent card ordering within role board lanes ... Add role_sort_order column to items for independent ordering in the role board, separate from the collection sort_order. Backend: - Migration 020: role_sort_order INTEGER column on items - Item model, all SELECT/INSERT/Scan queries updated - PUT /roles/board/reorder endpoint for batch sort updates - Board API sorts items by role_sort_order within each lane Frontend: - Within-lane drag reorder persists via reorder API - Cross-lane moves also persist new sort order - Both operations are optimistic (no page refresh)	2026-04-04 14:00:21 +00:00