palinks

Verdict: APPROVED

Round 3 re-review of board item #1809. Previous reviews (review-1809-2026-07-05, review-1809-2026-07-05-r2) returned NEEDS_REFINEMENT. All findings are now resolved.

Previous Findings Resolution

• [x] [SCOPE] arch-palinks note (round 1) -- RESOLVED. arch-palinks note exists in pal-e-docs (note_type: architecture, project: palinks). Includes Mermaid diagram, component table with iOS entry, and key decisions.
• [x] [BODY] Repo placement (round 1) -- RESOLVED. Issue body reads: ldraney/palinks-ios (issue filed on palinks for centralized sprint tracking).
• [x] [BODY] ./build-testflight.sh reference (round 1) -- RESOLVED. AC item 4 reads: ./build-testflight.sh uploads build to TestFlight (wraps keychain fix + fastlane beta). Script exists in palinks-ios repo root (224 bytes).
• [x] [BODY] Directory name PalinksApp/ to Palinks/ (round 2) -- RESOLVED. File targets now correctly reference Palinks/, matching project.yml sources and actual repo directory structure.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, next step after #56
• [x] Repo -- ldraney/palinks-ios (centralized tracking documented)
• [x] User Story -- present
• [x] Context -- present
• [x] File Targets -- 2 files in palinks-ios + source file noted
• [x] Feature Flag -- none (appropriate for manual iOS build task)
• [x] Acceptance Criteria -- 6 items
• [x] Test Expectations -- manual (honest about non-automatable workflow)
• [x] Constraints -- present (MacBook, Apple team, icon source, build-testflight.sh)
• [x] Checklist -- present
• [x] Related -- project-palinks

Traceability

• [x] story:ios-distribution label -- Turbo Native iOS shell + TestFlight + App Store
• [x] story note verified -- found in project-palinks user-stories section (status: in progress)
• [x] arch:palinks label -- palinks component
• [x] arch note verified -- arch-palinks note exists in pal-e-docs (slug: arch-palinks, note_type: architecture). Includes iOS component in diagram and component table (palinks-ios: Turbo Native iOS shell, HotwireNative + Fastlane).
• [x] Forgejo issue -- ldraney/palinks#59, open

File Targets

• [x] palinks-ios/Palinks/Assets.xcassets/AppIcon.appiconset/AppIcon.png -- verified: directory path exists in repo (Palinks/Assets.xcassets/AppIcon.appiconset/ confirmed via Forgejo API). File to be created by copying app-icon.png. Currently only Contents.json exists in the appiconset directory.
• [x] palinks-ios/Palinks/Assets.xcassets/AppIcon.appiconset/Contents.json -- verified: file EXISTS in repo (confirmed via Forgejo API directory listing).
• [x] app-icon.png (palinks repo root, source) -- verified: 46KB file exists in palinks repo root.

Repo Placement

OK. Issue is filed on ldraney/palinks for centralized sprint tracking; ### Repo section explicitly documents that work is in ldraney/palinks-ios. Convention is consistent with sibling ios-distribution issues (#56, #57, #60, #61). The palinks-ios repo exists on Forgejo (not empty, default branch: main).

Dependencies

• #56 (iOS distribution: Create Turbo Native shell + Fastlane pipeline) -- CLOSED on Forgejo, in validation column on board. Direct predecessor per Lineage. Functionally complete.
• #57 (Update stale docs, add CLAUDE.md, iOS docs, and app icon) -- sibling in backlog. Minor overlap on app icon copy, but not a blocker. If #57 runs first, the icon copy in #59 becomes a verify step.
• #60 (Mobile CSS polish for iOS WKWebView) -- sibling in todo, can proceed in parallel.
• #61 (App Store metadata and privacy policy page) -- sibling in todo, downstream of this ticket (needs App Store Connect registration first).

Acceptance Criteria

6 criteria, all manual MacBook + device work. Sequentially ordered and clear. Agent cannot verify remotely (ticket honestly acknowledges with "Run command: n/a"). ./build-testflight.sh wrapper correctly referenced in AC item 4, matching the script in palinks-ios repo root (224 bytes).

Blast Radius

Limited. Work is confined to palinks-ios (icon copy + build/upload). No changes to the palinks Rails app. Same Apple Developer team (HAY64YD5PX) shared with landscaping-assistant-ios -- no conflict (different bundle IDs: com.palinks.app vs landscaping-assistant). No downstream consumers affected by initial TestFlight upload.

Decomposition Assessment

2 file targets in 1 repo. 6 acceptance criteria (tightly coupled as a single build-upload workflow). Estimated time: 15-30 minutes of manual MacBook work. No decomposition needed -- the task is a coherent manual workflow that cannot be meaningfully split.

Recommendations

No action needed.

Verdict: APPROVED

Re-review after scope refinement. All previously identified issues have been resolved. Scope is solid, all file targets verified, traceability complete.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, discovered during App Store sprint planning
• [x] Repo -- ldraney/palinks
• [x] User Story -- developer wants accurate docs and CLAUDE.md
• [x] Context -- explains what's stale and why
• [x] File Targets -- 7 modified + 3 created, correctly categorized
• [x] Feature Flag -- none (docs-only, appropriate)
• [x] Acceptance Criteria -- 7 items, all agent-verifiable
• [x] Test Expectations -- manual verification, appropriate for docs
• [x] Constraints -- port 80 constraint documented, references issue #29
• [x] Checklist -- PR #58 opened, no unrelated changes
• [x] Related -- project-palinks referenced

Traceability

• [x] story:ios-distribution label -- present on board item #1808
• [x] story note verified -- found in project-palinks user-stories section: "Turbo Native iOS shell + TestFlight + App Store (in progress)"
• [x] arch:palinks label -- present on board item #1808
• [x] arch note verified -- arch-palinks note exists in pal-e-docs (updated 2026-07-06), includes Mermaid diagram, component table, key decisions, and current access methods
• [x] Forgejo issue -- ldraney/palinks#57, open

File Targets

Modified files (all verified to exist on main):

• [x] docs/architecture.md -- verified: exists, contains stale content (correctly says "no nginx sidecar" but needs custom domain section)
• [x] docs/infrastructure.md -- verified: exists, custom domain status says "under investigation" (stale, should be "live")
• [x] docs/custom-domain.md -- verified: exists, "Remaining Work" checklist has items already completed (DNS, Caddy, config.hosts)
• [x] docs/pipeline.md -- verified: exists, contains ruby-rails-runtime spike section (lines 142+) needing "not yet implemented, see #29" annotation
• [x] docs/rails-notes.md -- verified: exists, line 92 incorrectly references nginx, line 80 says Stimulus "not used yet" (stale: sortable_controller.js is active)
• [x] docs/user-stories.md -- verified: exists, needs implementation status annotations
• [x] README.md -- verified: exists, missing palinks.app URL and palinks-ios link

Created files (all verified to NOT exist on main):

• [x] CLAUDE.md -- verified: does not exist on main, correctly marked as created
• [x] docs/ios.md -- verified: does not exist on main, correctly marked as created
• [x] app-icon.png -- verified: does not exist on main, correctly marked as created

Repo Placement

Correct. Issue filed on ldraney/palinks, all file targets are in ldraney/palinks. Single repo, no cross-repo concerns.

Dependencies

• Issue #29 (Swap Dockerfile runtime to ruby-rails-runtime) -- referenced in constraints for port 80 vs 3000. Not a blocker; this ticket maintains port 80.
• PR #58 already opened with the implementation.
• No items in in_progress column. Board item #1530 (issue #56, iOS distribution parent) is in validation.
• Sibling ios-distribution tickets (#59, #60, #61) are in backlog -- no ordering conflicts.

Acceptance Criteria

7 criteria, all agent-verifiable:

• [x] "Custom domain status reflects reality" -- verifiable via grep for stale status strings
• [x] "No nginx references remain in docs" -- verifiable via grep
• [x] "CLAUDE.md exists with build commands and architecture" -- verifiable via file existence and content check
• [x] "docs/ios.md covers Turbo Native workflow" -- verifiable via file existence and content check
• [x] "User stories annotated with implementation status" -- verifiable via content check
• [x] "1024x1024 app icon included" -- verifiable via file existence and dimension check
• [x] "README links to palinks.app and palinks-ios" -- verifiable via grep

Blast Radius

Minimal. Documentation-only changes with no runtime code impact. No downstream consumers affected. The arch-palinks note in pal-e-docs references port 3000 (aspirational, per issue #29), which is consistent -- in-repo docs maintain port 80 until #29 is implemented.

Decomposition Assessment

7 acceptance criteria (technically exceeds the 5 AC threshold). Decomposition is not needed because:

• All changes are documentation-only in a single repo
• Changes are thematically coherent (stale doc update sprint)
• Each AC is a small, independent edit (grep-and-replace or new file)
• Work is already complete -- PR #58 is open with all changes
• Estimated agent work: 3-5 minutes
• 3 story points is appropriate

Re-review Fixes Verified

• [x] Port 80 constraint -- Dockerfile confirms PORT=80, EXPOSE 80. Issue correctly says port stays at 80.
• [x] Pipeline.md spike -- issue says "not yet implemented (issue #29)", spike section exists at line 142+.
• [x] File targets -- correctly differentiate "modified" (7 files exist on main) vs "created" (3 files absent from main).
• [x] Nginx context -- issue correctly states nginx "doesn't exist in the stack"; rails-notes.md has the stale reference to fix.
• [x] arch-palinks note -- exists in pal-e-docs, updated 2026-07-06, comprehensive with diagram, components, decisions, access methods.

Recommendation

No action needed. Scope is complete and accurate.

Verdict: APPROVED

Re-review of board item #1811 after scope refinement. All 4 recommendations from review-1811-2026-07-05 have been addressed.

Previous Review Resolution

• [x] [BODY] Add missing file target app/controllers/pages_controller.rb -- FIXED: now listed as "new controller for static pages"
• [x] [BODY] Remove 5 stale palinks-ios file targets -- FIXED: separated into "Files to create" vs "Files that already exist (no changes needed)"
• [x] [BODY] Update AC to reflect actual remaining work -- FIXED: 5 specific ACs now correctly scoped (PagesController AC added, metadata AC narrowed to description.txt only)
• [x] [SCOPE] Create architecture note arch-palinks -- FIXED: note exists in pal-e-docs (note ID 1885, type: architecture, project: palinks)

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- present (Standalone)
• [x] Repo -- present (ldraney/palinks and ldraney/palinks-ios)
• [x] User Story -- present
• [x] Context -- present, explains Apple requirements and what already exists from #56
• [x] File Targets -- present, accurate (see below)
• [x] Feature Flag -- "none" (appropriate for a static page)
• [x] Acceptance Criteria -- present (5 items)
• [x] Test Expectations -- present
• [x] Constraints -- present
• [x] Checklist -- present
• [x] Related -- present

Traceability

• [x] story:ios-distribution label -- "Turbo Native iOS shell + TestFlight + App Store (in progress)"
• [x] story note verified -- found in project-palinks user-stories section
• [x] arch:palinks label -- present on board item
• [x] arch note verified -- arch-palinks note exists in pal-e-docs (includes iOS component in diagram)
• [x] Forgejo issue -- ldraney/palinks#61, open

File Targets

palinks (Rails) -- verified:

• [x] app/controllers/pages_controller.rb -- does not exist, to be created. No existing PagesController in codebase. Correct.
• [x] app/views/pages/privacy.html.erb -- does not exist, to be created. Correct.
• [x] config/routes.rb -- exists, no /privacy route yet. Current routes: resources :links, health check, root. Correct target for modification.

palinks-ios -- cross-repo (not verifiable from this worktree):

• [x] fastlane/metadata/en-US/description.txt -- to be created. Reasonable based on #56 having created sibling files.

Already-existing files correctly documented as no-change:

• [x] privacy_url.txt, support_url.txt, release_notes.txt, copyright.txt, Deliverfile -- all listed as "already set" from #56

Repo Placement

OK. Issue filed on palinks for centralized tracking. Cross-repo work is minimal (1 text file in palinks-ios). Documented in Repo section.

Dependencies

• #56 (Turbo Native shell + Fastlane pipeline) -- in validation column. Created the existing metadata files. Not a blocker.
• #59 (TestFlight beta upload) -- backlog. Likely depends on #61 for /privacy URL. Not documented but acceptable since it's downstream.
• #60 (Mobile CSS polish) -- backlog. Independent.
• #57 (Update stale docs) -- backlog. Independent.
• No blockers for #61.

Acceptance Criteria

• 5 criteria, well-scoped
• AC 1 ("/privacy route returns a basic privacy policy page") -- agent-verifiable via curl or Rails test
• AC 2 ("PagesController serves the privacy view") -- agent-verifiable by checking controller exists and routes correctly
• AC 3 ("description.txt created in palinks-ios") -- agent-verifiable by file check (requires palinks-ios repo access)
• AC 4 ("fastlane prepare_metadata uploads successfully on MacBook") -- manual only, correctly listed in Test Expectations as manual
• AC 5 ("Privacy policy states: no personal data collected") -- agent-verifiable by reading page content

Blast Radius

Low. No existing privacy, pages, or policy patterns in the codebase. New controller, view, and route are fully isolated. No downstream consumers affected.

Decomposition Assessment

4 files across 2 repos (3 in palinks, 1 in palinks-ios). 5 acceptance criteria. Estimated agent work: under 5 minutes. No decomposition needed.

Recommendation

No action needed. All previous recommendations resolved. Scope is solid for agent execution.

Verdict: NEEDS_REFINEMENT

Re-review of board item #1809. Previous review (review-1809-2026-07-05) returned NEEDS_REFINEMENT with three findings. Two of three are now resolved; one new issue found.

Previous Findings Resolution

• [x] [SCOPE] arch-palinks note -- RESOLVED. arch-palinks note now exists in pal-e-docs (note_type: architecture, project: palinks). Includes Mermaid diagram, component table, key decisions, and iOS component entry.
• [x] [BODY] Repo placement -- RESOLVED. Issue body now reads: ldraney/palinks-ios (issue filed on palinks for centralized sprint tracking). Convention is documented.
• [x] [BODY] ./build-testflight.sh reference -- RESOLVED. AC item 4 now reads: ./build-testflight.sh uploads build to TestFlight (wraps keychain fix + fastlane beta).

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, next step after #56
• [x] Repo -- ldraney/palinks-ios (centralized tracking documented)
• [x] User Story -- present
• [x] Context -- present
• [x] File Targets -- 2 files in palinks-ios + source file noted
• [x] Feature Flag -- none (appropriate for manual iOS build task)
• [x] Acceptance Criteria -- 6 items
• [x] Test Expectations -- manual (honest about non-automatable workflow)
• [x] Constraints -- present (MacBook, Apple team, icon source, build-testflight.sh)
• [x] Checklist -- present
• [x] Related -- project-palinks

Traceability

• [x] story:ios-distribution label -- Turbo Native iOS shell + TestFlight + App Store
• [x] story note verified -- found in project-palinks user-stories section (status: in progress)
• [x] arch:palinks label -- palinks component
• [x] arch note verified -- arch-palinks note exists in pal-e-docs (slug: arch-palinks, note_type: architecture, updated 2026-07-06). Includes iOS component in diagram and component table.
• [x] Forgejo issue -- ldraney/palinks#59, open

File Targets

• [ ] palinks-ios/PalinksApp/Assets.xcassets/AppIcon.appiconset/AppIcon.png -- ISSUE: Directory PalinksApp does not exist. The actual directory is Palinks (confirmed via project.yml target sources and Forgejo API tree listing). Correct path: Palinks/Assets.xcassets/AppIcon.appiconset/AppIcon.png (file to be created).
• [ ] palinks-ios/PalinksApp/Assets.xcassets/AppIcon.appiconset/Contents.json -- ISSUE: Same directory name error. Correct path: Palinks/Assets.xcassets/AppIcon.appiconset/Contents.json (file exists in repo).
• [x] app-icon.png (palinks repo root, source) -- verified: 46KB file exists.

Repo Placement

OK. Issue is filed on ldraney/palinks for centralized sprint tracking; ### Repo section explicitly documents that work is in ldraney/palinks-ios. The palinks-ios repo exists on Forgejo (not empty, has PR #1 merged). Convention is consistent with sibling ios-distribution issues (#56, #57, #60, #61).

Dependencies

• #56 (iOS distribution: Create Turbo Native shell + Fastlane pipeline) -- closed on Forgejo, in validation column on board. Direct predecessor per Lineage section. Should complete validation before #59 moves to in_progress.
• #57 (Update stale docs, add CLAUDE.md, iOS docs, and app icon) -- sibling in backlog, not a blocker.
• #60 (Mobile CSS polish for iOS WKWebView) -- sibling in backlog, can proceed in parallel.
• #61 (App Store metadata and privacy policy page) -- downstream, depends on this ticket completing.

Acceptance Criteria

6 criteria, all manual MacBook + device work. Sequentially ordered and clear. Agent cannot verify remotely (ticket honestly acknowledges with "Run command: n/a"). ./build-testflight.sh wrapper now correctly referenced in AC item 4, matching the script that exists in the palinks-ios repo root (224 bytes).

Blast Radius

Limited. Work is confined to palinks-ios (icon copy + build). No changes to the palinks Rails app. Same Apple Developer team (HAY64YD5PX) shared with landscaping-assistant-ios -- no conflict expected (different bundle IDs: com.palinks.app vs landscaping-assistant's). No downstream consumers affected by initial TestFlight upload.

Decomposition Assessment

2 file targets in 1 repo. 6 acceptance criteria (tightly coupled as a single build-upload workflow). Estimated time: 15-30 minutes of manual MacBook work. No decomposition needed.

Recommendations

• [BODY] Fix file target paths: PalinksApp/ does not exist in the palinks-ios repo. The correct directory is Palinks/ (per project.yml target sources). Update both paths:
  • PalinksApp/Assets.xcassets/AppIcon.appiconset/AppIcon.png --> Palinks/Assets.xcassets/AppIcon.appiconset/AppIcon.png
  • PalinksApp/Assets.xcassets/AppIcon.appiconset/Contents.json --> Palinks/Assets.xcassets/AppIcon.appiconset/Contents.json

Verdict: APPROVED

Re-review of board item #1810. Prior finding (arch-palinks note missing) has been resolved -- arch-palinks note now exists in pal-e-docs. No new issues found.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Related to ldraney/palinks #56
• [x] Repo -- ldraney/palinks
• [x] User Story -- present
• [x] Context -- present
• [x] File Targets -- present (2 files to modify, exclusions listed)
• [x] Feature Flag -- none (appropriate for CSS-only change)
• [x] Acceptance Criteria -- 6 items
• [x] Test Expectations -- manual visual testing specified
• [x] Constraints -- ror-css-guide, CSS-only, Safari + WKWebView
• [x] Checklist -- present
• [x] Related -- project-palinks referenced

Traceability

• [x] story:ios-distribution label -- Turbo Native iOS shell + TestFlight + App Store
• [x] story note verified -- found in project-palinks user-stories section (status: in progress)
• [x] arch:palinks label -- main application architecture
• [x] arch note verified -- arch-palinks note exists in pal-e-docs (slug: arch-palinks, architecture type, project: palinks)
• [x] Forgejo issue -- ldraney/palinks#60, open

File Targets

• [x] app/assets/stylesheets/application.css -- verified: exists, 493 lines, currently has no safe-area insets, no viewport-fit, no touch-target minimums. Single breakpoint at 600px. Confirms need for mobile polish.
• [x] app/views/layouts/application.html.erb -- verified: exists, line 5 has <meta name="viewport" content="width=device-width,initial-scale=1"> missing viewport-fit=cover. Confirms ticket scope.

Repo Placement

OK -- issue filed on ldraney/palinks, all file targets are in the palinks repo. No cross-repo work needed.

Dependencies

• Board item #1530 (issue #56) -- iOS distribution: Turbo Native shell + Fastlane pipeline -- in validation column. This is the parent work that wraps palinks in WKWebView. Prerequisite satisfied.
• Board items #1809 (issue #59, TestFlight beta) and #1811 (issue #61, App Store metadata) are downstream -- they depend on this CSS polish being done first.
• Lineage section documents the relationship to #56.

Acceptance Criteria

6 ACs, all verifiable:

• Viewport meta tag with viewport-fit=cover -- checkable by reading HTML
• CSS env(safe-area-inset-*) usage -- checkable by grepping CSS
• 44x44pt touch targets -- checkable via CSS inspection
• No horizontal scroll -- testable at specified widths
• Link cards at 375px -- visual verification
• Filter tabs on mobile -- visual verification

Manual testing plan is appropriate for visual/CSS work. Test widths specified (375px, 390px, 428px).

Blast Radius

Low. CSS-only and viewport meta changes. All additive (safe-area padding, touch-target minimums). No backend changes. All pages in the app benefit from the improvements. No risk to existing functionality.

Decomposition Assessment

No decomposition needed. 2 file targets in 1 repo. 6 ACs (borderline on the >5 threshold) but all are cohesive CSS modifications in the same files. Estimated agent work: well under 5 minutes.

Recommendation

No action needed. Prior finding resolved. Ticket is ready for implementation.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag -- none (appropriate for docs-only)
• [x] Acceptance Criteria -- 6 items
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

All required sections present.

Traceability

• [x] story:ios-distribution label -- Turbo Native iOS shell + TestFlight + App Store
• [x] story note verified -- found in project-palinks user-stories section ("in progress")
• [x] arch:palinks label -- present on board item
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-palinks in pal-e-docs
• [x] Forgejo issue -- ldraney/palinks#57, open

File Targets

• [x] docs/architecture.md -- exists
• [x] docs/infrastructure.md -- exists
• [x] docs/custom-domain.md -- exists
• [x] docs/pipeline.md -- exists
• [x] docs/rails-notes.md -- exists
• [x] docs/user-stories.md -- exists
• [ ] CLAUDE.md -- ISSUE: listed as "create" but already exists (committed in f602330). References port 3000 but Dockerfile sets PORT=80
• [ ] docs/ios.md -- ISSUE: listed as "create" but already exists (committed in f602330)
• [ ] app-icon.png -- ISSUE: listed as "create" but already exists (46k, committed in f602330)

Critical finding: Commit f602330 ("Update docs for current state, add CLAUDE.md, iOS docs, and app icon") on a worktree branch has already done this work, but introduced inaccuracies. The docs now say port 3000 everywhere, but the Dockerfile still sets PORT=80 and EXPOSE 80. Puma binds to ENV.fetch("PORT", 3000), so production actually serves on port 80.

Repo Placement

OK. Issue filed on ldraney/palinks, work is docs-only in the palinks repo. No cross-repo changes needed.

Dependencies

• Board item #1530 (issue #56, 8 pts) is in validation column, same story:ios-distribution. This is the iOS distribution implementation ticket. No hard dependency -- docs can be written independently.
• Board items #1809, #1810, #1811 (issues #59, #60, #61) are also in backlog with story:ios-distribution. No blocking relationship for docs work.
• No dependencies documented in the issue. None needed -- docs work is independent.

Acceptance Criteria

• [ ] AC #1: "All port 80 references updated to 3000" -- INVALID. The Dockerfile sets PORT=80 and EXPOSE 80. Port 80 IS the current reality. The spike in pipeline.md recommended switching to 3000 but this has not been implemented. The pipeline.md spike section header falsely claims "Recommendations implemented: palinks uses single-stage build from ruby-rails-build, serves on port 3000, CMD is bundle exec puma." All three claims are wrong: runtime stage uses ruby:3.4.9-slim (not ruby-rails-runtime), port is 80 (not 3000), CMD is rails server (not bundle exec puma).
• [x] AC #2: "Custom domain status reflects reality (live)" -- verifiable, docs/infrastructure.md already says "Custom domain is live"
• [x] AC #3: "CLAUDE.md exists with build commands and architecture" -- verifiable
• [x] AC #4: "docs/ios.md covers Turbo Native workflow" -- verifiable
• [x] AC #5: "User stories annotated with implementation status" -- verifiable, docs/user-stories.md already annotated
• [x] AC #6: "1024x1024 app icon included" -- verifiable (file exists, 46k)

Blast Radius

Docs-only ticket. No runtime code changes. No downstream consumers affected. Low blast radius.

One concern: if docs are updated to say port 3000 but the Dockerfile still uses port 80, future agents working on deployment configuration could be misled by the inaccurate docs.

Decomposition Assessment

9 file targets (6 modify + 3 create) across 1 repo. 6 acceptance criteria. Estimated agent work under 5 minutes for docs-only changes. No decomposition needed.

Recommendation

• [BODY] AC #1 is wrong. The Dockerfile sets PORT=80 -- port 80 is the production reality. Change AC to: "Docs accurately reflect current port configuration" (keep port 80 in docs). Alternatively, create a separate code ticket to implement the spike recommendations (switch Dockerfile to ruby-rails-runtime, port 3000, bundle exec puma) BEFORE this docs ticket updates port references.
• [BODY] Fix pipeline.md spike section header: "Recommendations implemented" is false. Should read "Recommendations analyzed, implementation pending" or reference a future implementation ticket.
• [BODY] The three "Files to create" (CLAUDE.md, docs/ios.md, app-icon.png) already exist in commit f602330. If this commit is the implementation of this ticket, the issue should note that. If f602330 predates this ticket, the file targets section should say "modify" not "create."
• [SCOPE] Create architecture note arch-palinks for component palinks in pal-e-docs.
• [BODY] Context section claims "nginx is referenced (doesn't exist)" but no nginx references were found in any docs file. Remove or clarify this claim.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, next step after #56
• [x] Repo -- ldraney/palinks-ios
• [x] User Story -- present
• [x] Context -- present
• [x] File Targets -- 2 files in palinks-ios
• [x] Feature Flag -- none (appropriate for iOS build task)
• [x] Acceptance Criteria -- 6 items
• [x] Test Expectations -- manual (honest about non-automatable workflow)
• [x] Constraints -- present (MacBook requirement, Apple team, icon source)
• [x] Checklist -- present
• [x] Related -- project-palinks

Traceability

• [x] story:ios-distribution label -- Turbo Native iOS shell + TestFlight + App Store
• [x] story note verified -- found in project-palinks user-stories section (status: in progress)
• [x] arch:palinks label -- palinks component
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-palinks for component palinks
• [x] Forgejo issue -- ldraney/palinks#59, open

File Targets

• [?] palinks-ios/PalinksApp/Assets.xcassets/AppIcon.appiconset/AppIcon.png -- cannot verify (palinks-ios not cloned to this machine; repo exists on Forgejo)
• [?] palinks-ios/PalinksApp/Assets.xcassets/AppIcon.appiconset/Contents.json -- cannot verify (same reason)
• [x] app-icon.png (source, palinks repo root) -- verified: 46KB file exists

Note: The issue correctly states "No files in the palinks Rails repo are modified."

Repo Placement

MISMATCH: The Forgejo issue is filed on ldraney/palinks but ### Repo says ldraney/palinks-ios. The palinks-ios repo exists on Forgejo (confirmed via API). All five ios-distribution issues (#56, #57, #59, #60, #61) follow this pattern of centralized tracking on the main palinks repo. If this is intentional, consider documenting the convention. Otherwise, refile on palinks-ios.

Dependencies

• #56 (iOS distribution: Create Turbo Native shell + Fastlane pipeline) -- CLOSED on Forgejo but in validation column on board. This is the direct predecessor per the Lineage section. Should complete validation before #59 moves to todo.
• #57 (Update stale docs, add CLAUDE.md, iOS docs, and app icon) -- sibling in backlog, not a blocker but related (docs/ios.md already partially covers the workflow)
• #60 (Mobile CSS polish for iOS WKWebView) -- sibling in backlog, can proceed in parallel
• #61 (App Store metadata and privacy policy page) -- downstream, depends on this ticket completing

Acceptance Criteria

6 criteria, all manual MacBook + device work. An agent cannot fully verify these remotely. The ticket honestly acknowledges this with "Run command: n/a" in Test Expectations. The criteria are clear and sequentially ordered. Minor note: docs/ios.md references ./build-testflight.sh as a wrapper script, while the AC uses raw fastlane beta -- either approach works but the wrapper handles keychain issues automatically.

Blast Radius

Limited. The work is confined to the palinks-ios repo (icon copy only). The palinks Rails app is unchanged. docs/ios.md already documents the full build/deploy workflow. No downstream consumers are affected by the initial TestFlight upload. The same Apple Developer team (HAY64YD5PX) is shared with landscaping-assistant-ios -- no conflict expected since they use different bundle IDs.

Decomposition Assessment

2 file targets in 1 repo. 6 acceptance criteria (slightly over 5 threshold but tightly coupled as a single build-upload workflow). Estimated time: 15-30 minutes of manual MacBook work. No decomposition needed -- the task is a coherent manual workflow that cannot be meaningfully split.

Recommendations

• [SCOPE] Create architecture note arch-palinks for the palinks component. This is a systemic gap affecting all palinks board items, not just this ticket.
• [BODY] Repo placement: Issue is filed on ldraney/palinks but work is in ldraney/palinks-ios. Either refile on palinks-ios or add a note in Lineage explaining the centralized-tracking convention.
• [BODY] Consider referencing ./build-testflight.sh wrapper from docs/ios.md in the AC, since it handles keychain unlock automatically.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- present
• [x] Repo -- present (ldraney/palinks and ldraney/palinks-ios)
• [x] User Story -- present
• [x] Context -- present
• [x] File Targets -- present (but has accuracy issues, see below)
• [x] Feature Flag -- "none" (appropriate for a static page)
• [x] Acceptance Criteria -- present (4 items)
• [x] Test Expectations -- present
• [x] Constraints -- present
• [x] Checklist -- present
• [x] Related -- present

Traceability

• [x] story:ios-distribution label -- "Turbo Native iOS shell + TestFlight + App Store (in progress)"
• [x] story note verified -- found in project-palinks user-stories section
• [x] arch:palinks label -- present on board item
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-palinks. Search returned no results.
• [x] Forgejo issue -- ldraney/palinks#61, open

File Targets

palinks (Rails) -- needs work:

• [x] app/views/pages/privacy.html.erb -- valid: file does not exist yet, needs creation
• [x] config/routes.rb -- valid: file exists, needs /privacy route added
• [ ] app/controllers/pages_controller.rb -- MISSING FROM TARGETS: Rails requires a controller to serve views. No PagesController exists. The ticket must add this file target.

palinks-ios -- mostly already done:

• [x] fastlane/metadata/en-US/description.txt -- valid: file does not exist (404), needs creation
• [ ] fastlane/metadata/en-US/privacy_url.txt -- STALE: already exists with "https://palinks.app/privacy"
• [ ] fastlane/metadata/en-US/support_url.txt -- STALE: already exists with "https://palinks.app"
• [ ] fastlane/metadata/en-US/release_notes.txt -- STALE: already exists with release notes
• [ ] fastlane/metadata/copyright.txt -- STALE: already exists with "2026 PAL Enterprises"
• [ ] fastlane/Deliverfile -- STALE: already exists with age rating and content rights configured

5 of 6 palinks-ios file targets already exist with the expected content, created during issue #56 (Turbo Native shell + Fastlane pipeline, now in validation/closed).

Repo Placement

Issue filed on ldraney/palinks but scopes work across both palinks and palinks-ios. Since most palinks-ios work is already complete from issue #56, the remaining cross-repo work is trivial (one file: description.txt). Consider narrowing scope to palinks-only and handling description.txt as part of issue #59 (TestFlight beta upload), or keeping it here but correcting the file targets.

Dependencies

• #56 (Turbo Native shell + Fastlane pipeline) -- validation/closed. Created the existing fastlane metadata files. Not a blocker.
• #59 (Build and upload first TestFlight beta) -- backlog. Likely depends on #61 having the /privacy page deployed so Apple review can access it.
• #60 (Mobile CSS polish for iOS WKWebView) -- backlog. Independent.
• #57 (Update stale docs, add CLAUDE.md, iOS docs, and app icon) -- backlog. Independent.
• No blockers for #61 itself. No dependencies documented in the issue.

Acceptance Criteria

• 4 criteria, reasonable scope
• AC 1 ("/privacy route returns a basic privacy policy page") -- agent-verifiable via curl or test
• AC 2 ("fastlane metadata files populated for App Store") -- agent-verifiable by checking file existence, but 5 of 6 already done
• AC 3 ("fastlane prepare_metadata uploads successfully") -- NOT agent-verifiable, requires MacBook with Apple credentials
• AC 4 ("Privacy policy states: no personal data collected") -- agent-verifiable by checking page content
• Missing: no AC for the PagesController existing or for proper HTML structure/layout of the privacy page

Blast Radius

Low. No existing privacy, policy, or pages patterns in the codebase. The new route, controller, and view are fully isolated. No downstream consumers affected. No similar patterns to check in sibling services.

Decomposition Assessment

Actual remaining work: 3 files in palinks (controller + view + routes modification), 1 file in palinks-ios (description.txt). 4 acceptance criteria. Estimated agent work: under 5 minutes. No decomposition needed. The issue overstates scope due to stale file targets.

Recommendation

• [BODY] Add missing file target: app/controllers/pages_controller.rb -- Rails requires a controller to serve the privacy view
• [BODY] Remove or mark as "already exists" the 5 stale palinks-ios file targets (privacy_url.txt, support_url.txt, release_notes.txt, copyright.txt, Deliverfile) -- these were created by issue #56
• [BODY] Update AC 2 to reflect that only description.txt needs creation in palinks-ios
• [SCOPE] Create architecture note arch-palinks for the palinks component -- the label references a note that does not exist in pal-e-docs

Verdict: NEEDS_REFINEMENT

Board item #1810 — Mobile CSS polish for iOS WKWebView (Forgejo issue ldraney/palinks#60). Scope is solid and file targets are verified, but the backing architecture note arch-palinks is missing from pal-e-docs.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Related to ldraney/palinks #56
• [x] Repo — ldraney/palinks
• [x] User Story — present and well-formed
• [x] Context — adequate background on WKWebView wrapping
• [x] File Targets — 2 files to modify, 2 exclusion zones
• [x] Feature Flag — none (appropriate for CSS-only work)
• [x] Acceptance Criteria — 6 items
• [x] Test Expectations — manual visual testing acknowledged
• [x] Constraints — ror-css-guide, CSS-only, Safari+WKWebView
• [x] Checklist — present
• [x] Related — present

Traceability

• [x] story:ios-distribution label — Turbo Native iOS shell + Fastlane pipeline
• [x] story note verified — found in project-palinks user-stories section
• [x] arch:palinks label — main application architecture
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-palinks for the palinks application component
• [x] Forgejo issue — ldraney/palinks#60, open

File Targets

• [x] app/assets/stylesheets/application.css — verified: 493 lines, contains design tokens, responsive breakpoint at line 488, existing touch-action on drag handle at line 181. No safe-area or viewport-fit CSS currently present — confirms work is needed.
• [x] app/views/layouts/application.html.erb — verified: 42 lines, viewport meta tag at line 5 reads width=device-width,initial-scale=1. Missing viewport-fit=cover — confirms AC #1 is actionable.

Repo Placement

OK. Issue filed on ldraney/palinks, repo section says ldraney/palinks, all file targets are in palinks. Single-repo change.

Dependencies

• Item #1530 (issue #56, 8pt) — parent iOS distribution ticket, currently in validation column. This ticket's lineage references it. CSS polish can proceed independently; no blocker.
• Sibling ios-distribution items (#1808/#57, #1809/#59, #1811/#61) — all in backlog. No ordering dependency documented or detected.
• No items currently in in_progress that would conflict.

Acceptance Criteria

6 criteria, all assessable:

• AC 1 (viewport-fit=cover) — code-verifiable via grep. Currently missing from meta tag, confirms work needed.
• AC 2 (env(safe-area-inset-*)) — code-verifiable via grep. Currently absent from CSS, confirms work needed.
• AC 3 (44x44pt touch targets) — partially code-verifiable (min-height/min-width checks), visual confirmation needed. Nav tabs currently have padding var(--spacing-xs) var(--spacing-sm) (4px 8px) which is well under 44pt — confirms work needed.
• AC 4 (no horizontal scroll) — visual testing required. Current container uses max-width: 48rem with padding, should be fine but needs verification.
• AC 5 (375px rendering) — visual testing required. Current grid is 1-column below 600px, reasonable baseline.
• AC 6 (filter tabs on mobile) — visual testing required. Navbar uses flex with 5 items (Links, Popular, Favorites, Other, + Add) — likely to overflow on narrow screens. Issue should consider whether wrapping or horizontal scroll is the expected solution.

Test expectations appropriately acknowledge "Run command: n/a (visual testing)" — acceptable for CSS-only work. All criteria are verifiable post-implementation.

Blast Radius

• application.css is the single stylesheet for all views. Changes affect 8 templates: layout, flash partial, index, show, _link partial, _form partial, new, edit.
• Form templates (_form.html.erb, new.html.erb, edit.html.erb) are not in file targets but use shared button and form classes. Current form inputs are full-width, likely fine on mobile already.
• No sibling services — palinks is the only Rails app; no blast radius beyond this repo.
• PWA manifest (pwa/manifest.json.erb) exists but is not affected by CSS changes.

Decomposition Assessment

2 file targets in 1 repo — under threshold. 6 acceptance criteria — marginally over the 5-item threshold, but all criteria are tightly coupled CSS concerns in the same 2 files. Estimated agent work is 3-5 minutes. No decomposition needed — splitting would create artificial boundaries in cohesive CSS work.

Recommendation

• [SCOPE] Create architecture note arch-palinks for the palinks application component. This note is referenced by the arch:palinks label on this and 20+ other board items but does not exist in pal-e-docs.

Verdict: APPROVED

Re-review of review-1530-2026-06-20. Previous verdict was NEEDS_REFINEMENT due to one [BODY] finding. That finding has been addressed.

Previous Finding Resolution

• [x] [BODY] Fix reference path -- RESOLVED. Issue body File Targets section previously referenced ~/landscaping-assistant-ios/ (local path that does not exist). Now reads: https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant-ios.git -- clone from Forgejo as template (no local clone exists; agent must git clone this first). The fix explicitly instructs the agent to clone from Forgejo rather than assuming a local checkout.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, follows landscaping-assistant-ios pattern
• [x] Repo -- ldraney/palinks (issue tracker), ldraney/palinks-ios (implementation)
• [x] User Story -- well-formed As/I want/So that
• [x] Context -- sufficient background, references proven pattern
• [x] File Targets -- CREATE targets for new repo, reference files listed with Forgejo clone URL
• [x] Feature Flag -- None (appropriate for native packaging)
• [x] Acceptance Criteria -- 6 criteria
• [x] Test Expectations -- manual test steps, run command
• [x] Constraints -- clear guardrails
• [x] Checklist -- 4 items
• [x] Related -- project and template references

Traceability

• [x] story:ios-distribution label -- "Turbo Native iOS shell + Fastlane pipeline (same pattern as landscaping-assistant)"
• [x] story note verified -- found in project-palinks user-stories section
• [x] arch:palinks label -- palinks architecture component
• [x] arch note verified -- arch-palinks note exists in pal-e-docs (slug: arch-palinks, architecture type, active)
• [x] Forgejo issue -- ldraney/palinks#56, open

File Targets

This issue creates a NEW repo (palinks-ios). No existing files to modify. Verification of reference targets:

• [x] landscaping-assistant-ios -- EXISTS on Forgejo (HTTP 200), referenced as clone URL in issue body
• [x] ~/macbook-ssh/docs/ios-pipeline.md -- verified, 12k
• [x] ~/macbook-ssh/docs/dev-build-guide.md -- verified, 7.3k
• [x] ~/secrets/apple-developer/ -- verified, contains AuthKey_2A6BSP3H76.p8
• [x] palinks-ios repo does NOT yet exist on Forgejo (HTTP 404) -- correct, issue creates it

Repo Placement

OK. Issue filed on ldraney/palinks (issue tracker), implementation creates ldraney/palinks-ios (new repo). Explicitly documented in the Repo section. No cross-repo mismatch.

Dependencies

• [x] palinks.app must be live -- VERIFIED: HTTP 200
• [x] landscaping-assistant-ios must exist as template -- VERIFIED: repo exists on Forgejo
• [x] Apple Developer credentials -- VERIFIED: ~/secrets/apple-developer/ contains key file
• [x] No board items blocking this ticket -- all items in backlog or done; one item in todo (link groups #1407) is unrelated
• [ ] MacBook accessible via SSH over Tailscale -- not verified (requires network test), documented in macbook-ssh docs

Acceptance Criteria

6 criteria. 4 are agent-verifiable, 2 require manual device testing (dev build install, TestFlight WKWebView load). This is inherent to iOS development and acceptable.

Blast Radius

Low. Standalone new repo wrapping existing web app. No changes to palinks Rails app or infrastructure. Turbo Native model means zero coupling beyond the URL constant.

Decomposition Assessment

8 points, 6 AC, 1 new repo. Estimated agent work 10-15 minutes due to cross-machine SSH build steps. Borderline on the 5-minute rule, but scope is well-defined and heavily templated from landscaping-assistant-ios. Operator accepted this assessment in the first review by proceeding with refinement rather than requesting decomposition. No decomposition needed.

Recommendation

No action needed. Previous [BODY] finding resolved. Ticket is ready for implementation.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, follows landscaping-assistant-ios pattern
• [x] Repo -- ldraney/palinks (issue tracker), ldraney/palinks-ios (implementation)
• [x] User Story -- well-formed As/I want/So that
• [x] Context -- sufficient background, references proven pattern
• [x] File Targets -- CREATE targets for new repo, reference files listed
• [x] Feature Flag -- None (appropriate for native packaging)
• [x] Acceptance Criteria -- 6 criteria
• [x] Test Expectations -- manual test steps, run command
• [x] Constraints -- clear guardrails
• [x] Checklist -- 4 items
• [x] Related -- project and template references

Traceability

• [x] story:ios-distribution label -- "Turbo Native iOS shell + Fastlane pipeline (same pattern as landscaping-assistant)"
• [x] story note verified -- found in project-palinks user-stories section
• [x] arch:palinks label -- palinks architecture component
• [x] arch note verified -- arch-palinks note exists in pal-e-docs (slug: arch-palinks)
• [x] Forgejo issue -- ldraney/palinks#56, open

File Targets

This issue creates a NEW repo (palinks-ios). No existing files to modify. Verification of reference targets:

• [x] landscaping-assistant-ios -- EXISTS on Forgejo (https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant-ios), non-empty repo
• [ ] ~/landscaping-assistant-ios/ -- ISSUE: local clone does NOT exist. Issue body references this path but the agent would need to clone from Forgejo first. [BODY] Change to "clone from Forgejo: https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant-ios"
• [x] ~/macbook-ssh/docs/ios-pipeline.md -- verified, 12k, documents the full iOS pipeline architecture
• [x] ~/macbook-ssh/docs/dev-build-guide.md -- verified, 7.3k, step-by-step dev build instructions
• [x] ~/secrets/apple-developer/ -- verified, contains AuthKey_2A6BSP3H76.p8

Repo Placement

OK. Issue filed on ldraney/palinks (issue tracker), implementation creates ldraney/palinks-ios (new repo). This is explicitly documented in the ### Repo section. The palinks-ios repo does not yet exist on Forgejo -- confirmed via API. No cross-repo mismatch.

Dependencies

• palinks.app must be live -- VERIFIED: HTTP 200 confirmed
• landscaping-assistant-ios must exist as template -- VERIFIED: repo exists on Forgejo
• MacBook accessible via SSH over Tailscale -- not verified (requires network test), but documented in macbook-ssh docs
• Apple Developer credentials -- VERIFIED: ~/secrets/apple-developer/ contains key file
• No board items blocking this ticket -- all board items are either in backlog or done
• No dependency on auth-roles, custom-domain, or other stories

Acceptance Criteria

6 criteria. Assessment:

• "palinks-ios repo exists on Forgejo" -- agent-verifiable via Forgejo API
• "SceneDelegate points at https://palinks.app" -- agent-verifiable via grep
• "xcodegen generate produces a valid .xcodeproj" -- requires MacBook SSH, agent-verifiable
• "Dev build installs on iPhone (7-day provisioning)" -- MANUAL ONLY, requires physical device
• "fastlane beta uploads to TestFlight successfully" -- requires MacBook SSH, agent-verifiable but slow
• "App loads palinks.app content in WKWebView on launch" -- MANUAL ONLY, requires device

2 of 6 criteria require manual verification with a physical device. This is inherent to iOS development and acceptable. The remaining 4 are agent-verifiable.

Blast Radius

Low. This creates a standalone new repo that wraps the existing web app. No changes to palinks Rails app. No changes to infrastructure. The Turbo Native pattern means the web app is loaded in WKWebView -- zero coupling to native code beyond the URL constant. The only downstream effect is that palinks.app must remain accessible at that URL (already true).

Decomposition Assessment

8 points, 6 AC, 1 repo (new). Touches files across a single new repo. The work is heavily templated from landscaping-assistant-ios, which reduces complexity. However:

• Requires SSH to MacBook for Xcode and Fastlane operations
• Manual device testing required (dev build, TestFlight install)
• Estimated agent work: 10-15 minutes (clone template, adapt files, create repo, push, SSH build)
• Exceeds 5-minute rule due to cross-machine SSH build steps

Borderline. The pattern is proven and the scope is well-defined, but the 8-point estimate and multi-machine workflow push it past the single-agent threshold. Could be kept as-is if the operator accepts the longer agent pass, or decomposed into: (1) Create repo + project files, (2) Build + TestFlight upload.

Recommendation

• [BODY] Fix reference path: ~/landscaping-assistant-ios/ does not exist locally. Change File Targets to instruct agent to clone from Forgejo URL (https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant-ios) rather than referencing a local path.

Verdict: APPROVED

Re-review of board item #1392. Previous review (review-1392-2026-06-13) flagged 4 items -- all 4 have been addressed.

Previous Findings Resolution

• [x] [DECOMPOSE] -- Resolved. Umbrella #28 now has 3 sub-tickets: #50 (DNS), pal-e-platform #425 (Caddy), #51 (Rails + Keycloak)
• [x] [BODY] Missing Caddy path -- Resolved. Sub-ticket #425 specifies /etc/caddy/Caddyfile and salt/states/caddy/ with both manual SSH and Salt state options
• [x] [BODY] Keycloak mechanism -- Resolved. Sub-ticket #51 specifies Terraform via terraform/k3s.tfvars with tofu plan / tofu apply
• [x] [LABEL] Points mismatch -- Resolved. Board item updated from 1 to 5 points

Template Completeness

• [x] Type
• [x] Lineage
• [x] Repo -- correctly declares Multi-repo umbrella
• [x] User Story
• [x] Context
• [x] Sub-Tickets -- new section listing execution order with repo and scope per sub-ticket
• [x] File Targets -- defers to sub-tickets with summary pointers
• [x] Feature Flag
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist -- maps to sub-ticket completion
• [x] Related

All required sections for template-issue-feature are present. The umbrella format with a Sub-Tickets table is a good pattern for multi-repo work.

Traceability

• [x] story:custom-domain label -- "Route palinks.app to production"
• [x] story note verified -- found in project-palinks user-stories section
• [x] arch:palinks label -- palinks architecture component
• [ ] arch note MISSING -- arch-palinks not found in pal-e-docs. This has been flagged in multiple prior reviews (review-1400, review-1381, review-1377, etc.) and remains an open [SCOPE] item. However, this is a persistent platform-level gap, not a blocker for this specific ticket's scope.
• [x] Forgejo issue -- ldraney/palinks#28, state: open

Sub-Ticket Verification

• [x] #50 (GoDaddy DNS) -- well-scoped manual task, clear AC (dig verification), no code changes
• [x] pal-e-platform #425 (Caddy config) -- concrete file paths, includes Caddyfile template from architecture doc, offers both manual SSH and Salt state options
• [x] #51 (Rails + Keycloak) -- specifies config/environments/production.rb and terraform/k3s.tfvars with clear instructions

Minor issue in #425: Constraints section references "palinks #49" as the DNS dependency, but the DNS sub-ticket is actually #50. Issue #49 is an unrelated closed bug ("Open external links in new tabs"). This is cosmetic -- the dependency logic is correct, just the reference number is wrong.

File Targets

• [x] config/environments/production.rb -- verified: file exists, config.hosts is commented out at lines 63-66. Development.rb shows the pattern: config.hosts << "hostname"
• [x] docs/custom-domain.md -- verified: file exists with Remaining Work section (5 items) to be updated
• [x] /etc/caddy/Caddyfile on edge-proxy -- correctly specified in #425 with sample Caddyfile content
• [x] terraform/k3s.tfvars in pal-e-services -- specified in #51 with clear instructions on which arrays to update

Repo Placement

Umbrella is correctly filed on palinks (the primary app). Sub-tickets are filed on correct repos: #50 on palinks (manual task), #425 on pal-e-platform (Caddy infra), #51 on palinks (Rails changes + cross-repo Terraform). The multi-repo scope is now properly decomposed so each sub-ticket can be executed by an agent cloned into the correct repo.

Dependencies

• [x] pal-e-platform #419 (Hetzner edge provisioning) -- done, on board in done column (item #1417)
• [x] Spike #15 (custom domain routing) -- done, on board in done column (item #1377)
• [x] Execution order documented: #50 (DNS) before #425 (Caddy TLS), #51 independent but must deploy before e2e

Acceptance Criteria

5 AC on the umbrella, each is an end-to-end verification. Sub-tickets have their own per-component AC. The umbrella AC serves as the final integration gate. All are verifiable with curl and browser testing. This is well-structured.

Blast Radius

• docs/custom-domain.md lists landscaping-assistant.app and westsidekingsandqueens.com as future domains using the same pattern. This ticket establishes the reusable template.
• No downstream consumers affected beyond the app itself.
• Keycloak redirect URI change: sub-ticket #51 correctly specifies adding to existing arrays, not replacing.

Decomposition Assessment

Already decomposed into 3 sub-tickets across 2 repos + 1 manual task. Each sub-ticket is appropriately scoped for a single agent pass. The umbrella serves as a coordination and verification checkpoint. No further decomposition needed.

Recommendations

• [BODY] Fix cross-reference in pal-e-platform #425: Constraints says "palinks #49" but should be "palinks #50" (DNS sub-ticket). Minor cosmetic issue, not a blocker.
• [SCOPE] Create architecture note arch-palinks -- persistent gap flagged across 5+ reviews. Not blocking this ticket but should be addressed as platform housekeeping.

Neither recommendation is a blocker. The ticket is well-scoped and ready for execution.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

All required sections for template-issue-feature are present. Template is complete.

Traceability

• [x] story:custom-domain label -- "Route palinks.app to production"
• [x] story note verified -- found in project-palinks user-stories section
• [x] arch:palinks label -- palinks architecture component
• [x] arch note verified -- arch-palinks note exists in pal-e-docs (doc type, active)
• [x] Forgejo issue -- ldraney/palinks#28, state: open

All three traceability legs are satisfied.

File Targets

• [x] GoDaddy DNS (A records) -- manual/API, correctly specified (palinks.app and www.palinks.app to 178.156.129.142)
• [ ] pal-e-platform Caddy config -- ISSUE: no specific file path given, just "Add palinks.app site block to Caddy config on edge-proxy." The agent needs a concrete path (e.g., salt/edge-proxy/caddy/Caddyfile or equivalent) to know where to make changes.
• [x] config/environments/production.rb -- verified: file exists, config.hosts is currently commented out (lines 63-66). The file also references palinks-dev host allowlisting in the recent commit history. Note: the issue says config.hosts but the current pattern in development.rb uses config.hosts << (append), not assignment. The agent should follow the existing pattern.
• [x] docs/custom-domain.md -- verified: file exists with "Remaining Work" section (5 items). Marking complete is straightforward.
• [ ] pal-e-services Keycloak -- ISSUE: no specific file path or Keycloak admin procedure specified. "Add https://palinks.app/* to Keycloak client redirect URIs" is an admin task, not a code change. How is this done -- Terraform, Keycloak admin UI, or a config file?

Repo Placement

Issue is filed on ldraney/palinks but correctly declares Multi-repo scope. Touches:

• ldraney/palinks -- Rails host config + docs (code changes)
• ldraney/pal-e-platform -- Caddy/Salt config (code changes)
• pal-e-services -- Keycloak redirect URIs (admin/config)
• GoDaddy DNS -- A records (manual)

This is 4 distinct systems. A single Forgejo issue across this many repos is problematic for agent execution -- an agent cloned into palinks cannot modify pal-e-platform files.

Dependencies

• [x] pal-e-platform #419 (Hetzner edge provisioning) -- done, on board in done column (item #1417)
• [x] Spike #15 (custom domain routing) -- done, on board in done column (item #1377)
• No blocking items in in_progress or todo columns for this story

Dependencies are satisfied and correctly documented in Lineage.

Acceptance Criteria

5 acceptance criteria. All are verifiable with curl and browser testing:

• curl -I https://palinks.app returns 200 -- testable after DNS propagation
• curl -I https://www.palinks.app returns 301 -- testable
• TLS via Let's Encrypt -- verifiable via curl certificate inspection
• Rails accepts palinks.app host -- verifiable via curl
• Keycloak login/logout works -- requires browser test

However, these criteria cannot be verified until all 4 systems are wired up. No individual sub-task can satisfy any criterion in isolation.

Blast Radius

• The docs/custom-domain.md already lists landscaping-assistant.app and westsidekingsandqueens.com as future domains using the same edge proxy pattern. This ticket establishes the pattern for those future domains.
• No downstream consumers affected beyond the app itself.
• The Keycloak redirect URI change could affect existing auth flows if misconfigured (e.g., if the existing tailscale funnel URI is removed instead of added alongside).

Decomposition Assessment

NEEDS DECOMPOSITION.

• File targets across repos: 4+ targets across 4 systems (palinks, pal-e-platform, pal-e-services, GoDaddy) -- exceeds the >3 targets across >2 repos threshold
• Acceptance criteria: 5 -- at the threshold
• Points mismatch: Scored at 1 point but the multi-repo, multi-system scope is at least 3-5 points of work
• Agent executability: No single agent can execute this ticket. An agent cloned into palinks cannot modify pal-e-platform Salt configs, cannot access Keycloak admin, and cannot set GoDaddy DNS records.

Recommended decomposition:

1. GoDaddy DNS (manual/task) -- Set A records for palinks.app and www.palinks.app
2. pal-e-platform: Caddy config (issue) -- Add palinks.app site block to Caddy on edge-proxy, filed on pal-e-platform repo
3. palinks: Rails host + docs (issue) -- Add palinks.app to config.hosts, update docs/custom-domain.md, filed on palinks repo
4. pal-e-services: Keycloak redirect URIs (task) -- Add palinks.app to client redirect URIs
5. End-to-end verification (task) -- curl + browser verification after all sub-tasks complete

Recommendations

• [DECOMPOSE] 4+ file targets across 4 systems, no single agent can execute. Route to skill-decompose-ticket for sub-ticket creation.
• [BODY] Add specific file path for Caddy config in pal-e-platform (e.g., the Salt state or Caddyfile path on edge-proxy).
• [BODY] Clarify Keycloak redirect URI update mechanism -- is it Terraform, admin UI, or a config file in pal-e-services?
• [LABEL] Update points from 1 to at least 3 -- multi-repo multi-system work cannot be 1 point.

Verdict: APPROVED

Re-review of board item #1406 after refinement. Previous review review-1406-2026-06-09 returned NEEDS_REFINEMENT with 4 items. All 4 have been addressed.

Previous Findings — Resolution

• [x] story:canvas-layout not in user-stories — acknowledged as cross-cutting gap, not blocking. Precedent set by #36 and #41 reviews. Accepted.
• [x] Undocumented dependency on #34 (feature_flags) — FIXED. Feature Flag section now says Flag: none. Canvas ships as default layout; flag gate deferred to when #34 lands. Matches #36's approach.
• [x] Missing AC for initial placement — FIXED. Two new ACs added: auto-placement of links with null canvas_x/canvas_y in a grid pattern, and new links get auto-placed at sensible default. Migration columns specified as nullable.
• [x] Pan/zoom underspecified — FIXED. AC now specifies "click-drag on empty background" for pan and "scroll wheel" for zoom. Constraints add "No pinch-to-zoom required (desktop-first)."

Template Completeness

• [x] Type — Feature
• [x] Lineage — depends on #36, prerequisite for #41
• [x] Repo — ldraney/palinks
• [x] User Story
• [x] Context — includes architecture decision (HTML/CSS vs canvas/WebGL)
• [x] File Targets — 6 targets + 1 exclusion
• [x] Feature Flag — "none" with rationale
• [x] Acceptance Criteria — 7 items
• [x] Test Expectations — 4 tests + run command
• [x] Constraints — 6 constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:canvas-layout label — present on board item #1406
• [ ] story note MISSING — story:canvas-layout not listed in project-palinks user-stories section. Cross-cutting gap acknowledged in prior reviews (#36, #41). Not blocking per precedent.
• [x] arch:palinks label — present on board item
• [ ] arch note MISSING — no arch-palinks note exists. Board-wide gap acknowledged in #36 review. Not blocking.
• [x] Forgejo issue — ldraney/palinks#40, open

File Targets

• [x] db/migrate/*_add_canvas_position_to_links.rb — new file to create. Verified no canvas_x/canvas_y columns exist in current schema. Links table has position (integer) but no spatial columns.
• [x] app/models/link.rb — verified exists (8 lines). Has position/favorite scopes, no click logic. Correct target for canvas_scale method.
• [x] app/views/links/index.html.erb — verified exists (23 lines). Currently renders div.link-grid with data-controller="sortable". Correct target for canvas container replacement.
• [x] app/views/links/_link.html.erb — verified exists (40 lines). Renders div.link-card with sortable targets. Correct target for inline position/scale styles.
• [x] app/javascript/controllers/canvas_controller.js — new file to create. Controllers directory exists with sortable_controller.js as pattern reference.
• [x] app/assets/stylesheets/application.css — verified exists. Has .link-grid (line 142) and .link-card styles. Correct target for canvas container styles.
• [x] Do NOT touch: sortable_controller.js — verified exists (230 lines). Correct exclusion.

Repo Placement

Correct. Issue filed on ldraney/palinks, all file targets within the same repo. Single-repo change.

Dependencies

• #36 (clicks table) — currently in_progress on board-palinks (item #1400). This ticket depends on it for click count data. Dependency is documented in both Lineage and Constraints. #36 must merge first.
• #34 (feature_flags) — in backlog (item #1398). No longer a dependency. Feature Flag section correctly says "none" and ships ungated. Flag gate deferred to when #34 lands.
• #41 (link groups) — in todo (item #1407). Downstream dependency: depends on canvas existing. Not a blocker for this ticket. Correctly documented in Lineage.

Acceptance Criteria

• [x] "Links render on a canvas with absolute positioning instead of a grid" — testable, clear
• [x] "Card size scales proportionally to click count (min scale 0.7, max scale 1.5)" — testable with specific bounds
• [x] "Cards can be dragged to new positions, position persists on reload" — testable via integration test
• [x] "Canvas supports pan (click-drag on empty background) and zoom (scroll wheel)" — testable, interaction methods specified
• [x] "Links with zero clicks render at base size (scale 1.0)" — testable edge case
• [x] "Links with no canvas_x/canvas_y are auto-placed in a grid pattern on first render" — testable, addresses existing-links migration
• [x] "New links get auto-placed at sensible default position" — testable, addresses post-deployment creation

All 7 ACs are verifiable by an agent. Test expectations cover unit tests for scale calculation, nullable columns, and integration tests for drag persistence and auto-placement.

Blast Radius

• .link-grid CSS class used in 3 places: application.css (lines 142, 450) and index.html.erb (line 7). Replacing with canvas container is safe — no other views reference it.
• sortable_controller.js (230 lines) manages current grid ordering. Correctly excluded. With "Flag: none," the canvas replaces the grid outright — no coexistence concern since the sortable controller just won't be attached to the new DOM.
• No clicks table or click_count references exist yet — confirms dependency on #36.
• No other services or repos affected. palinks is a standalone Rails app.

Decomposition Assessment

6 file targets in 1 repo, 7 acceptance criteria. At the boundary of the 5-minute thresholds but all targets are tightly coupled in a single feature unit: migration + model method + view changes + Stimulus controller + CSS. Natural cohesion. No decomposition needed.

Recommendation

No action needed. All previous NEEDS_REFINEMENT items resolved. Scope is solid.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- depends on #36
• [x] Repo -- ldraney/palinks
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag -- canvas_layout, global, disabled, superadmin only
• [x] Acceptance Criteria -- 6 items
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:canvas-layout label -- present on board item #1406
• [ ] story note MISSING -- story:canvas-layout is NOT listed in the project-palinks user-stories section. Only containerize-palinks, sortable-links, auth-roles, and custom-domain are listed. [SCOPE] Create user story entry on project-palinks user-stories section for story:canvas-layout.
• [x] arch:palinks label -- present on board item
• [ ] arch note MISSING -- no arch-palinks note exists in pal-e-docs. Known board-wide gap acknowledged in #36 review; not blocking individual tickets.
• [x] Forgejo issue -- ldraney/palinks#40, open

File Targets

• [x] db/migrate/*_add_canvas_position_to_links.rb -- new file to create, correct (no canvas_x/canvas_y columns exist yet)
• [x] app/models/link.rb -- verified exists (380 bytes), currently has position/favorite scopes, no click count logic yet. Correct target for canvas scale method.
• [x] app/views/links/index.html.erb -- verified exists, currently renders div.link-grid with data-controller="sortable". Correct target for canvas container replacement.
• [x] app/views/links/_link.html.erb -- verified exists (40 lines), renders div.link-card with sortable targets. Correct target for inline position/scale styles.
• [x] app/javascript/controllers/canvas_controller.js -- new file to create. Controllers directory exists with sortable_controller.js as pattern reference.
• [x] app/assets/stylesheets/application.css -- verified exists (11KB), has .link-grid and .link-card styles. Correct target for canvas container styles.
• [x] Do NOT touch: sortable_controller.js -- verified exists (230 lines), legacy grid ordering. Correct exclusion.

Repo Placement

Correct. Issue is filed on ldraney/palinks, all file targets are within the same repo. Single-repo change.

Dependencies

• #36 (clicks table) -- in todo column on board-palinks (item #1400). This ticket explicitly depends on it for click count data used in scale calculations. The dependency is correctly documented in both Lineage and Constraints sections. #36 must be merged before this ticket can proceed.
• #34 (feature_flags table and admin UI) -- in backlog column (item #1398). The ticket specifies gating behind a canvas_layout feature flag using feature_enabled? helper, but the feature flag system does not yet exist. Per docs/feature-flags.md: "Feature flag system pending implementation." This is an undocumented dependency.
• #41 (link groups) -- in todo column (item #1407), shares story:canvas-layout label. Appears to be a follow-on ticket that depends on the canvas view existing first. Not a blocker for this ticket.

Acceptance Criteria

• [x] "Links render on a canvas with absolute positioning instead of a grid" -- testable, clear
• [x] "Card size scales proportionally to click count" -- testable, with min/max bounds specified in Constraints (0.7-1.5)
• [x] "Cards can be dragged to new positions, position persists on reload" -- testable via integration test
• [x] "Canvas supports pan and zoom" -- testable but broad; could benefit from specifying interaction method (scroll wheel? pinch? buttons?)
• [x] "Zero-click links render at minimum base size" -- testable, clear edge case
• [ ] "Feature is gated behind canvas_layout flag, grid remains default" -- NOT testable until #34 (feature flag system) is implemented. The feature_enabled? helper referenced in docs/feature-flags.md does not exist yet.

Missing criteria: No AC for what happens when the feature flag is off (should render original grid). No AC for initial canvas_x/canvas_y placement algorithm for existing links that have no position data.

Blast Radius

• The sortable_controller.js (230 lines) manages the current grid drag-and-drop. The ticket correctly excludes it, but the canvas_controller.js will need to coexist alongside it since the flag gates which view renders. No conflict as long as the two controllers attach to different DOM containers.
• No other services or repos affected -- palinks is a standalone Rails app.
• The .link-grid CSS class is used only in index.html.erb, so replacing it with a canvas container is safe.

Decomposition Assessment

6 file targets in 1 repo, 6 acceptance criteria. This is at the boundary of the 5-minute rule thresholds but all targets are tightly coupled within a single feature. The migration, model method, view changes, Stimulus controller, and CSS form a natural unit. No decomposition needed, provided the feature flag dependency is resolved by either (a) implementing #34 first or (b) using a simpler interim flag mechanism in this ticket's scope.

Recommendations

• [SCOPE] Add story:canvas-layout entry to project-palinks user-stories section. Suggested text: story:canvas-layout -- Activity-based spatial canvas layout for link cards.
• [BODY] Add #34 (feature_flags table) as an explicit dependency in the Lineage and Constraints sections, or remove the feature flag AC and simplify to a direct boolean/env-var gate until the flag system exists.
• [BODY] Add AC for initial placement: "Existing links without canvas positions are placed in a default grid-like arrangement on first canvas render."
• [BODY] Clarify pan/zoom interaction methods in AC #4 (e.g., "scroll wheel to zoom, click-drag on empty space to pan").

Verdict: APPROVED

Re-review of board item #1407. Previous review review-1407-2026-06-09 returned NEEDS_REFINEMENT with 5 findings. All blocking issues have been resolved.

Previous Findings Resolution

• [x] Lineage #39 -> #40 -- FIXED. Issue body now correctly says "Depends on ldraney/palinks #40".
• [x] canvas_controller.js dependency -- FIXED. File target entry notes "(file created by #40)" and Constraints section says "canvas_controller.js is created by #40 -- this ticket extends it, does not create it".
• [x] story:canvas-layout not in user-stories -- Acknowledged as cross-cutting gap. Not blocking per caller direction. [SCOPE] remains open.
• [x] arch-palinks missing -- Acknowledged as board-wide gap. Not blocking per #36 review precedent. [SCOPE] remains open.
• [x] Decomposition deferred -- Correctly deferred until dependencies #40 and #36 land. Ticket is in backlog; decomposition is premature now.
• [x] Feature flag system not implemented -- Acknowledged. Flag section documents the target gate. Consistent with template guidance; the flag design is forward-looking documentation, not a claim that the system exists.

Template Completeness

• [x] Type
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:canvas-layout label -- present on board item #1407
• [ ] story note MISSING -- story:canvas-layout not listed in project-palinks user-stories section. Current entries: containerize-palinks, sortable-links, auth-roles, custom-domain. Acknowledged as cross-cutting gap, not blocking. [SCOPE] Create user story entry for story:canvas-layout on project-palinks user-stories section.
• [x] arch:palinks label -- present on board item
• [ ] arch note MISSING -- no arch-palinks note found in pal-e-docs. Board-wide gap with precedent from #36 review. Not blocking. [SCOPE] Create architecture note arch-palinks.
• [x] Forgejo issue -- ldraney/palinks#41, state: open

File Targets

• [x] db/migrate/*_create_link_groups.rb -- new file (create). Migration directory exists at db/migrate/. OK.
• [x] db/migrate/*_add_group_id_to_links.rb -- new file (create). OK.
• [x] app/models/link_group.rb -- new file (create). Models directory exists. OK.
• [x] app/models/link.rb -- exists. No group association yet. Will need belongs_to :link_group added. OK.
• [x] app/views/links/_link_group.html.erb -- new file (create). Views directory exists. OK.
• [x] app/views/links/index.html.erb -- exists. Currently renders a flat link-grid with sortable controller. Will need canvas-aware rendering. OK.
• [x] app/javascript/controllers/canvas_controller.js -- does not exist yet. Ticket now explicitly documents that this file is created by #40 and this ticket extends it. Dependency is clearly stated. OK.
• [x] app/controllers/link_groups_controller.rb -- new file (create). Controllers directory exists. OK.
• [x] config/routes.rb -- exists. Currently has resources :links. Will need link_groups resource. OK.
• [x] app/javascript/controllers/sortable_controller.js -- correctly listed as DO NOT TOUCH. Exists. OK.

Repo Placement

OK. Issue filed on ldraney/palinks, all file targets are in the same repo. No cross-repo work needed.

Dependencies

• #36 (Create clicks table and tracking) -- board item #1400, column: todo. Group aggregate click tracking depends on the clicks table. Documented in issue.
• #40 (Canvas view with activity-based card sizing) -- board item #1406, column: backlog. Canvas rendering and canvas_controller.js depend on this. Documented in issue Lineage, File Targets, and Constraints sections.
• Feature flag system -- not yet implemented per docs/feature-flags.md. Ticket documents the target flag design. Acceptable as forward-looking documentation.

Acceptance Criteria

7 acceptance criteria. All well-written and verifiable once prerequisites exist. Several AC depend on #36 and #40 landing first, which is expected given the dependency chain. The AC themselves are testable by an agent post-dependencies.

Blast Radius

• Adding link_group_id to links is a schema change affecting the Link model. Migration should be reversible.
• Modifying index.html.erb changes the primary view -- must be behind feature flag.
• No sibling services or downstream consumers. Palinks is self-contained.
• No existing references to link_group or LinkGroup anywhere in the codebase -- clean surface area.

Decomposition Assessment

7 AC + 9 file targets exceeds the 5-minute rule. However, decomposition is correctly deferred: the ticket is in backlog, and dependencies #40 (backlog) and #36 (todo) must ship first. When this ticket moves to todo, decompose into: (1) model/migrations/routes, (2) controller/CRUD, (3) view/canvas integration.

Recommendations

• [SCOPE] Create user story entry for story:canvas-layout on project-palinks user-stories section (cross-cutting gap, not blocking this ticket).
• [SCOPE] Create architecture note arch-palinks (board-wide gap, not blocking this ticket).
• [DECOMPOSE] When this ticket moves from backlog to todo (after #40 ships), route to skill-decompose-ticket. Suggested split: (1) model/migrations/routes, (2) controller/CRUD, (3) view/canvas integration.

No blocking issues. All NEEDS_REFINEMENT findings from the previous review are resolved.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:canvas-layout label — present on board item #1407
• [ ] story note MISSING — story:canvas-layout is not listed in the project-palinks user-stories section. Current entries: containerize-palinks, sortable-links, auth-roles, custom-domain. [SCOPE] Create user story entry for story:canvas-layout on project-palinks user-stories section.
• [x] arch:palinks label — present on board item
• [ ] arch note MISSING — no arch-palinks note found in pal-e-docs. Acknowledged as a board-wide gap (not blocking individual tickets per #36 review precedent). [SCOPE] Create architecture note arch-palinks for component palinks.
• [x] Forgejo issue — ldraney/palinks#41, state: open

File Targets

• [x] db/migrate/*_create_link_groups.rb — new file (create). Migration directory exists at db/migrate/. OK.
• [x] db/migrate/*_add_group_id_to_links.rb — new file (create). OK.
• [x] app/models/link_group.rb — new file (create). Models directory exists. OK.
• [x] app/models/link.rb — exists. Currently has no group association. Will need belongs_to :link_group added. OK.
• [x] app/views/links/_link_group.html.erb — new file (create). Views directory exists. OK.
• [x] app/views/links/index.html.erb — exists. Currently renders a flat link-grid with sortable controller. Will need canvas-aware rendering. OK.
• [ ] app/javascript/controllers/canvas_controller.js — ISSUE: does not exist yet. This file is created by issue #40 (canvas view). This ticket cannot add group drag behavior to a controller that doesn't exist. Dependency must land first.
• [x] app/controllers/link_groups_controller.rb — new file (create). Controllers directory exists. OK.
• [x] config/routes.rb — exists. Currently has only resources :links. Will need link_groups resource added. OK.
• [x] app/javascript/controllers/sortable_controller.js — correctly listed as DO NOT TOUCH. Exists. OK.

Repo Placement

OK. Issue filed on ldraney/palinks, all file targets are in the same repo. No cross-repo work needed.

Dependencies

• #36 (Create clicks table and tracking) — board item #1400, column: todo, state: open. This ticket's group aggregate click tracking depends on the clicks table existing. Not yet implemented.
• #40 (Canvas view with activity-based card sizing) — board item #1406, column: backlog, state: open. This ticket's canvas rendering and canvas_controller.js modifications depend on the canvas view being implemented first. Not yet implemented.
• Feature flag system — per docs/feature-flags.md, the feature flag infrastructure is not yet implemented ("Feature flag system pending implementation"). The ticket specifies a link_groups flag gated to superadmin, but there is no FeatureFlag model, no feature_enabled? helper, and no flags in the database. The flag cannot be implemented until the flag system itself exists.
• Lineage section references wrong issue number — the issue body says "Depends on canvas view (ldraney/palinks #39 or next)" but the actual canvas view issue is #40. This should be corrected.

Acceptance Criteria

7 acceptance criteria. Most are testable by an agent:

• "Can create, rename, and delete link groups" — testable via integration test
• "Can add/remove links to/from a group via UI" — testable but requires canvas view to exist
• "Grouped links render inside a parent container card on the canvas" — requires canvas view (#40) to be done first
• "Group container size reflects aggregate click activity" — requires clicks table (#36) to be done first
• "Dragging a group card moves all child link cards with it" — requires canvas_controller.js from #40
• "Ungrouped links continue to render independently on the canvas" — requires canvas view
• "A link can belong to at most one group" — testable via model validation

Several AC are untestable until dependencies #36 and #40 land. The AC themselves are well-written and verifiable once prerequisites exist.

Blast Radius

• Adding link_group_id to links is a schema change that affects the existing Link model. The migration should be reversible.
• Modifying index.html.erb to support grouped rendering changes the primary view for all users — must be behind the feature flag (which doesn't exist yet).
• No sibling services or downstream consumers identified. Palinks is self-contained.

Decomposition Assessment

7 acceptance criteria + 4 test expectations across 9 file targets (7 creates + 2 modifications). This exceeds the 5-minute rule on multiple dimensions:

• >5 acceptance criteria (7)
• 9 file targets across model, controller, view, migration, JS, and routes layers
• Estimated agent work: well beyond 5 minutes

However, decomposition should wait until dependencies are resolved. The ticket cannot be meaningfully decomposed when its core prerequisites (#36 clicks table, #40 canvas view, feature flag system) are not yet implemented. Once those land, decompose into: (1) model + migrations + routes, (2) controller + CRUD, (3) view partials + canvas integration.

Recommendations

• [BODY] Fix Lineage reference: ldraney/palinks #39 → ldraney/palinks #40
• [SCOPE] Create user story entry for story:canvas-layout on project-palinks user-stories section
• [SCOPE] Create architecture note arch-palinks (board-wide gap, not unique to this ticket)
• [SCOPE] Feature flag system must be implemented before this ticket can use the link_groups flag. Either add the flag system as an explicit dependency or remove the Feature Flag section and note it as a follow-up.
• [DECOMPOSE] 7 AC + 9 file targets exceeds 5-minute rule. Route to skill-decompose-ticket after dependencies land. Suggested split: (1) model/migrations/routes, (2) controller/CRUD, (3) view/canvas integration.

Verdict: APPROVED

Re-review of board item #1400 after refinement. Previous review review-1400-2026-06-09 returned NEEDS_REFINEMENT with two items. Both are now resolved.

Previous Findings -- Resolution

• [x] [BODY] app/views/links/show.html.erb was missing from File Targets -- FIXED. Now listed as a file to modify: "update the direct link to URL to also route through click tracking endpoint." New AC #7 added: "Both index partial and show page route through click tracking."
• [x] [SCOPE] arch-palinks note missing in pal-e-docs -- Acknowledged as a cross-cutting board-wide gap affecting all palinks items, not blocking this individual ticket. Will be addressed at board level.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- references spike #16, prerequisite for #40
• [x] Repo -- ldraney/palinks
• [x] User Story -- well-formed As/I want/So that
• [x] Context -- thorough, includes schema from spike doc and key design decisions
• [x] File Targets -- 9 targets (was 8, now includes show.html.erb) with modify/create and NOT touch sections
• [x] Feature Flag -- "none" with rationale (deferred to #34)
• [x] Acceptance Criteria -- 7 criteria (was 6, new AC for index+show routing)
• [x] Test Expectations -- 5 expectations with run command
• [x] Constraints -- 4 constraints, well-specified
• [x] Checklist -- present
• [x] Related -- present, references #40 and #41

Traceability

• [x] story:auth-roles label -- Keycloak auth, roles, visibility, feature flags
• [x] story note verified -- found in project-palinks user-stories section
• [x] arch:palinks label -- palinks architecture component
• [ ] arch note MISSING -- acknowledged board-wide gap, not blocking. search_notes("arch-palinks") still returns no results.
• [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/palinks/issues/36, open

File Targets

• [x] db/migrate/*_create_clicks.rb -- verified: NEW file, no existing clicks migration. 4 existing migrations in db/migrate/.
• [x] app/models/click.rb -- verified: NEW file. Only link.rb and application_record.rb exist in app/models/.
• [x] app/models/link.rb -- verified: EXISTS at app/models/link.rb. Has validations, scopes (ordered, favorites, tagged). No existing click associations.
• [x] app/controllers/clicks_controller.rb -- verified: NEW file. Only links_controller.rb and application_controller.rb exist.
• [x] config/routes.rb -- verified: EXISTS. Has resources :links with sort and toggle_favorite. Click route will nest under links.
• [x] app/views/links/_link.html.erb -- verified: EXISTS. Line 13: link_to link.title, link.url links directly to URL. Correctly identified for modification.
• [x] app/views/links/show.html.erb -- verified: EXISTS. Line 4: link_to @link.title, @link.url links directly to URL. Now correctly included in file targets.
• [x] test/models/click_test.rb -- verified: NEW file. Note: test/models/ directory does not exist yet and must be created by agent.
• [x] test/controllers/clicks_controller_test.rb -- verified: NEW file. test/controllers/ directory exists.

Repo Placement

OK. Issue is filed on ldraney/palinks, all file targets are within that repo. Single-repo scope.

Dependencies

• Upstream (not blocking): #32 (users table) -- handled correctly: user_id as plain bigint, no FK constraint.
• Upstream (not blocking): #34 (feature_flags table) -- handled correctly: feature flag gating deferred.
• Downstream (blocked by this): #40 (canvas view, board item #1406) -- needs click_count data. Documented.
• Downstream (transitively): #41 (link groups, board item #1407) -- depends on #40. Documented.
• No items currently in_progress that block this ticket.

Acceptance Criteria

All 7 criteria are agent-verifiable:

• [x] "Clicking a link card records a click row" -- testable via integration test POST
• [x] "Anonymous clicks record session_id" -- testable via controller test
• [x] "After recording, user is redirected" -- testable via assert_redirected_to
• [x] "Link#click_count returns total clicks" -- testable via unit test
• [x] "Click recording does not break existing link card UI" -- testable via existing test suite
• [x] "user_id column nullable, no FK" -- testable via schema inspection
• [x] "Both index partial and show page route through click tracking" -- testable via view inspection in integration tests. New criterion addresses the show.html.erb gap.

Blast Radius

• show.html.erb: Now addressed in file targets and acceptance criteria.
• No sibling services affected: palinks is standalone.
• Existing sort test: test/controllers/links_controller_sort_test.rb exists. Agent should verify existing tests still pass.
• Turbo/JS interaction: POST-and-redirect pattern avoids Turbo stream complications. Correctly constrained.

Decomposition Assessment

9 file targets in 1 repo. 7 acceptance criteria (slightly over the 5 threshold). However, this is a standard Rails resource scaffold pattern (migration + model + controller + route + view updates + tests) -- cohesive and well-understood. An experienced agent can complete this in a single pass within 5 minutes. No decomposition needed.

Recommendations

No action needed. Both items from the previous review have been addressed. The arch-palinks note gap is a board-wide concern tracked separately.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- references spike #16, prerequisite for #40
• [x] Repo -- ldraney/palinks
• [x] User Story -- well-formed As/I want/So that
• [x] Context -- thorough, includes schema from spike doc and key design decisions
• [x] File Targets -- 8 targets with modify/create and NOT touch sections
• [x] Feature Flag -- "none" with rationale (deferred to #34)
• [x] Acceptance Criteria -- 6 criteria
• [x] Test Expectations -- 5 expectations with run command
• [x] Constraints -- 4 constraints, well-specified
• [x] Checklist -- present
• [x] Related -- present, references #40 and #41

Traceability

• [x] story:auth-roles label -- Keycloak auth, roles, visibility, feature flags
• [x] story note verified -- found in project-palinks user-stories section
• [x] arch:palinks label -- palinks architecture component
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-palinks for the palinks component. search_notes("arch-palinks") returned no results.
• [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/palinks/issues/36, open

File Targets

• [x] db/migrate/*_create_clicks.rb -- verified: NEW file, no existing clicks migration. 4 existing migrations in db/migrate/.
• [x] app/models/click.rb -- verified: NEW file. Only link.rb and application_record.rb exist in app/models/.
• [x] app/models/link.rb -- verified: EXISTS. Currently has validations, scopes (ordered, favorites, tagged). No existing click associations.
• [x] app/controllers/clicks_controller.rb -- verified: NEW file. Only links_controller.rb and application_controller.rb exist.
• [x] config/routes.rb -- verified: EXISTS. Currently has resources :links with sort and toggle_favorite. Click route will nest under links.
• [x] app/views/links/_link.html.erb -- verified: EXISTS. Line 13: link_to link.title, link.url links directly to URL. Correctly identified for modification.
• [x] test/models/click_test.rb -- verified: NEW file. Note: test/models/ directory does not exist yet and must be created.
• [x] test/controllers/clicks_controller_test.rb -- verified: NEW file. test/controllers/ directory exists.

File Target Issues

• [ ] app/views/links/show.html.erb -- ISSUE: [BODY] Line 4 also links directly to link.url via link_to @link.title, @link.url. This view should either also route through the click tracking endpoint or be explicitly listed in "Files the agent should NOT touch" with rationale. Currently unaddressed -- an agent may miss it or make an inconsistent choice.

Repo Placement

OK. Issue is filed on ldraney/palinks, all file targets are within that repo. Single-repo scope.

Dependencies

• Upstream (not blocking): #32 (users table) -- ticket correctly handles this by making user_id a plain bigint with no FK constraint. Good.
• Upstream (not blocking): #34 (feature_flags table) -- ticket correctly defers flag gating. Feature Flag section documents this with rationale.
• Downstream (blocked by this): #40 (canvas view with activity-based card sizing, board item #1406) -- needs click_count data from this ticket. Documented in Lineage and Related sections.
• Downstream (transitively): #41 (link groups, board item #1407) -- depends on #40 which depends on this.
• No items currently in_progress that block this ticket.
• Dependencies are well-documented in the issue body.

Acceptance Criteria

All 6 criteria are agent-verifiable:

• [x] "Clicking a link card records a click row" -- testable via integration test POST
• [x] "Anonymous clicks record session_id" -- testable via controller test checking session assignment
• [x] "After recording, user is redirected" -- testable via assert_redirected_to
• [x] "Link#click_count returns total clicks" -- testable via unit test
• [x] "Click recording does not break existing link card UI" -- testable via existing test suite passing
• [x] "user_id column exists but nullable, no FK" -- testable via schema inspection / migration review

Test expectations align well with acceptance criteria. Run command bin/rails test is correct for this project.

Blast Radius

• show.html.erb: Also links directly to link.url (line 4). If _link.html.erb is updated to route through click tracking, show.html.erb should be addressed too -- either tracked or explicitly excluded.
• No sibling services affected: palinks is a standalone Rails app. No other services consume the links table.
• Existing sort test: test/controllers/links_controller_sort_test.rb exists. The new click route should not break existing link routes, but the agent should verify existing tests still pass.
• Turbo/JS interaction: The constraint says "use redirect, not AJAX" which is correct given the existing Turbo setup. The POST-and-redirect pattern avoids Turbo stream complications.

Decomposition Assessment

8 file targets in 1 repo. 6 acceptance criteria (slightly over the 5 threshold). However, this is a standard Rails resource scaffold pattern (migration + model + controller + route + view update + tests) -- cohesive and well-understood. An experienced agent can complete this in a single pass within 5 minutes. No decomposition needed.

Recommendations

• [BODY] Add app/views/links/show.html.erb to File Targets (either as a file to modify for click tracking consistency, or explicitly in the "should NOT touch" list with rationale for why show page clicks are not tracked).
• [SCOPE] Create architecture note arch-palinks for the palinks component in pal-e-docs. This is a cross-cutting gap affecting all palinks board items, not just this ticket.

Verdict: APPROVED

Re-review of board item #1379. Previous review (review-1379-2026-06-07) returned NEEDS_REFINEMENT with 4 issues. All have been addressed.

Previous Findings Resolution

• [x] [BODY] Role model inconsistency — RESOLVED. Issue body now explicitly declares the canonical model: superadmin + member (Keycloak roles) + anonymous (unauthenticated). Confirmed consistent in docs/visibility.md, docs/architecture.md, project-palinks, and arch-palinks. Residual "lead"/"collaborator" text in docs/user-stories.md (lines 17, 36, 169, 172) is descriptive prose in non-canonical user stories, not role definitions — acceptable for now, cleanup can follow.
• [x] [BODY] Deliverable reframing — RESOLVED. Issue deliverable now reads "Complete the 'Current Link Inventory' table by auditing production links and assigning proposed visibility tiers." Correctly frames as completing existing doc, not creating from scratch.
• [x] [SCOPE] Create project-palinks — RESOLVED. project-palinks note exists in pal-e-docs (note_type: project-page) with vision, status, architecture, roles, and user-stories section listing story:auth-roles.
• [x] [SCOPE] Create arch-palinks — RESOLVED. arch-palinks note exists in pal-e-docs (note_type: doc, tags: architecture,active) with overview, key decisions (including visibility model: three tiers), and canonical docs pointer.

Template Completeness

• [x] Type — Spike
• [x] Lineage — references ldraney/palinks #16
• [x] Repo — ldraney/palinks
• [x] Question — well-structured with 7 sub-questions including role model clarification
• [x] Deliverables — 2 checklist items, correctly scoped
• [x] Time-box — 2 hours
• [x] Related — lists service, related issues #16 and #19, parent story

All required spike template sections present and complete.

Traceability

• [x] story:auth-roles label — present on board item
• [x] story note verified — story:auth-roles found in project-palinks user-stories section
• [x] arch:palinks label — present on board item
• [x] arch note verified — arch-palinks note exists in pal-e-docs with visibility model documented
• [x] Forgejo issue — ldraney/palinks#17, open

File Targets

Spike template expects a docs/{topic}.md as the primary deliverable.

• [x] docs/visibility.md — verified: exists with tier definitions, mermaid diagrams, schema approach, and scope pseudo-code. "Current Link Inventory" section at line 103 is TODO with empty table. This is correctly identified as the core deliverable.

Repo Placement

OK. Issue filed on ldraney/palinks, work targets ldraney/palinks. Single repo.

Dependencies

• ldraney/palinks #16 (Keycloak integration spike, board item #1378) — open, in backlog. Issue body documents that #16 depends on visibility model. Correct ordering: this spike (#17) completes first.
• ldraney/palinks #19 (seed data, board item #1381) — open, in backlog, story:auth-roles. Will consume tier definitions. Documented in Related section.

Acceptance Criteria

Spike deliverables assessment:

• Complete docs/visibility.md inventory table — verifiable. Agent can check the table rows are populated with link names and tier assignments.
• Follow-up ticket for adding visibility column — verifiable. Agent can check Forgejo for a new issue.

Both deliverables are concrete and agent-verifiable.

Blast Radius

Role model is now consistent across canonical docs. Residual "lead"/"collaborator" references in docs/user-stories.md (US-1 line 36, mermaid chart line 17, US-9 lines 169/172) are descriptive prose, not role definitions. No code references to old role terms in app/ or config/. No schema changes in this spike — output is docs-only. Impact contained.

Decomposition Assessment

Single repo, docs-only output, 2 deliverables, estimated <30 min agent time. No decomposition needed.

Recommendations

No action needed. All previous findings resolved. Ticket is ready for execution.

Minor note for executing agent: docs/user-stories.md has stale "lead"/"collaborator" references in US-1 and US-9. Not in scope for this spike, but a cleanup todo for a future pass.

Verdict: APPROVED

Re-review of board item #1378. Previous review (review-1378-2026-06-07) returned NEEDS_REFINEMENT with 5 issues. All have been addressed.

Previous Findings Resolution

• [x] Finding 1: project-palinks note missing -- RESOLVED. project-palinks note created as project-page type with Vision, Status, Architecture, Roles, User Stories, Repos, and Board sections. The user-stories section lists story:auth-roles which maps to this spike.
• [x] Finding 2: arch-palinks note missing -- RESOLVED. arch-palinks note created as doc type with Overview and Key Decisions sections. Auth decision documented as "Keycloak OIDC (planned). Two roles: superadmin, member." References repo docs/architecture.md for details.
• [x] Finding 3: Role model inconsistency -- RESOLVED. Issue body now includes "Role model reconciliation" sub-question: "The canonical model is two Keycloak roles (superadmin, member) plus anonymous." docs/architecture.md role table fixed to superadmin/member/anonymous. docs/visibility.md aligned with same three tiers. project-palinks Roles section matches. Minor: docs/user-stories.md US-3 and US-9 still use "Admin" and "lead/collaborator" as role names, but the spike itself is scoped to reconcile these -- acceptable as-is.
• [x] Finding 4: Deliverable overlap with existing docs -- RESOLVED. Issue deliverable now reads: "docs/auth.md created -- consolidates auth design from existing docs/architecture.md and docs/visibility.md into a single reference." Clear intent: consolidation, not duplication.
• [x] Finding 5: Undocumented dependencies -- RESOLVED. Issue Related section now lists: "#17 -- visibility tier definitions (depends on this spike's role model)" and "#19 -- seed data (consumes schema decisions from this spike)." Both issues verified open in Forgejo.

Template Completeness

• [x] Type -- Spike
• [x] Lineage -- Standalone, adequate context
• [x] Repo -- Multiple (palinks, pal-e-platform, pal-e-services, pal-e-deployments)
• [x] Question -- Well-structured with sub-questions covering Keycloak setup, Rails schema, role model reconciliation, OIDC flow, platform provisioning
• [x] Deliverables -- docs/auth.md (consolidation) + follow-up tickets
• [x] Time-box -- 3 hours
• [x] Related -- Lists affected repos, #15, #17, #19

All required spike template sections present and well-formed.

Traceability

• [x] story:auth-roles label -- present on board item
• [x] story note verified -- project-palinks user-stories section lists story:auth-roles as "Keycloak auth, roles, visibility, feature flags"
• [x] arch:palinks label -- present on board item
• [x] arch note verified -- arch-palinks note exists in pal-e-docs with Key Decisions section covering auth, visibility, feature flags, click tracking
• [x] Forgejo issue -- ldraney/palinks#16, state: open

File Targets

• [x] docs/auth.md -- does NOT exist yet (correct for a spike deliverable to be created)
• [x] docs/architecture.md -- EXISTS, role table aligned to superadmin/member/anonymous canonical model
• [x] docs/visibility.md -- EXISTS, three tiers (superadmin, member, public) consistent with architecture
• [x] docs/user-stories.md -- EXISTS, US-4 and US-8 directly relevant. Note: US-3 and US-9 still reference "Admin" and "lead/collaborator" -- acceptable since the spike is scoped to reconcile the role model

Repo Placement

Correctly identifies multiple repos. Forgejo issue filed on palinks (primary service). Cross-repo questions framed as investigation items. Appropriate for a spike.

Dependencies

• #15 (Route palinks.app domain) -- noted in Related section. OIDC redirect URIs depend on domain. Both in backlog, no blocking conflict.
• #17 (Visibility tier assignment, board item #1379) -- documented in issue body as dependent on this spike's role model. Verified open in Forgejo.
• #19 (Dev seed data, board item #1381) -- documented in issue body as consuming schema decisions from this spike. Verified open in Forgejo.
• No existing Keycloak/OIDC code in codebase (confirmed by grep). Current schema: single links table, no users/visibility/feature_flags.

Acceptance Criteria

Spike deliverables are clear and verifiable:

• docs/auth.md created as consolidation doc -- verifiable by file existence and content review
• Follow-up tickets created -- verifiable by checking Forgejo issues
• Consolidation framing eliminates the previous ambiguity about whether this duplicates existing docs

Blast Radius

• No existing auth code to disrupt -- zero Keycloak/OIDC references in Ruby files
• Schema is minimal (single links table) -- additive changes only
• Cross-repo investigation is reading, not writing
• Role model stale references in user-stories.md are contained to that file and will be reconciled as part of spike output

Decomposition Assessment

Single deliverable (docs/auth.md + follow-up tickets). 1 file target in 1 repo for output. Cross-repo investigation is reading, not writing. 2 acceptance criteria. Well within 5-minute rule. No decomposition needed.

Recommendations

No action needed. All previous findings resolved. Ticket is ready for next_up.

Verdict: READY

Re-review of board item #1380. Previous review review-1380-2026-06-07 returned NEEDS_REFINEMENT with 2 SCOPE findings (missing project-palinks and arch-palinks notes). Both have been created and verified.

Template Completeness

• [x] Type — Spike
• [x] Lineage — Standalone, clear rationale
• [x] Repo — Multiple (palinks, pal-e-services, pal-e-deployments)
• [x] Question — Well-framed with 7 sub-questions
• [x] Deliverables — docs/pipeline.md update + follow-up ticket
• [x] Time-box — 1 hour
• [x] Related — 3 related repos listed

All required spike template sections present and well-structured.

Traceability

• [x] story:containerize-palinks label — present on board item
• [x] story note verified — found in project-palinks user-stories section: story:containerize-palinks — Containerization and CI/CD pipeline (done)
• [x] arch:palinks label — present on board item
• [x] arch note verified — arch-palinks note exists in pal-e-docs (tagged architecture,active). Contains Overview, Key Decisions, and Canonical Docs sections.
• [x] Forgejo issue — ldraney/palinks#18, open

All three traceability legs verified. Previous SCOPE gaps resolved.

File Targets

• [x] Dockerfile — verified: line 26 uses docker.io/library/ruby:3.4.9-slim, lines 30-33 manual apt-get for jemalloc and postgresql-client, lines 42-43 manual user creation. Divergence from platform standard confirmed.
• [x] .woodpecker.yaml — verified: build stage already uses ruby-rails-build from Harbor (correct). No runtime image referenced in pipeline.
• [x] docker-compose.yml — verified: dev uses ruby-rails-build from Harbor (correct, not affected by runtime change).
• [x] docs/pipeline.md — verified: exists, 141 lines, documents current pipeline. This is the spike deliverable target.

Repo Placement

OK. Issue correctly filed on palinks as the primary repo. The issue body correctly identifies that investigation spans palinks, pal-e-services, and pal-e-deployments. Since this is a spike (investigation, not code), single-repo filing is appropriate.

Dependencies

• Board item #1227 (Add Woodpecker CI pipeline) — done. Prerequisite satisfied.
• Board item #1228 (Create production kustomize overlay) — done. Prerequisite satisfied.
• Board item #1229 (Cutover: migrate DB and decommission local Puma) — done. Production is already containerized.
• No blocking items in todo/in_progress/next_up.

Acceptance Criteria

Spike deliverables are clear and verifiable:

• docs/pipeline.md updated with findings — agent can verify file was modified with runtime alignment content.
• Follow-up ticket created — agent can verify a new Forgejo issue exists referencing the spike.

Sub-questions in the Question section provide good investigation structure. All 7 sub-questions are concrete and answerable.

Blast Radius

Low. The DockerHub ruby-slim reference exists only in Dockerfile:26. No other files reference it. The runtime image change is isolated to the production Dockerfile runtime stage. Dev workflow (docker-compose) uses ruby-rails-build and is unaffected. The pipeline (.woodpecker.yaml) builds the Dockerfile but doesn't reference the runtime image directly.

Decomposition Assessment

No decomposition needed. Single investigation spike with 2 deliverables, 1 primary repo, 1-hour time-box. Well within the 5-minute agent execution rule for the docs update and ticket creation that follow.

Recommendation

No action needed. Both previous SCOPE findings have been resolved:

• [SCOPE] Create project page project-palinks — RESOLVED: note exists with user-stories section referencing story:containerize-palinks.
• [SCOPE] Create architecture note arch-palinks — RESOLVED: note exists with architecture overview and key decisions.

Ticket is ready for execution.

Verdict: READY

Re-review of board item #1377. Previous review (review-1377-2026-06-07) returned NEEDS_REFINEMENT with 3 SCOPE issues — all three have been resolved.

Previous Findings Resolution

• [x] project-palinks note created — has user-stories section with story:custom-domain entry
• [x] arch-palinks note created — architecture note exists (slug: arch-palinks, project: palinks)
• [x] Story entry verified — story:custom-domain — Route palinks.app to production listed in project-palinks user-stories section

Template Completeness

• [x] Type — Spike
• [x] Lineage — Standalone, domain purchased 2026-06-07
• [x] Repo — Multiple (pal-e-platform, pal-e-services, pal-e-deployments, palinks)
• [x] Question — Well-formed with 5 sub-questions covering funnel, redirect vs canonical, TLS, per-repo changes, cost/complexity
• [x] Deliverables — docs/custom-domain.md + follow-up tickets
• [x] Time-box — 2 hours
• [x] Related — Lists all 4 affected repos

All required spike template sections present and well-formed.

Traceability

• [x] story:custom-domain label — present on board item
• [x] story note verified — found in project-palinks user-stories section
• [x] arch:palinks label — present on board item
• [x] arch note verified — arch-palinks note exists in pal-e-docs (note_type: doc, project: palinks)
• [x] Forgejo issue — ldraney/palinks#15, open

File Targets

Spike type — no code file targets to verify. Deliverable target docs/custom-domain.md does not exist yet (expected; the spike creates it).

• [x] docs/ directory — exists with 6 files, deliverable path is valid
• [x] config/environments/production.rb — confirmed config.hosts, assume_ssl, force_ssl are currently commented out, validating that the spike question about Rails host config is relevant
• [x] docs/infrastructure.md — already cross-references this spike issue and notes palinks.app purchase

Repo Placement

OK. Issue filed on ldraney/palinks (primary service). Correctly identifies all 4 repos that may need changes. Spike investigation is appropriately scoped to the primary service repo; follow-up implementation tickets will be created per-repo as a deliverable.

Dependencies

No blocking dependencies. All other backlog items (#1378 Keycloak spike, #1379 visibility tiers, #1380 Dockerfile alignment, #1381 seed data) are independent. Domain purchase on GoDaddy is already complete.

Acceptance Criteria

• [x] docs/custom-domain.md created — verifiable by file existence check
• [x] Follow-up tickets created — verifiable by checking Forgejo issues post-spike

Both criteria are agent-verifiable. No missing criteria for a spike of this scope.

Blast Radius

Investigation-only spike. No code changes, no downstream impact. docs/infrastructure.md already references the spike. The eventual implementation will touch TLS termination, DNS, Tailscale funnel config, Rails host allowlisting, and ingress config across 4 repos — but the spike correctly scopes these as questions to answer.

Decomposition Assessment

No decomposition needed. 2-point spike, 2 deliverables, 2-hour time-box. Investigation is conceptually unified. Well within the 5-minute rule for spikes.

Recommendations

No action needed.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Spike
• [x] Lineage — Standalone, clear rationale
• [x] Repo — Multiple (palinks, pal-e-services, pal-e-deployments)
• [x] Question — Well-framed with 7 sub-questions
• [x] Deliverables — docs/pipeline.md update + follow-up ticket
• [x] Time-box — 1 hour
• [x] Related — 3 related repos listed

All required spike template sections present and well-structured.

Traceability

• [x] story:containerize-palinks label — present on board item
• [ ] story note MISSING — [SCOPE] No project-palinks note exists in pal-e-docs. The story is documented in docs/user-stories.md in the repo but not tracked in pal-e-docs. Create project page project-palinks with user-stories section.
• [x] arch:palinks label — present on board item
• [ ] arch note MISSING — [SCOPE] No arch-palinks note found in pal-e-docs. Architecture docs exist in docs/architecture.md in the repo but are not tracked in pal-e-docs. Create architecture note arch-palinks.
• [x] Forgejo issue — ldraney/palinks#18, open

File Targets

• [x] Dockerfile — verified: line 26 uses docker.io/library/ruby:3.4.9-slim, lines 30-33 manual apt-get for jemalloc and postgresql-client, lines 42-43 manual user creation. Divergence from platform standard confirmed.
• [x] .woodpecker.yaml — verified: build stage already uses ruby-rails-build from Harbor (correct). No runtime image referenced in pipeline.
• [x] docker-compose.yml — verified: dev uses ruby-rails-build from Harbor (correct, not affected by runtime change).
• [x] docs/pipeline.md — verified: exists, 141 lines, documents current pipeline. This is the spike deliverable target.

Repo Placement

OK. Issue correctly filed on palinks as the primary repo. The issue body correctly identifies that investigation spans palinks, pal-e-services, and pal-e-deployments. Since this is a spike (investigation, not code), single-repo filing is appropriate.

Dependencies

• Board item #1227 (Add Woodpecker CI pipeline) — done. Prerequisite satisfied.
• Board item #1228 (Create production kustomize overlay) — done. Prerequisite satisfied.
• Board item #1229 (Cutover: migrate DB and decommission local Puma) — done. Production is already containerized.
• No blocking items in todo/in_progress/next_up.

Acceptance Criteria

Spike deliverables are clear and verifiable:

• docs/pipeline.md updated with findings — agent can verify file was modified with runtime alignment content.
• Follow-up ticket created — agent can verify a new Forgejo issue exists referencing the spike.

Sub-questions in the Question section provide good investigation structure. All 7 sub-questions are concrete and answerable.

Blast Radius

Low. The DockerHub ruby-slim reference exists only in Dockerfile:26. No other files reference it. The runtime image change is isolated to the production Dockerfile runtime stage. Dev workflow (docker-compose) uses ruby-rails-build and is unaffected. The pipeline (.woodpecker.yaml) builds the Dockerfile but doesn't reference the runtime image directly.

Decomposition Assessment

No decomposition needed. Single investigation spike with 2 deliverables, 1 primary repo, 1-hour time-box. Well within the 5-minute agent execution rule for the docs update and ticket creation that follow.

Recommendation

• [SCOPE] Create project page note project-palinks in pal-e-docs with a user-stories section that references the containerize-palinks story. The repo has excellent docs in docs/ but pal-e-docs has no project page for traceability.
• [SCOPE] Create architecture note arch-palinks in pal-e-docs. The repo has thorough architecture docs in docs/architecture.md but pal-e-docs has no backing note.

Both SCOPE items are platform-level traceability gaps, not issues with this ticket's content. The spike scope itself is well-written and ready for execution once the backing notes exist.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Spike
• [x] Lineage -- Standalone, adequate context
• [x] Repo -- Multiple (palinks, pal-e-platform, pal-e-services, pal-e-deployments)
• [x] Question -- Well-structured with sub-questions covering Keycloak setup, Rails schema, role model, platform provisioning, OIDC flow
• [x] Deliverables -- docs/auth.md + follow-up tickets
• [x] Time-box -- 3 hours
• [x] Related -- Lists all affected repos and Spike #15

All required spike template sections are present and well-formed.

Traceability

• [x] story:auth-roles label -- present on board item
• [ ] story note MISSING -- project-palinks note does not exist in pal-e-docs. Cannot verify user story entry. However, docs/user-stories.md in the repo does define US-4 (Role-Based Link Visibility) and US-8 (Authentication) which map to this spike. [SCOPE] Create project-palinks note with user-stories section in pal-e-docs.
• [x] arch:palinks label -- present on board item
• [ ] arch note MISSING -- No arch-palinks note found in pal-e-docs. The repo does contain docs/architecture.md with substantial Keycloak integration design. [SCOPE] Create architecture note arch-palinks in pal-e-docs (can reference or mirror the repo docs).
• [x] Forgejo issue -- ldraney/palinks#16, state: open

File Targets

• [x] docs/auth.md -- does NOT exist yet (correct for a spike deliverable that will be created)
• [x] docs/architecture.md -- EXISTS and already contains Keycloak auth model, data model with users/clicks/feature_flags tables, role definitions, OIDC flow diagrams
• [x] docs/visibility.md -- EXISTS and already contains 3-tier visibility model (superadmin, member, public) with schema impact and access scopes
• [x] docs/user-stories.md -- EXISTS with US-4 (Role-Based Visibility) and US-8 (Authentication) directly relevant to this spike
• [ ] Role model inconsistency -- ISSUE: The Forgejo issue describes 2 roles (superadmin, member). docs/architecture.md defines 4 roles (admin, collaborator, lead, public). docs/visibility.md defines 3 tiers (superadmin, member, public). The spike should reconcile these conflicting models.

Repo Placement

Correctly identifies multiple repos (palinks, pal-e-platform, pal-e-services, pal-e-deployments). The Forgejo issue is filed on palinks which is the primary service. Cross-repo questions are framed as investigation items, not file changes. Appropriate for a spike.

Dependencies

• Spike #15 (Route palinks.app domain to production) -- open, directly related. OIDC redirect URIs depend on the production domain being settled. The issue correctly notes this relationship.
• Board item #1379 (Spike: Define link visibility tiers and assign current links) -- also in backlog with story:auth-roles label. This spike should run after #1378 since it needs the schema design to assign visibility tiers. Not documented as a dependency in #1378.
• Board item #1381 (Write dev seed data for representative local environment) -- story:auth-roles, depends on schema decisions from this spike. Not documented.
• No existing Keycloak/OIDC code in the codebase (confirmed by grep). Current schema has only a links table with no users, no visibility column, no feature flags.

Acceptance Criteria

Deliverables are appropriate for a spike:

• docs/auth.md creation -- verifiable by file existence and content review
• Follow-up tickets created -- verifiable by checking Forgejo issues

However, given that docs/architecture.md and docs/visibility.md already contain substantial Keycloak design, the deliverable should clarify whether docs/auth.md is a new standalone doc or a consolidation/refinement of existing design spread across multiple docs.

Blast Radius

• No existing auth code to disrupt -- the codebase has zero Keycloak/OIDC references in Ruby files
• Schema is minimal (single links table) so adding users/clicks/feature_flags tables is additive, not disruptive
• Cross-repo blast radius is contained to investigation only (spike produces docs, not code changes)
• The role model inconsistency across existing docs could propagate confusion into follow-up tickets if not reconciled during this spike

Decomposition Assessment

This is a spike (investigation, not implementation). Single deliverable is docs/auth.md + follow-up tickets. Touches 1 file target in 1 repo for the actual output. Cross-repo investigation is reading, not writing. Well within the 5-minute rule for an agent pass. No decomposition needed.

Recommendations

• [SCOPE] Create project-palinks note in pal-e-docs with a user-stories section (can reference the repo's docs/user-stories.md).
• [SCOPE] Create architecture note arch-palinks in pal-e-docs (can reference the repo's docs/architecture.md).
• [BODY] Add note to spike question: reconcile the role model inconsistency across docs/architecture.md (4 roles: admin, collaborator, lead, public), docs/visibility.md (3 tiers: superadmin, member, public), and the issue body (2 roles: superadmin, member). The spike deliverable should settle the canonical role model.
• [BODY] Clarify deliverable: specify whether docs/auth.md consolidates/replaces the auth sections in docs/architecture.md and docs/visibility.md, or supplements them. Existing docs already contain substantial Keycloak design.
• [BODY] Document downstream dependencies: Board items #1379 (visibility tier assignment) and #1381 (dev seed data) depend on schema decisions from this spike.

Verdict: READY

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, dev-only concern
• [x] Repo — ldraney/palinks
• [x] User Story — present, well-formed
• [x] Context — clear motivation
• [x] File Targets — db/seeds.rb
• [x] Acceptance Criteria — 7 items
• [x] Test Expectations — idempotency test + docker command
• [x] Constraints — 3 constraints listed
• [x] Checklist — standard PR checklist
• [x] Related — references issue #17 and story:auth-roles

Traceability

• [x] story:auth-roles label — present on board item
• [ ] story note MISSING — project-palinks note does not exist in pal-e-docs, so user-stories section cannot be verified. However, this is foundational dev tooling work. Acceptable for now.
• [x] arch:palinks label — present on board item
• [ ] arch note MISSING — no arch-palinks note found in pal-e-docs. [SCOPE] Create architecture note arch-palinks for component palinks. However, this is a 1-point seed data ticket — not blocked by missing arch note.
• [x] Forgejo issue — ldraney/palinks#19, state: open

File Targets

• [x] db/seeds.rb — verified: file exists, currently contains only the default Rails boilerplate comment (no actual seed logic yet). This is the correct target for new seed data.

Repo Placement

OK. Issue filed on ldraney/palinks, file target is in ldraney/palinks. Single repo, no mismatch.

Dependencies

• No blocking dependencies. All referenced columns exist in current schema: url, title, description, metadata (JSONB with tags), forgejo_url, position, favorite.
• Issue references #17 (visibility tiers) as a future concern. AC item "Evolves to include visibility tiers once that column lands" correctly defers this — no visibility column exists yet, and no unreleased migration adds one.
• Board item #1379 (Spike: Define link visibility tiers) is in backlog — not a blocker for this ticket.
• Board item #1378 (Spike: Keycloak integration and role-based schema design) is in backlog — not a blocker.

Acceptance Criteria

Testable and complete. Minor observation:

• AC says "Includes links with varied metadata (tags, categories)" — the schema has no category column or metadata key. Tags are stored in metadata["tags"] as an array. The word "categories" should be understood as "varied tag values" rather than a separate data structure. Not a blocker — an implementing agent can interpret this correctly from the model code.
• AC item "Evolves to include visibility tiers" is forward-looking, not testable now. Acceptable as a reminder, not a hard criterion.
• All other criteria are concrete and agent-verifiable.

Blast Radius

Minimal. Seeds are dev-only (opt-in via rails db:seed), never auto-run. No production impact. No downstream consumers. The find_or_create_by constraint ensures idempotency.

Decomposition Assessment

No decomposition needed. Single file target (db/seeds.rb), single repo, 7 AC items but all are facets of a single write operation. Estimated agent work well under 5 minutes.

Recommendation

No action needed. Ticket is well-scoped for a single agent pass.

Non-blocking observations for future board hygiene:

• [SCOPE] Create project page project-palinks with user-stories section (affects all palinks board items, not just this one).
• [SCOPE] Create architecture note arch-palinks (affects all palinks board items).

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Spike
• [x] Lineage — references ldraney/palinks #16
• [x] Repo — ldraney/palinks
• [x] Question — well-structured with 6 sub-questions
• [x] Deliverables — 3 checklist items
• [x] Time-box — 2 hours
• [x] Related — lists service, related issue, parent story

All required spike template sections present and complete.

Traceability

• [x] story:auth-roles label — present on board item
• [ ] story note MISSING — [SCOPE] No project-palinks note exists in pal-e-docs. User stories live in docs/user-stories.md in the repo (US-4: Role-Based Link Visibility is the relevant story). Create project-palinks project page with user-stories section, or document the repo-local convention.
• [x] arch:palinks label — present on board item
• [ ] arch note MISSING — [SCOPE] No arch-palinks note found in pal-e-docs. Architecture docs live in docs/architecture.md in the repo. Create arch-palinks note in pal-e-docs or link to the repo doc.
• [x] Forgejo issue — ldraney/palinks#17, open

File Targets

Spike template expects a docs/{topic}.md as the primary file target.

• [x] docs/visibility.md — already exists in the repo with tier definitions and mermaid diagrams. However, the "Current Link Inventory" section (line 105) is marked TODO with an empty table. This is the core deliverable of the spike.

Note: docs/visibility.md already existing means part of the spike deliverable is partially done. The agent executing this spike must complete the inventory, not create the file from scratch.

Repo Placement

OK. Issue filed on ldraney/palinks, work targets ldraney/palinks. Single repo.

Dependencies

• ldraney/palinks #16 (Keycloak integration spike, board item #1378) — open, in backlog. The issue body says #16 "depends on visibility model," meaning this spike (#17) should complete first. This dependency ordering is correct and documented in the issue lineage.
• Board item #1381 (Write dev seed data) — also story:auth-roles, in backlog. Seed data will need to reference visibility tiers once defined. Not a blocker, but should consume this spike's output.

Acceptance Criteria

Spike deliverables assessment:

• docs/visibility.md created with tier definitions, mermaid diagram, and link inventory audit — partially verifiable. The doc already exists with tiers and diagrams. The inventory audit is the remaining work. An agent can verify this by checking the table is populated.
• Each current link assigned a proposed visibility tier — verifiable. Agent can query the database or read the completed table.
• Follow-up ticket for adding visibility column to links schema — verifiable. Agent can check Forgejo for a new issue.

Blast Radius

Critical inconsistency found: The codebase has two conflicting role/tier models:

• docs/visibility.md defines 3 tiers: public, member, superadmin
• docs/architecture.md (line 70-76) and docs/user-stories.md (US-4, line 103) define 4 roles: public, lead, collaborator, admin

This spike must reconcile these two models. The issue's Question section asks the right questions but doesn't acknowledge this existing inconsistency. The executing agent needs to be aware that the docs already contain conflicting tier definitions.

No visibility column exists in the schema yet (db/schema.rb has no visibility field). The Link model has no visibility scope. Impact is contained to docs and follow-up tickets.

Decomposition Assessment

Single repo, docs-only output, 3 deliverables, estimated <30 min agent time. No decomposition needed.

Recommendations

• [BODY] Add a note in the Question section acknowledging that docs/visibility.md already exists with partial content (tiers and diagrams done, inventory TODO). The spike should be framed as "complete the existing doc" not "create from scratch."
• [BODY] Add a sub-question: "Reconcile 3-tier model (visibility.md: public/member/superadmin) with 4-role model (architecture.md: public/lead/collaborator/admin). Which is canonical?"
• [SCOPE] Create project-palinks project page in pal-e-docs with a user-stories section linking to repo docs.
• [SCOPE] Create arch-palinks architecture note in pal-e-docs or register the repo-local docs/architecture.md as the canonical source.

Architecture: palinks

Diagram

graph TB
    subgraph "Hetzner Edge"
        CADDY[Caddy reverse proxy
178.156.129.142 cpx11 Ashburn]
    end

    subgraph "Home Lab — k3s"
        RAILS[palinks Rails 8.1
kustomize overlay]
        PG[(PostgreSQL
CNPG)]
        RAILS --> PG
    end

    subgraph "CI"
        WP[Woodpecker CI
build / test / push / deploy]
        HARBOR[Harbor registry]
        WP --> HARBOR
        HARBOR --> RAILS
    end

    subgraph "DNS"
        GODADDY[GoDaddy
palinks.app]
    end

    subgraph "iOS"
        IOS[palinks-ios
Turbo Native shell]
    end

    USER[Browser] -->|palinks.app| GODADDY
    GODADDY -->|A record 178.156.129.142| CADDY
    CADDY -->|Tailscale mesh| RAILS

    USER2[Browser] -->|palinks.tail5b443a.ts.net| RAILS

    IOS -->|WKWebView| CADDY

Components

Key Decisions

• Rails 8.1 — server-rendered app, Puma on port 3000, no reverse proxy inside cluster (Tailscale funnel terminates TLS)
• Custom domain live — palinks.app routes through Hetzner edge (Caddy + Tailscale mesh), DNS A records at GoDaddy
• iOS via Turbo Native — WKWebView wraps the Rails app, ~40 lines of Swift, most updates are web-only
• No Keycloak auth today — auth/roles/visibility designed (spikes done) but deferred until after App Store launch
• CNPG for PostgreSQL — operator-managed database on k3s, consistent with other platform apps
• JSONB metadata — escape hatch for fast iteration; promote to columns when patterns stabilize
• Deployment parity — auto-migrations, secrets-based config match landscaping-assistant patterns

Current Access

Related

• project-palinks — project page
• arch-godaddy-tofu — DNS provider architecture
• Canonical repo docs at docs/architecture.md — diagrams and data model details
• iOS docs at docs/ios.md — build, deploy, and config

Vision

Multi-user link hub and portfolio — a dashboard for curating, sharing, and tracking URLs. The front door to Lucas Draney's platform: clients, leads, and collaborators discover services; Lucas controls what each audience sees.

Status

Core app shipped: link CRUD, favorites, drag-and-drop reordering, click tracking, canvas layout with filter tabs (popular/favorites/other). Custom domain live at palinks.app via Hetzner edge (Caddy + Tailscale mesh). CI/CD pipeline operational (Woodpecker → Harbor → ArgoCD Image Updater, ~5 min merge-to-live).

iOS shell created: palinks-ios repo (Turbo Native + HotwireNative) with PR #1 merged. Current sprint: TestFlight beta → App Store submission.

Auth/roles/visibility designed (spikes complete) but not yet implemented — deferred until after App Store launch.

Architecture

Rails 8.1 on k3s, PostgreSQL (CNPG), Puma on port 3000, Tailscale Funnel ingress. Hetzner edge node (Caddy + Tailscale) as reverse proxy for palinks.app. iOS: Turbo Native shell in separate repo (palinks-ios). Detailed architecture in repo: docs/architecture.md

Roles

• superadmin — Lucas. Sees all links, all flags, user management.
• member — Authenticated users (2FA-verified email + phone). Sees public + member links, direct contact info, limited flags.
• (anonymous) — Unauthenticated. Public links and contact form only. Not a Keycloak role.

User Stories

• story:containerize-palinks — Containerization and CI/CD pipeline (done)
• story:sortable-links — Drag-and-drop reordering (done)
• story:canvas-layout — Canvas view with activity-based card sizing (done)
• story:custom-domain — Route palinks.app to production (done)
• story:ios-distribution — Turbo Native iOS shell + TestFlight + App Store (in progress)
• story:auth-roles — Keycloak auth, roles, visibility, feature flags (backlog)
• story:ci-testing — Test coverage and CI test step (backlog)

Current Sprint: TestFlight Beta

• #57 — Update stale docs, add CLAUDE.md, iOS docs, app icon (PR #58, in review)
• #59 — Build and upload first TestFlight beta
• #60 — Mobile CSS polish for iOS WKWebView
• #61 — App Store metadata and privacy policy page
• #55 — Fix N+1 query and polish on link filters
• #54 — Add test coverage and CI test step

Repos

• ldraney/palinks — application code
• ldraney/palinks-ios — Turbo Native iOS shell (HotwireNative + Fastlane)

Board

board-palinks

Verdict: PASS

Ticket

ldraney/palinks#36 — Create clicks table and tracking. Adds a clicks table to record link usage, with session-based anonymous tracking, redirect-through pattern, and click count display on the show page.

Merged PR: #42

Environment

Production cluster (archbox), namespace palinks, URL: https://palinks.tail5b443a.ts.net

Pod: palinks-6b8fbf884f-qb5ss, image: harbor.tail5b443a.ts.net/palinks/app:e5352d7fb5e91bfe773bfab6c7c22e8da4b00018

Tiers Executed

Tier 1 (local tests) + Tier 3 (production health check)

Checks

Tier 1: Local Tests

bin/rails test: 14 runs, 28 assertions, 0 failures, 0 errors, 0 skips

Tests cover: Click model validations (attribution, clicked_at, belongs_to), controller integration (POST creates click and redirects, 404 for missing link, click_count increments)

Tier 3: Production

• Woodpecker pipeline #19: success (clone + build-and-push both green)
• ArgoCD Image Updater: detected new tag e5352d7f..., pushed to pal-e-deployments, ArgoCD synced
• Pod: Running, Ready 1/1, 0 restarts
• Health check: /up returns 200
• Click endpoint: POST /links/6/click returns 302, redirects to correct URL, increments click count

Regression Check

All existing routes verified healthy after deployment:

• / (root/index) — 200
• /links — 200
• /links/new — 200
• /links/6 (show) — 200
• /links/6/edit — 200
• /up (health) — 200

Favorites, edit, delete buttons all present in rendered HTML. No console errors or broken elements observed.

Discovered Issues

None.

Validation

• Issue: #419 — Add Hetzner edge node as reverse proxy for custom domains
• PRs: #420 (module), #421 (secrets), #422 (4 missing secrets), #423 (OIDC secrets), #424 (ACL + OAuth rotation + apply fixes)

Checks

• ✓ tofu apply succeeded — server + tailnet key created
• ✓ VPS running at 178.156.129.142 (Ashburn, cpx11)
• ✓ Joined correct tailnet: edge-proxy.tail5b443a.ts.net
• ✓ Tailscale ACL grants edge→k8s access
• ✓ Firewall allows 22/80/443 only
• ✓ Cloud-init completed (Tailscale + Caddy installed)
• ✓ All secrets GPG-encrypted in pillar, ~/secrets updated

Remaining

• DNS A record at GoDaddy (manual, post-validation)
• Caddy Caddyfile configuration via Salt (follow-up work)
• palinks/docs/custom-domain.md needs update to reflect Hetzner edge decision