Landscaping Assistant

Verdict: READY

Note: Both READY and APPROVED are accepted as passing verdicts by the check-board-advance hook. Use either keyword interchangeably.

Template Completeness

Issue type: Bug (template-issue-bug). All required sections present:

• [x] Type
• [x] Lineage
• [x] Repo
• [x] What Broke
• [x] Repro Steps
• [x] Expected Behavior
• [x] Environment
• [x] Acceptance Criteria
• [x] Related

Traceability

• [x] story:app-store-submission label — "Submit and maintain iOS App Store listing"
• [x] story note verified — found in project-landscaping-assistant user-stories table
• [x] arch:keycloak label — Keycloak authentication component
• [x] arch note verified — arch-keycloak note exists in pal-e-docs (id 1728, doc type, active)
• [x] Forgejo issue — ldraney/pal-e-services#208, open

File Targets

• [x] terraform/k3s.tfvars (symlink to ~/secrets/pal-e-services/k3s.tfvars) — verified: landscaping realm exists at lines 102-118, confirmed attributes field is absent (0 occurrences in file)
• [x] terraform/keycloak.tf — verified: attributes = each.value.attributes already present (added by PR #207, commit dbed215)
• [x] terraform/variables.tf — verified: attributes = optional(map(string), {}) already defined (added by PR #207)

IaC support is in place. Only the tfvars config value needs to be set.

Repo Placement

OK. Issue filed on ldraney/pal-e-services, fix is in the same repo (k3s.tfvars + tofu apply). No cross-repo changes needed.

Dependencies

Related board items on board-landscaping-assistant:

• #1940 (qa): "Keycloak login/reset redirects to Tailscale URL instead of public domain" — downstream symptom of same root cause. This fix resolves the persistence risk for that item.
• #1991 (qa): "Switch Keycloak auth URL to auth.landscaping-assistant.app" — related Keycloak URL alignment work.
• #1983 (qa): same story (app-store-submission) + arch:keycloak — related submission work.
• #1927 (validation): arch:keycloak + story:account-email — Keycloak email flow, indirectly affected if frontendUrl is lost on restart.

No hard blockers identified. This ticket can proceed independently.

Acceptance Criteria

3 criteria, all verifiable by an agent:

• AC1: k3s.tfvars updated with attributes = { frontendUrl = "https://auth.landscaping-assistant.app" } — verifiable via file read
• AC2: tofu apply run successfully — verifiable via exit code and output
• AC3: Discovery doc at auth.landscaping-assistant.app returns correct URLs — verifiable via curl

Note: k3s.tfvars is a gitignored secrets file (symlink). This is an operational config change, not a PR-able code change. The agent will edit the secret directly and run tofu apply.

Blast Radius

Low risk. The attributes variable defaults to {}, so adding it to one realm does not affect other realms. However, other production realms with public domains (ISS at intelligentstaffingsystems.ai, prediction-assistant) may eventually need the same frontendUrl treatment. That is out of scope for this ticket.

Decomposition Assessment

1 file target, 3 acceptance criteria, estimated agent time <5 minutes. No decomposition needed.

Recommendation

No action needed. Scope is solid, traceability complete, file targets verified, and the work fits comfortably in a single agent pass.

Verdict: READY

Re-review after NEEDS_REFINEMENT. All five issues from the first review have been resolved.

Template Completeness

• [x] Type — Bug
• [x] Lineage — Standalone, discovered during App Store resubmission testing 2026-08-02. References board item #1940.
• [x] Repo — Cross-repo: pal-e-platform (DNS + Caddy), pal-e-deployments (KEYCLOAK_URL env var). Correct repos identified.
• [x] What Broke — TLS handshake failure on auth.palinks.app, login/registration broken for all public users
• [x] Repro Steps — 3 steps with curl verification
• [x] Expected Behavior — auth.landscaping-assistant.app terminates TLS via Hetzner edge proxy, OAuth flow completes
• [x] Environment — prod / landscaping-assistant, commit 14952b6, Hetzner Caddy at 178.156.129.142
• [x] File Targets — 3 files with exact line numbers, plus thorough "NOT changing" section with rationale
• [x] Acceptance Criteria — 6 criteria, all testable
• [x] Related — project-landscaping-assistant, board items #1940 and #1572

All required bug template sections present. The File Targets and "NOT changing" documentation are excellent scope discipline.

Previous Review Issues — All Resolved

• [x] Repo section fixed: now correctly names pal-e-platform and pal-e-deployments (was incorrectly saying pal-e-services for edge proxy)
• [x] KEYCLOAK_URL location clarified: deployment-patch.yaml lines 62-63 and 135-136, verified in codebase
• [x] File targets added: all 3 files specified with line numbers
• [x] arch label fixed: now arch:keycloak (was arch:rails-frontend)
• [x] #1940 dependency documented in Lineage and Related sections

Traceability

• [x] story:app-store-submission label — "Submit and maintain iOS App Store listing"
• [x] story note verified — found in project-landscaping-assistant user-stories section
• [x] arch:keycloak label — Keycloak OIDC authentication
• [x] arch note verified — arch-keycloak note exists in pal-e-docs (id: 1728)
• [x] Forgejo issue — ldraney/landscaping-assistant#360, open

File Targets

• [x] pal-e-platform/terraform/dns.tf — verified: file exists, contains A records for other domains pointing to module.hetzner_edge.server_ipv4. No auth subdomain record exists for landscaping-assistant.app. Pattern for new record is clear from existing entries (lines 12-18).
• [x] pal-e-platform/salt/pillar/caddy.sls — verified: file exists, contains site entries with domain/proxy_target/www_redirect keys. No auth subdomain entry exists. Proxy target would be keycloak.tail5b443a.ts.net.
• [x] pal-e-deployments/overlays/landscaping-assistant/prod/deployment-patch.yaml — verified: lines 62-63 show KEYCLOAK_URL: "https://auth.palinks.app" and lines 135-136 show identical value in second container spec. Both match the issue description exactly.

NOT changing assertions verified:

• [x] KEYCLOAK_ISSUER at lines 64-65 and 137-138 confirmed as https://keycloak.tail5b443a.ts.net/realms/landscaping
• [x] KEYCLOAK_ADMIN_URL at lines 66-67 and 139-140 confirmed as Tailnet hostname
• [x] pal-e-services/terraform/k3s.tfvars redirect URIs — correctly excluded (they point to app callback URL, not auth domain)

Repo Placement

Forgejo issue filed on ldraney/landscaping-assistant but changes are in ldraney/pal-e-platform and ldraney/pal-e-deployments. The issue explicitly acknowledges this cross-repo scope. Since all three changes are tightly coupled (DNS + Caddy + env var must all change together) and landscaping-assistant is the affected service, this placement is acceptable. PRs will use Closes ldraney/landscaping-assistant#360.

Dependencies

• #1940 [qa] — "Keycloak login/reset redirects to Tailscale URL instead of public domain." Related (same auth domain area) but not blocking. #1940 addresses Keycloak-side redirect URLs; this ticket addresses Rails-side KEYCLOAK_URL + DNS + Caddy routing. Independent fixes.
• #1572 [done] — Prior issuer mismatch fix. The ticket explicitly guards against regressing this.
• #1460 [backlog] — Parent custom-domain story work. The apex domain already works; this ticket extends to the auth subdomain.
• #1463 [done] — Caddy reverse proxy for landscaping-assistant.app. Provides the pattern this ticket follows.

No undocumented dependencies. No blockers.

Acceptance Criteria

6 criteria, all verifiable:

• AC 1-3: Infrastructure verification (dig, curl, Caddy logs) — agent-verifiable post-apply
• AC 4: Code change verification (grep deployment-patch.yaml) — agent-verifiable
• AC 5: End-to-end login from public network — requires browser automation or validate-ui skill
• AC 6: Regression guard (grep for unchanged KEYCLOAK_ISSUER) — agent-verifiable

Blast Radius

• auth.palinks.app appears ONLY in landscaping-assistant overlay (deployment-patch.yaml lines 63 and 136). No other apps reference it.
• Other apps (pal-enterprises, intelligentstaffingsystems) use secretKeyRef for KEYCLOAK_URL, not hardcoded values. No cross-app impact.
• No auth subdomain pattern exists in DNS or Caddy for any app currently. This will be the first.
• Minor: secrets.enc.yaml line 11 has an encrypted KEYCLOAK_URL that is unused (deployment-patch overrides with hardcoded value). Cleanup opportunity, not a blocker.

Decomposition Assessment

3 file targets across 2 repos (below threshold). 6 acceptance criteria (marginally above 5-AC threshold), but all changes are mechanically simple: one Terraform resource, one Caddy site entry, two YAML value swaps. Estimated agent work under 5 minutes for code changes. No decomposition needed.

Recommendation

No action needed. All issues from the first review have been resolved. Scope is solid, file targets verified, traceability complete. Ready to move to todo.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Bug
• [x] Lineage — Standalone, related to #1940
• [x] Repo — Cross-repo listed (but incomplete, see below)
• [x] What Broke — Clear symptoms with curl evidence
• [x] Repro Steps — Concrete 3-step repro
• [x] Expected Behavior — Clear target state
• [x] Environment — Cluster, commit, edge proxy identified
• [x] File Targets — Present (has inaccuracies, see below)
• [x] Acceptance Criteria — 6 criteria listed
• [x] Related — Project and related board item referenced

All required bug template sections present.

Traceability

• [x] story:app-store-submission label — found in project-landscaping-assistant user-stories table
• [x] story note verified — entry exists in project-landscaping-assistant user-stories section
• [x] arch:keycloak label — Keycloak authentication component
• [x] arch note verified — arch-keycloak note exists in pal-e-docs (id: 1728)
• [x] Forgejo issue — ldraney/landscaping-assistant#360, state: open

File Targets

• [x] pal-e-platform/terraform/dns.tf — verified: file exists, has landscaping-assistant.app root A record (line 12-18) but no auth subdomain record. Adding auth A record is correct.
• [x] pal-e-platform/salt/pillar/caddy.sls — verified: file exists, has landscaping-assistant.app site entry (lines 17-20) but no auth subdomain entry. Adding auth site is correct.
• [x] pal-e-services/terraform/k3s.tfvars — verified: file exists (symlink to secrets). Landscaping-assistant client config starts at line 204. ISSUE: ticket says to add https://auth.landscaping-assistant.app/* to redirect URIs and web origins (lines 214-230), but redirect URIs are for app callbacks (where Keycloak sends users AFTER auth), not for Keycloak's own frontend URL. Adding Keycloak's own domain as a redirect URI is incorrect for standard OAuth. Clarify what Keycloak config change is actually needed (likely realm frontend URL or server config, not client redirect URIs).
• [ ] pal-e-deployments/overlays/landscaping-assistant/prod/deployment-patch.yaml — MISSING from ticket. This file contains the hardcoded KEYCLOAK_URL: "https://auth.palinks.app" at lines 62-63 (init container) and lines 135-136 (app container). This is where the env var actually lives.
• [ ] KEYCLOAK_ISSUER concern — same file, lines 64-65 and 137-138, set to https://keycloak.tail5b443a.ts.net/realms/landscaping. Board item #1572 (done) fixed an issuer mismatch with auth.palinks.app previously. Changing the auth domain may resurface the issuer mismatch. Ticket should state whether KEYCLOAK_ISSUER also changes or explain why it stays.

Repo Placement

Issue filed on ldraney/landscaping-assistant. Ticket correctly identifies this as cross-repo and lists pal-e-platform, pal-e-services, and landscaping-assistant. However, pal-e-deployments is missing from the Repo section. The KEYCLOAK_URL env var is hardcoded in pal-e-deployments/overlays/landscaping-assistant/prod/deployment-patch.yaml (lines 62-63, 135-136), not "not git-tracked" as the ticket claims. The landscaping-assistant repo itself has no fix files — only pal-e-platform, pal-e-services, and pal-e-deployments need changes.

Dependencies

• Board item #1940 ("Bug: Keycloak login/reset redirects to Tailscale URL instead of public domain") — in QA column. Same root cause (wrong auth domain). Ticket documents this relationship. Not a blocker but changes should be coordinated.
• Board item #1572 ("Bug: Keycloak issuer mismatch blocks login via auth.palinks.app") — done. Established the KEYCLOAK_ISSUER pattern. Relevant precedent for the issuer concern above.

Acceptance Criteria

6 criteria, all agent-verifiable via CLI commands (dig, curl, kubectl, grep). Missing criterion: ticket should verify KEYCLOAK_ISSUER still works after the domain switch (or is updated). Otherwise solid and testable.

Blast Radius

• auth.palinks.app appears ONLY in pal-e-deployments/overlays/landscaping-assistant/prod/deployment-patch.yaml (2 occurrences). No other apps reference it.
• The landscaping-assistant app code reads KEYCLOAK_URL from ENV in sessions_controller.rb, application_controller.rb, and keycloak_admin_service.rb — all read-only, no hardcoded URLs. Changing the env var value is sufficient for the app.
• No staging impact — staging uses Tailscale URLs, not auth.palinks.app.
• The encrypted secrets.enc.yaml also contains a KEYCLOAK_URL entry but the plain value in deployment-patch.yaml takes precedence.

Decomposition Assessment

4+ file targets across 3 repos (pal-e-platform, pal-e-services, pal-e-deployments). 6 acceptance criteria. Estimated agent work: borderline on 5-minute rule due to cross-repo nature (DNS + Caddy + Keycloak + deployment). However, per project convention, no decomposition — keep unified and discuss sequencing after review.

Recommendation

• [BODY] Add pal-e-deployments to the ### Repo section.
• [BODY] Replace the "Deployment (pal-e-services or pal-e-deployments)" file target with: pal-e-deployments/overlays/landscaping-assistant/prod/deployment-patch.yaml lines 62-63 and 135-136. Remove the claim that KEYCLOAK_URL is "not git-tracked".
• [BODY] Clarify the k3s.tfvars change — redirect URIs are for app callbacks, not Keycloak's own frontend URL. If the intent is to configure Keycloak's frontend URL or issuer to use auth.landscaping-assistant.app, specify the correct Terraform resource/setting.
• [BODY] Address whether KEYCLOAK_ISSUER (currently https://keycloak.tail5b443a.ts.net/realms/landscaping) needs updating. Board item #1572 (done) established this pattern — changing the auth domain may break token validation if the issuer doesn't match.

Verdict: READY

Re-review after prior NEEDS_REFINEMENT findings were addressed. Previous review checked stale local checkout; this review verified all file targets against origin/main (which includes merged PR #351). Story label corrected to story:app-store-submission, arch note arch-rails-frontend created.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Follow-up to #349 / PR #351
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — proper As/I want/So that format
• [x] Context — accurate description of current state on main after PR #351 merge
• [x] File Targets — 3 modify targets, 3 don't-touch targets, all correct
• [x] Feature Flag — none (appropriate for CSS/HTML/copy changes)
• [x] Acceptance Criteria — 6 items, all testable
• [x] Test Expectations — 4 items with specific checks
• [x] Constraints — 3 items (inline SVG, no gems, match existing naming)
• [x] Checklist — standard 3 items
• [x] Related — project-landscaping-assistant

Traceability

• [x] story:app-store-submission label — "Submit and maintain iOS App Store listing" found in project-landscaping-assistant user-stories table
• [x] story note verified — app-store-submission entry exists in project-landscaping-assistant user-stories section
• [x] arch:rails-frontend label — "Convention: Rails Frontend Architecture"
• [x] arch note verified — arch-rails-frontend note exists in pal-e-docs (convention note, active, created 2026-08-02)
• [x] Forgejo issue — ldraney/landscaping-assistant#355, state: open

File Targets

All verified against origin/main (includes merged PR #351):

• [x] app/views/landing/index.html.erb — verified: exists on origin/main. Contains hero with app_store_badge partial render, feature cards, bottom CTA with second badge render. No header/hamburger nav (matches issue Context). Previous review checked stale local branch that had different content.
• [x] app/views/landing/_app_store_badge.html.erb — verified: exists on origin/main. Contains inline SVG App Store badge linking to apps.apple.com/app/id6780226794. Previous review incorrectly reported missing because local checkout was behind origin/main.
• [x] app/assets/stylesheets/application.css — verified: exists (74k), contains 28 landing-related CSS rules following .landing-* naming convention.

Don't-touch targets verified:

• [x] app/views/sessions/new.html.erb — exists, correctly excluded
• [x] app/views/layouts/application.html.erb — exists, correctly excluded (hamburger belongs in landing template only)
• [x] app/controllers/landing_controller.rb — exists, correctly excluded

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, Repo section says ldraney/landscaping-assistant. Single repo, no cross-repo concerns.

Dependencies

• Board item #1988 "Mobile app: skip landing page, go straight to login/register" shares story:app-store-submission label and is in backlog. Related but not blocking — it handles Turbo Native mobile routing, separate from web landing page changes.
• Items #1983 and #1984 in QA column share story:app-store-submission but are on different arch components (keycloak, rails-app). Not blocking.
• No hard dependencies. No blockers identified.

Acceptance Criteria

All 6 criteria are concrete and agent-verifiable:

• AC1: Google Play badge next to App Store badge — verifiable. Issue explicitly states "Play Store URL TBD — use placeholder href until Android listing is live." Agent has clear guidance.
• AC2: Header with hamburger menu, links to Sign In (/login) and Register (/login with note that login page has Create Account link) — verifiable via HTML structure and href checks.
• AC3: Landing page copy pitches web access as free demo — verifiable via template content.
• AC4: Mobile downloads remain primary CTA — verifiable via prominence/ordering.
• AC5: Web demo CTA secondary but prominent, pointing to /login — verifiable.
• AC6: Responsive layout across mobile and desktop — verifiable via CSS inspection; full visual check in QA.

Blast Radius

Low. Changes isolated to the landing page (web-only, public-facing). The .landing-* CSS naming convention (enforced by arch-rails-frontend) prevents style collisions with authenticated views. The _app_store_badge partial is only rendered on the landing page. No downstream consumers affected.

Decomposition Assessment

3 file targets in 1 repo (under threshold). 6 acceptance criteria (borderline on the >5 rule). All changes are cohesive — single page, single concern, single repo. Estimated agent time well under 5 minutes. No decomposition needed.

Recommendation

No action needed.

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:app-store-submission label — "Submit and maintain iOS App Store listing"
• [x] story note verified — found in project-landscaping-assistant user-stories section
• [x] arch:rails-frontend label — "Rails Frontend Architecture"
• [x] arch note verified — arch-rails-frontend note exists in pal-e-docs
• [x] Forgejo issue — ldraney/landscaping-assistant#355, open

File Targets

• [x] app/views/landing/index.html.erb — verified: exists (5.2k), hamburger markup present at lines 11-21 as claimed, JS toggle at lines 105-117
• [x] app/views/landing/_app_store_badge.html.erb — correctly marked as CREATE target; file does not exist yet
• [x] app/assets/stylesheets/application.css — verified: exists (74k), has .landing-hero/.landing-features/.landing-roles/.landing-footer styles but ZERO styles for .landing-header, .landing-menu-btn, .landing-menu, .landing-logo (confirms ticket claim "zero CSS styles")
• [ ] app/controllers/landing_controller.rb — ISSUE: not listed in File Targets but likely needs modification. AC2 says hamburger should have "links to Login and Register" — the Keycloak registration URL (@registration_url) is only exposed in SessionsController, not LandingController. If the Register link needs a direct Keycloak URL, the controller must be modified.

Repo Placement

OK — issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo change.

Dependencies

• #1988 "Mobile app: skip landing page, go straight to login/register" (backlog, same story:app-store-submission) — related but not blocking. The landing page is web-only; Turbo Native users bypass it per #1988's scope. No dependency conflict.
• #1983 and #1984 (QA, story:app-store-submission) — no direct dependency on this work.
• No items in in_progress block this ticket.

Acceptance Criteria

• 6 ACs — all are verifiable via visual inspection
• AC2 is ambiguous: "links to Login and Register" — does Register mean a direct Keycloak registration URL (requires controller change not in scope) or just /login (where "Create Account" already exists, making a separate link redundant)?
• AC4 "Mobile downloads remain primary CTA" — subjective but can be verified via visual hierarchy (size, position, color treatment)
• AC6 "Layout is responsive" — testable at standard breakpoints but no specific breakpoints listed
• Test Expectations are reasonable and verifiable

Blast Radius

Low. The landing page is a standalone public-facing page routed as the app root (landing#index). It does not use the application layout. No other apps or views share this template. CSS changes use the scoped .landing-* class naming convention, avoiding collisions with authenticated UI styles.

Decomposition Assessment

• 3 file targets, 1 repo — within threshold
• 6 acceptance criteria — exceeds the >5 threshold, but all criteria are tightly coupled (same page, same template). Per user preference, keeping unified is appropriate.
• Estimated agent work: ~5 minutes (inline SVG badges, CSS for hamburger, copy rewrite). Borderline but manageable in one pass.
• No decomposition needed.

Recommendations

• [BODY] Fix Context section: it claims "It currently has: 1. An App Store badge linking to the iOS listing" — this is incorrect. The current index.html.erb has NO badge markup whatsoever. The agent must CREATE badges from scratch, not modify existing ones. Also, the statement "The landing page was rebuilt in #349" is misleading — #349 is a closed planning issue with no associated merged PR; the landing page was built by PR #324/#329.
• [BODY] Add app/controllers/landing_controller.rb to File Targets if Register link should go directly to Keycloak registration URL (currently only available in SessionsController#new via keycloak_registration_url). Alternatively, clarify in AC2 that Register links to /login (which already has a "Create Account" link).

Verdict: READY

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- references #355 (landing page redesign)
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- well-formed As a/I want/So that
• [x] Context -- explains why mobile users should not see the marketing landing page
• [x] File Targets -- one modify target, two do-not-touch targets
• [x] Feature Flag -- none (appropriate for this change)
• [x] Acceptance Criteria -- 4 criteria
• [x] Test Expectations -- 2 request specs + run command
• [x] Constraints -- 3 constraints (User-Agent detection, before_action pattern, match both turbo-ios and turbo-android)
• [x] Checklist -- present
• [x] Related -- references project-landscaping-assistant

Traceability

• [x] story:app-store-submission label -- Submit and maintain iOS App Store listing
• [x] story note verified -- found in project-landscaping-assistant user-stories section
• [x] arch:rails-frontend label -- Rails frontend architecture
• [x] arch note verified -- arch-rails-frontend note exists in pal-e-docs. Notably, the arch note explicitly lists "Turbo Native User-Agent check in controller" as a correct example.
• [x] Forgejo issue -- ldraney/landscaping-assistant#356, open

File Targets

• [x] app/controllers/landing_controller.rb -- verified: exists, contains index action with existing logged_in? redirect and feature_enabled?(:public_landing) check. Correct file for adding Turbo Native User-Agent detection as a before_action or early return.
• [x] app/views/sessions/new.html.erb -- verified: exists (do-not-touch, login page)
• [x] app/views/landing/index.html.erb -- verified: exists (do-not-touch, landing page)
• [x] spec/requests/landing_spec.rb -- verified: exists, already tests landing page and redirect behavior. New Turbo Native specs will extend this file.

Repo Placement

Correct. Issue filed on ldraney/landscaping-assistant, fix is in that same repo. Single-repo change.

Dependencies

• Board item #1987 ("Landing page: Android badge, hamburger nav, web demo pitch") is related (same story, same arch label, references #355) but is in backlog and not a blocker. These two issues are independent -- #356 redirects mobile users away from the landing page, #355 improves the landing page for web visitors.
• Items #1983 and #1984 (app-store-submission, in qa column) -- not blocking.
• No items in in_progress block this work.
• No undocumented dependencies found.

Acceptance Criteria

All 4 criteria are testable by an agent:

• AC 1-2 (Turbo Native iOS/Android redirect): verifiable via request specs with User-Agent headers containing "Turbo Native"
• AC 3 (web browser sees landing page): existing spec already covers this; new spec can assert non-redirect explicitly
• AC 4 (authenticated mobile users go to dashboard): already handled by existing logged_in? check in the controller. This is a regression-prevention criterion, not new work -- the existing test suite covers it.

Test run command is valid: bundle exec rspec spec/requests/landing_spec.rb

Blast Radius

Low. The change is isolated to one controller action (LandingController#index). No other services consume the landing page redirect. No Turbo Native User-Agent detection exists elsewhere in the codebase currently, so this introduces the pattern for the first time. The arch-rails-frontend convention already endorses this exact pattern ("Turbo Native User-Agent check in controller" listed as correct example). Other Rails apps in the ecosystem (believers-elite, botfire, etc.) do not have landing controllers and are not affected.

Decomposition Assessment

No decomposition needed. 1 file target, 1 repo, 4 acceptance criteria, estimated agent work well under 5 minutes (add a before_action or early return, write 2 request specs).

Recommendation

No action needed.

Verdict: APPROVED

Note: Both READY and APPROVED are accepted as passing verdicts by the check-board-advance hook. Use either keyword interchangeably.

Re-review: Previous review (NEEDS_REFINEMENT) had one issue: test run command said rails test but project uses RSpec. Issue body updated to bundle exec rspec. All findings re-verified.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Related to #290 (App Store rejection)
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- present, well-formed
• [x] Context -- thorough background on iPad rejection, SMTP config, CSS hide removal
• [x] File Targets -- 2 modify targets, 2 DO NOT touch targets
• [x] Feature Flag -- "none" (appropriate for UI link + doc update)
• [x] Acceptance Criteria -- 6 criteria
• [x] Test Expectations -- present, run command corrected to bundle exec rspec
• [x] Constraints -- present
• [x] Checklist -- present
• [x] Related -- present

Traceability

• [x] story:app-store-submission label -- "Submit and maintain iOS App Store listing (privacy declarations, review compliance, metadata)"
• [x] story note verified -- found in project-landscaping-assistant user-stories section
• [x] arch:keycloak label -- Architecture: Keycloak (OIDC auth for pal-enterprises)
• [x] arch note verified -- arch-keycloak note exists in pal-e-docs
• [x] Forgejo issue -- ldraney/landscaping-assistant#348, open

File Targets

• [x] app/views/sessions/new.html.erb -- verified: exists (1.4k, last modified Jun 6). Shows only a "Sign in" button with plant icon, no mention of registration. Issue accurately describes the gap.
• [x] docs/keycloak-setup.md -- verified: exists (21k, last modified Jul 25). Line 85 still says registration is CSS-hidden (#kc-registration { display: none !important; }). This is outdated -- the CSS hide rule has been removed from login.css. Issue correctly identifies this needs updating.
• [x] keycloak-theme/landscaping/login/resources/css/login.css (DO NOT touch) -- verified: no display: none rule targeting #kc-registration. Line 284 styles #kc-registration with text-align, margin, font -- visible and functional.
• [x] config/initializers/omniauth.rb (DO NOT touch) -- verified: handles callback routing. Sessions controller uses CrewMember.find_or_create_by! (line 33) for both login and registration.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo change.

Dependencies

• Board item #1684 (done) -- issue #290 (original iPad Register button error). Predecessor, completed.
• Board item #1507 (done) -- pal-e-services#122 (Keycloak app-store-submission bug). Completed.
• Board item #1927 (validation) -- issue #324 (Keycloak account-email SMTP setup). In validation. Relevant because AC #4 requires email verification to work, but SMTP configuration is managed separately and should be functional by now.
• Board item #1940 (qa) -- issue #249 (Keycloak redirects to Tailscale URL instead of public domain). In QA. Could affect registration redirects if the same issue applies to the registration callback.
• No blocking dependencies for the core code changes (adding link + updating docs).

Acceptance Criteria

• AC 1-3: Directly testable via code inspection and integration tests. The sessions controller uses CrewMember.find_or_create_by! and redirects to root_path (which redirects logged-in users to work_queue_items_path).
• AC 4: Manual verification of SMTP. Depends on account-email story infrastructure (item #1927, in validation). Reasonable to verify here but not a code change.
• AC 5: Manual iOS testing. Reasonable verification step.
• AC 6: Doc accuracy check, directly verifiable.
• All criteria are assessable. AC 4-5 are manual validation steps, not code changes.

Blast Radius

• sessions/new.html.erb is the login page for all platforms (web, iOS via Turbo Native, Android). Adding a registration link affects all entry points.
• No other pal-enterprises apps share this login page -- change is scoped to landscaping-assistant.
• OmniAuth callback at sessions#create already handles first-time users via find_or_create_by!, so the registration callback path requires no controller changes.
• No sibling services have the same pattern to fix.

Decomposition Assessment

2 file targets across 1 repo. 6 AC but only 2 require code changes (AC 1-2 for the link, AC 6 for the doc). Estimated agent work well under 5 minutes. No decomposition needed.

Recommendation

No action needed.

Verdict: APPROVED

Re-review after refinement. Previous review (NEEDS_REFINEMENT) identified one issue: wrong file target for feature flag. That issue has been corrected.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Present
• [x] Repo -- Present (ldraney/landscaping-assistant)
• [x] User Story -- Present
• [x] Context -- Present
• [x] File Targets -- Present (3 modify, 1 do-not-touch)
• [x] Feature Flag -- Present ("none -- this ticket removes the public_landing flag")
• [x] Acceptance Criteria -- Present (5 criteria)
• [x] Test Expectations -- Present
• [x] Constraints -- Present
• [x] Checklist -- Present
• [x] Related -- Present

Traceability

• [x] story:app-store-submission label -- "Submit and maintain iOS App Store listing (privacy declarations, review compliance, metadata)"
• [x] story note verified -- found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label -- Rails App (Shared Pattern)
• [x] arch note verified -- arch-rails-app note exists in pal-e-docs (architecture note, status: active)
• [x] Forgejo issue -- ldraney/landscaping-assistant#349, open

File Targets

• [x] app/controllers/landing_controller.rb -- verified: line 10 has unless feature_enabled?(:public_landing) guard; lines 5-7 redirect logged-in users to work_queue_items_path (maps to /today). Ticket description matches code.
• [x] app/views/landing/index.html.erb -- verified: 117-line file with generic marketing copy (feature cards, role descriptions). No App Store link or badge present. Ticket correctly identifies what needs to change.
• [x] lib/tasks/feature_flags.rake -- verified: line 24 has { name: "public_landing", enabled: false, description: "Public landing page for unauthenticated users (#324)" }. CORRECTED from previous review (was app/models/feature_flag.rb). File target now accurate.
• [x] app/views/sessions/new.html.erb (do-not-touch) -- verified: exists, separate login page concern. Correct exclusion.

Repo Placement

OK -- issue filed on ldraney/landscaping-assistant, all file targets are within the landscaping-assistant app. Single repo, no cross-repo work needed.

Dependencies

No blocking dependencies. Board item #1983 (Clean registration flow for App Store resubmission, arch:keycloak) shares story:app-store-submission but is independent work. #1946 (deploy-validation) is in_progress but unrelated (arch:infra). Previously completed app-store-submission items (#1683, #1684, #1685, #1506, #1507) are all done.

Acceptance Criteria

5 ACs, all testable:

• AC1 (no feature flag check) -- verifiable via controller test and grep
• AC2 (App Store badge/link) -- verifiable by checking HTML content for https://apps.apple.com/app/id6780226794
• AC3 (logged-in redirect to /today) -- verifiable via controller test; current code already does this via work_queue_items_path
• AC4 (public_landing flag removed) -- verifiable via grep across codebase
• AC5 (clean and professional on desktop/mobile) -- subjective but reasonable for manual QA

Test command rails test is valid. Test expectations cover the controller logic adequately.

Blast Radius

Low. In the main repo, public_landing appears in 4 files: the 2 file targets plus spec/requests/landing_spec.rb and spec/requests/sessions_spec.rb (tests that will be updated per Test Expectations section). No sibling services, no downstream consumers. The FeatureFlag model is generic and shared by other flags -- removing the public_landing usage does not affect the model itself.

Decomposition Assessment

No decomposition needed. 3 file targets in 1 repo, 5 acceptance criteria, estimated agent work well under 5 minutes. Straightforward controller change + view redesign + rake task cleanup.

Recommendation

No action needed.

Verdict: NEEDS_REFINEMENT

Re-review of board item #1946 after refinements applied to address 5 issues from review-1946-2026-08-01. Four of five issues resolved. Decomposition threshold still exceeded.

Previous Findings Status

Template Completeness

• [x] Type -- Feature
• [x] Lineage
• [x] Repo -- now correctly lists all 4 repos with ldraney owner
• [x] User Story
• [x] Context
• [x] File Targets -- now includes caddy.sls and production.rb
• [x] Feature Flag
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

All 12 required sections for a Feature issue are present.

Traceability

• [x] story:deploy-validation label -- "Staging environment that auto-deploys every commit for deploy validation via observability before promoting to prod"
• [x] story note verified -- found in project-landscaping-assistant user-stories section (row 14 of 17)
• [x] arch:infra label -- Infrastructure: paldocs (Hetzner Edge, DNS, Traffic Routing)
• [x] arch note verified -- arch-infra note exists in pal-e-docs (architecture note, status: active)
• [x] Forgejo issue -- ldraney/landscaping-assistant#342, state: open

All three traceability legs present and verified.

File Targets

• [x] pal-e-services/terraform/k3s.tfvars -- verified: file exists (symlink to secrets). Contains landscaping-assistant service entry (line 337), service_databases (line 40), Keycloak realm/client (line 191). ISS staging reference pattern confirmed: iss-staging databases (line 34), staging service (line 400).
• [x] pal-e-platform/terraform/dns.tf -- verified: file exists. Contains godaddy_dns_record resources. Note: ticket says "add A record" but existing subdomain pattern (iss_dev, line 64) uses CNAME, not A record. Agent can determine correct record type from pattern. Minor inaccuracy, non-blocking.
• [x] pal-e-platform/salt/pillar/caddy.sls -- verified: file exists. Contains 7 site entries including landscaping (line 17-20) and iss-dev (line 37-40). No ISS staging entry exists (ISS staging is Tailscale-only). Landscaping staging will be a new public-access pattern.
• [x] pal-e-deployments/overlays/landscaping-assistant/staging/* -- correctly marked as new files. Parent directory exists with dev/ and prod/. ISS staging reference at overlays/intelligentstaffingsystems/staging/ confirmed with kustomization.yaml, deployment-patch.yaml, secrets.enc.yaml.
• [x] landscaping-assistant/config/environments/production.rb -- verified: file exists. config.hosts (lines 97-99) currently allows landscaping-assistant.app, landscaping-assistant.tail5b443a.ts.net, landscaping-dev.tail5b443a.ts.net. Ticket correctly notes that staging.landscaping-assistant.app must be added.

Repo Placement

Issue filed on ldraney/landscaping-assistant as a cross-repo tracking issue. Repo section now correctly lists all 4 repos with ldraney owner. Checklist has per-repo PR items. Acceptable pattern for cross-repo infrastructure work.

Dependencies

• #1945 (backlog): "Add dev.landscaping-assistant.app to Keycloak redirect URIs" -- similar Keycloak/DNS pattern, independent. Not blocking.
• #1940 (qa): "Keycloak login/reset redirects to Tailscale URL instead of public domain" -- could affect staging login. Staging uses separate Keycloak realm, so independent. Not blocking.
• #1460 (backlog): "Wire up landscaping-assistant.app custom domain" -- already done (item is in backlog but work appears complete given that landscaping-assistant.app is live). Not blocking.
• No blocking dependencies found. Dependencies are not documented in the issue scope but none are blocking.

Acceptance Criteria

8 criteria, all agent-testable:

• AC 1 (staging URL loads): testable via curl after deploy
• AC 2 (auto-deploy): testable by checking Image Updater annotation in kustomization.yaml
• AC 3-5 (observability): testable by checking ServiceMonitor, PrometheusRules, blackbox probe manifests
• AC 6 (prod manual): testable by verifying no Image Updater annotation on prod overlay
• AC 7-8 (separate DB, separate realm): testable by checking Terraform plan output

Test expectations include concrete commands (tofu plan, kubectl kustomize, curl /up, curl /). Test for curl / returning 200 (not 403) correctly validates the config.hosts fix. Adequate.

Blast Radius

All changes are additive -- new entries in Terraform maps, new overlay directory, new DNS record, new Caddy site entry, one new config.hosts entry. Prod overlay explicitly excluded in "Files NOT to touch" section. Low blast radius.

Note: ISS staging has no public DNS or Caddy entry (Tailscale-only). Landscaping-assistant staging will be the first staging environment with public access via the edge proxy. This is a minor architectural divergence from the ISS staging reference pattern, but the ticket correctly accounts for it by including dns.tf and caddy.sls targets.

Decomposition Assessment

NEEDS DECOMPOSITION -- thresholds still exceeded:

• File targets: 7+ files across 4 repos (threshold: >3 files across >2 repos)
• Acceptance criteria: 8 (threshold: >5)
• Estimated agent work: >5 minutes (Terraform changes across 2 repos, SOPS encryption, kustomize overlay, DNS record, Caddy pillar, Keycloak realm, Rails config.hosts, 4 separate PRs)
• Natural decomposition boundary: one sub-issue per repo/PR

[DECOMPOSE] Route to skill-decompose-ticket. Same decomposition as previous review:

1. pal-e-services: Add staging service, databases, Keycloak realm/client to k3s.tfvars
2. pal-e-platform: Add DNS record (dns.tf) + Caddy site entry (caddy.sls)
3. pal-e-deployments: Create staging overlay (kustomization.yaml, deployment-patch.yaml, secrets.enc.yaml)
4. landscaping-assistant: Add staging.landscaping-assistant.app to Rails config.hosts

Recommendation

• [DECOMPOSE] 8 AC across 4 repos with 4 separate PRs required. Route to skill-decompose-ticket for automated sub-ticket creation. Suggested split: one sub-issue per repo (4 sub-issues). The parent issue (#342) becomes the umbrella/tracking issue.

All 4 previous [BODY] and [SCOPE] issues have been resolved. Only the decomposition requirement remains.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [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 12 required sections for a Feature issue are present.

Traceability

• [x] arch:infra label -- arch-infra note exists (Infrastructure: paldocs (Hetzner Edge, DNS, Traffic Routing)). Covers DNS, Caddy, Tailscale funnel patterns.
• [x] arch note verified -- arch-infra note exists in pal-e-docs
• [ ] story:deploy-validation label -- NOT found in project-landscaping-assistant user-stories table. 16 stories listed; none match "deploy-validation". [SCOPE] Create user story entry on project-landscaping-assistant user-stories section.
• [x] Forgejo issue -- ldraney/landscaping-assistant#342, state: open

File Targets

• [x] pal-e-services/terraform/k3s.tfvars -- verified: file exists (symlink to secrets). Contains services map (line 327) with landscaping-assistant entry, service_databases map (line 17) with landscaping entry including 4 databases, Keycloak realm/client config (lines 98, 191). ISS staging reference pattern confirmed at lines 34 (databases), 400 (service).
• [x] pal-e-platform/terraform/dns.tf -- verified: file exists. Contains godaddy_dns_record resources for existing domains. ISS dev uses CNAME (line 64), not A record as ticket states, but functionally equivalent for subdomains. Agent can determine correct record type from pattern.
• [x] pal-e-deployments/overlays/landscaping-assistant/staging/* -- correctly marked as new files. Parent directory exists with dev/ and prod/. ISS staging reference at overlays/intelligentstaffingsystems/staging/ confirmed with kustomization.yaml, deployment-patch.yaml, secrets.enc.yaml.
• [ ] pal-e-platform/salt/pillar/caddy.sls -- MISSING from scope. Caddy reverse proxy is managed via Salt pillar data. Each public domain needs a site entry (domain, proxy_target, www_redirect). Without adding staging.landscaping-assistant.app, Caddy on the edge VPS will not proxy traffic to the staging Tailscale funnel. ISS dev reference: iss-dev entry exists at line 37. [BODY] Add file target for Caddy pillar.
• [ ] landscaping-assistant/config/environments/production.rb -- MISSING from scope. Rails config.hosts (lines 97-99) only allows landscaping-assistant.app, landscaping-assistant.tail5b443a.ts.net, landscaping-dev.tail5b443a.ts.net. The /up health check is excluded from host authorization (line 102-104), so AC "curl /up returns 200" would pass, but all other routes would return 403 without adding staging.landscaping-assistant.app. [BODY] Add file target for Rails config.hosts.

Repo Placement

Issue filed on ldraney/landscaping-assistant as a project-level tracking issue. Actual work spans 3-4 repos. Acceptable pattern for cross-repo infrastructure work.

Issue: Repo section lists forgejo_admin/pal-e-platform but git remote shows ldraney/pal-e-platform. Board items #1463 and #1942 also reference ldraney/pal-e-platform. [BODY] Fix owner to ldraney/pal-e-platform.

Dependencies

• Item #1945 (backlog): "Add dev.landscaping-assistant.app to Keycloak redirect URIs" -- similar Keycloak/DNS pattern but independent. Not blocking.
• Item #1940 (qa): "Keycloak login/reset redirects to Tailscale URL instead of public domain" -- could affect staging login, but staging uses a separate Keycloak realm. Not blocking.
• No critical blocking dependencies found. Dependencies are not documented in the issue scope but none are blocking.

Acceptance Criteria

8 criteria, all agent-testable:

• AC 1 (staging URL loads): testable via curl after deploy
• AC 2 (auto-deploy): testable by checking Image Updater annotation in kustomization.yaml
• AC 3-5 (observability): testable by checking ServiceMonitor, PrometheusRules, blackbox probe manifests. ISS staging overlay includes ServiceMonitor rename patch as reference.
• AC 6 (prod manual): testable by verifying no Image Updater annotation on prod overlay
• AC 7-8 (separate DB, separate realm): testable by checking Terraform plan output and Keycloak admin

Test expectations include concrete commands (tofu plan, kubectl kustomize, curl /up). Adequate.

Note: AC 1 ("loads and serves the app") will fail if config.hosts gap is not addressed -- Rails will return 403 for all routes except /up.

Blast Radius

All changes are additive -- new entries in Terraform maps, new overlay directory, new DNS record, new Caddy site entry. Prod overlay explicitly excluded in "Files NOT to touch" section. Low blast radius.

ISS staging is a proven reference pattern already in production.

Decomposition Assessment

NEEDS DECOMPOSITION

• File targets: 6+ files across 4 repos (pal-e-services, pal-e-platform, pal-e-deployments, landscaping-assistant) -- exceeds 3 files / 2 repos threshold
• Acceptance criteria: 8 -- exceeds 5 threshold
• Estimated agent work: >5 minutes (Terraform changes across 2 repos, SOPS encryption, kustomize overlay, DNS record, Caddy pillar, Keycloak realm, Rails config.hosts, 3+ separate PRs)
• Natural decomposition boundary: one sub-issue per repo/PR

[DECOMPOSE] Route to skill-decompose-ticket. Suggested sub-issues:

1. pal-e-services: Add staging service, databases, Keycloak realm/client to k3s.tfvars
2. pal-e-platform: Add DNS record (dns.tf) + Caddy site entry (salt/pillar/caddy.sls)
3. pal-e-deployments: Create staging overlay (kustomization.yaml, deployment-patch.yaml, secrets.enc.yaml)
4. landscaping-assistant: Add staging.landscaping-assistant.app to Rails config.hosts

Recommendation

• [SCOPE] Create user story entry "deploy-validation" on project-landscaping-assistant user-stories section.
• [BODY] Add missing file target: pal-e-platform/salt/pillar/caddy.sls -- add staging site entry (domain: staging.landscaping-assistant.app, proxy_target: landscaping-assistant-staging.tail5b443a.ts.net). Without this, Caddy will not proxy the staging domain.
• [BODY] Add missing file target: landscaping-assistant/config/environments/production.rb -- add config.hosts << "staging.landscaping-assistant.app". Without this, Rails returns 403 for all non-/up routes.
• [BODY] Fix Repo section: forgejo_admin/pal-e-platform should be ldraney/pal-e-platform (confirmed via git remote and board item history).
• [DECOMPOSE] 8 AC across 4 repos with 3+ PRs required. Route to skill-decompose-ticket for automated sub-ticket creation.

Verdict: NEEDS_REFINEMENT

Template Completeness

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

Traceability

• [x] story:dev-url label — present on board item
• [ ] story note MISSING — [SCOPE] Create user story entry "dev-url" on project-landscaping-assistant user-stories section. Suggested summary: "Access dev environment via dev.landscaping-assistant.app with DNS, Caddy proxy, and Keycloak configuration"
• [x] arch:edge-proxy label — Edge Proxy (Hetzner VPS)
• [x] arch note verified — arch-edge-proxy note exists in pal-e-docs (active, architecture type)
• [x] Forgejo issue — ldraney/landscaping-assistant#340, open

File Targets

• [x] salt/pillar/caddy.sls — verified: file exists in pal-e-platform. ISS dev entry pattern confirmed at lines 37-40 (domain: dev.intelligentstaffingsystems.ai, proxy_target: iss-dev.tail5b443a.ts.net, www_redirect: false). Adding a landscaping-dev entry following this pattern is straightforward.

Repo Placement

MISMATCH: Issue body declares ### Repo: ldraney/pal-e-platform but the Forgejo issue is filed under ldraney/landscaping-assistant (#340). The code change targets pal-e-platform/salt/pillar/caddy.sls. The previous Caddy proxy work for the custom-domain story was filed directly in pal-e-platform as pal-e-platform#434. Consider filing the implementation issue in the target repo for consistency, or document the cross-repo filing rationale.

Dependencies

• Blocker: Item #1943 (landscaping-assistant#339 — "Add DNS CNAME for dev.landscaping-assistant.app") must complete first. Both are in backlog. The Lineage section correctly documents this: "Depends on DNS CNAME being in place."
• Sibling: Item #1945 (landscaping-assistant#341 — arch:keycloak, story:dev-url) is a downstream sibling in the same story that likely handles Keycloak redirect URI updates for the dev domain.
• Dependencies are documented in the issue body (Lineage section).

Acceptance Criteria

1 AC — clear and testable: "HTTPS requests to dev.landscaping-assistant.app are proxied to landscaping-dev.tail5b443a.ts.net". Test command is real (curl -I). Note: test depends on DNS CNAME (issue #339) being in place first AND the dev environment running on the Tailscale funnel. The salt apply deployment command is documented.

Blast Radius

Low. Only ISS currently has a dev.* Caddy entry. Adding a new pillar entry is additive and does not affect existing sites. Other apps (WKQ, prediction-assistant, paldocs) do not have dev entries — future work if needed. No downstream consumers are affected.

Decomposition Assessment

1 file target in 1 repo, 1 acceptance criterion. Estimated agent work well under 5 minutes. No decomposition needed.

Recommendation

• [SCOPE] Create user story entry "dev-url" on project-landscaping-assistant user-stories section. The story spans 3 issues (#339 DNS, #340 Caddy, #341 Keycloak) and needs a summary entry for traceability.
• [BODY] Repo placement: Consider moving the Forgejo issue to pal-e-platform to match the target repo and the precedent set by pal-e-platform#434 (the production Caddy entry). Alternatively, document the cross-repo filing approach if this is intentional for project-board tracking.

Verdict: READY

Template Completeness

• [x] Type — Bug
• [x] Lineage — Blocker for landscaping-assistant#324
• [x] Repo — ldraney/pal-e-platform
• [x] What Broke — detailed CSS rule description
• [x] Repro Steps — 3 steps
• [x] Expected Behavior — registration link visible
• [x] Environment — cluster, theme source, ConfigMap, version
• [x] File Targets — extra section (not in bug template), acceptable
• [x] Acceptance Criteria — 3 criteria
• [x] Related — #324 and validation note

Traceability

• [x] story:account-email label — Account Email Delivery
• [x] story note verified — story-landscaping-assistant-account-email exists in pal-e-docs, listed in project-landscaping-assistant user-stories section
• [x] arch:keycloak label — Keycloak architecture
• [x] arch note verified — arch-keycloak note exists in pal-e-docs
• [x] Forgejo issue — ldraney/pal-e-platform#566, open

File Targets

• [x] keycloak/themes/landscaping/login/resources/css/login.css (pal-e-platform) — verified: #kc-registration { display: none !important; } exists at lines 340-341 exactly as described. Comment block (lines 331-339) confirms this was intentional for App Store v1.0 and says "Re-enable by removing this block when client self-registration is ready for production."

Repo Placement

OK. Issue filed on ldraney/pal-e-platform, which is correct — the CSS is deployed via ConfigMap keycloak-landscaping-theme from terraform modules/keycloak/main.tf.

Note: A development copy exists in ldraney/landscaping-assistant at keycloak-theme/landscaping/login/resources/css/login.css (lines 405-407). The landscaping-assistant repo has uncommitted changes that ADD the same display:none block. The agent implementing this fix should also ensure the landscaping-assistant copy does not retain the block, but pal-e-platform is the deployment source of truth.

Dependencies

• Blocks: Board item #1927 (landscaping-assistant#324 — "landing page + public registration") is in the validation column. Validation found AC4 FAIL due to this CSS rule.
• Blocked by: Nothing
• Dependencies documented in issue Lineage section: yes

Acceptance Criteria

3 AC, all clear and agent-verifiable via browser tools:

• AC1: element visibility — check via DOM inspection or screenshot
• AC2: link clickable and navigates — check via browser click
• AC3: login flow unaffected — verify existing login still works

No missing criteria. For a CSS-only change, browser verification is the appropriate test method.

Blast Radius

• Other Keycloak themes (paldocs, iss, prediction-assistant) reference #kc-registration for styling but none have display: none — no cross-theme blast radius.
• The landscaping-assistant repo has uncommitted changes adding the same display:none block — coordinate to ensure those changes do not include the block.

Decomposition Assessment

1 file target in 1 repo. 3 acceptance criteria. Estimated agent work: under 2 minutes (remove CSS block + comment). No decomposition needed.

Recommendation

No action needed. Scope is solid, all traceability verified, file targets confirmed, fits in a single agent pass.

Verdict: APPROVED

Board item #1938 — Hours tab: clock in/out/break UI (Forgejo issue #333, 5 points, sprint:7)

Re-review v3 after refinement. Previous reviews: review-1938-2026-07-27 (v1), review-1938-2026-07-27-v2 (v2). The sole remaining issue from v2 — missing user story entry on project page — has been fixed. All 5 original issues are now resolved.

Previous Issues — All Resolved

• [x] arch:rails label — Resolved in v2. convention-architecture-ids lists arch:rails as a general category label "Rails application (models, controllers, views)" under Application section. Not project-specific. Acceptable.
• [x] hours_controller.rb annotation — Resolved in v2. Issue body now reads app/controllers/hours_controller.rb (created by #332).
• [x] Stimulus timer test expectation — Resolved in v2. Test expectations note server-derived correctness: timer calculates elapsed from started_at minus break durations. JS is pure display.
• [x] Decomposition rejection — Resolved in v2. Context section justifies keeping 10 AC as one ticket: all items on single page, tightly coupled. Splitting nav/page-shell from timer-widget would deliver an empty page.
• [x] User story on project page — NOW RESOLVED. project-landscaping-assistant user-stories section has 16 entries. "crew-time-tracking" is row 16 with Key=crew-time-tracking, Role=Crew Member/Crew Lead, Summary=Clock in/out, track breaks, view daily/weekly hours from Hours tab. Success Metric includes parent #331 reference.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Related to #331 (parent), depends on #332 (model ticket)
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — As a crew member or lead, clock in/out/break
• [x] Context — Present, includes decomposition justification
• [x] File Targets — 2 create, 5 modify, exclusions listed
• [x] Feature Flag — time_tracking (registered by #332)
• [x] Acceptance Criteria — 10 items
• [x] Test Expectations — 6 items + run command
• [x] Constraints — 4 items
• [x] Checklist — standard
• [x] Related — project + parent + story

All template sections present and complete.

Traceability

• [x] story:crew-time-tracking label — present on board item
• [x] story note verified — found as row 16 of 16 in project-landscaping-assistant user-stories section
• [x] arch:rails label — present on board item. Verified against convention-architecture-ids: general category label "Rails application (models, controllers, views)" under Application section.
• [x] arch note verified — arch-rails note exists in pal-e-docs. General category label per convention, not project-specific.
• [x] Forgejo issue — #333, open

File Targets

• [x] app/views/hours/index.html.erb — TO CREATE. Directory does not exist; expected for greenfield.
• [x] app/javascript/controllers/timer_controller.js — TO CREATE. Controllers directory exists with Stimulus controllers. Uses eagerLoadControllersFrom.
• [x] app/views/layouts/application.html.erb — verified exists. Nav uses 5-slot grid. Slot 2 reuse for Hours (member/lead) is sound.
• [x] app/controllers/application_controller.rb — verified exists. TAB_ROLES present, adding :hours is straightforward.
• [x] app/controllers/hours_controller.rb (created by #332) — correctly annotated as dependency.
• [x] app/assets/stylesheets/application.css — verified exists.
• [x] config/routes.rb — verified exists. Ticket correctly notes routes may be added by #332.

Repo Placement

Correct. All work in ldraney/landscaping-assistant. Forgejo issue filed on same repo. No cross-repo scope.

Dependencies

• #1937 / issue #332 (TimeEntry data model + API + flag) — backlog, sprint:6. Hard dependency. Creates controller, models, routes, feature flag. Sprint ordering (6 before 7) is correct. Documented in Lineage section.
• #1936 / issue #331 (Time Tracking: Hours Tab) — backlog, parent umbrella. No blocking dependency.
• #1939 / issue #334 (Hours tab: daily/weekly summary) — backlog, sprint:7. Sibling ticket, independent, can run in parallel.
• Only in_progress item is #1940 (Keycloak redirect bug) — unrelated, does not block.

Acceptance Criteria

10 acceptance criteria. All have reasonable test coverage strategy. AC 1-3, 7-10 covered by request specs. AC 4-6 (client-side timer) addressed by server-derived correctness approach. All criteria are agent-verifiable.

Blast Radius

No existing time tracking code in codebase. Clean greenfield addition. Nav slot 2 reuse is architecturally sound — admin (Week) and member/lead (Hours) roles are mutually exclusive. No downstream consumers affected.

Decomposition Assessment

Decomposition waived. Justification accepted in v2: all 10 AC describe states of one cohesive widget on one page. Splitting would create artificial boundaries. AC are tightly coupled (cannot test break without clock-in, cannot test clock-out without timer).

Recommendation

No action needed. All issues from v1 and v2 have been resolved. Ticket is ready for implementation.

Verdict: APPROVED

Re-review v3 of board item #1939 after refinement. Previous reviews: review-1939-2026-07-27 (v1), review-1939-2026-07-27-r2 (v2). All three issues from v1 are now resolved.

Previous Review Issues -- Status

• [x] Lineage updated -- FIXED (v2). Lineage now lists both #332 (TimeEntry data model + API, sprint:6) and #333 (Hours tab UI, sprint:7) as explicit dependencies.
• [x] File targets annotated -- FIXED (v2). All upstream-created files annotated with "(created by #332)" or "(created by #333)".
• [x] User story on project page -- FIXED (v3). crew-time-tracking entry now present as row 16 of 16 in project-landscaping-assistant user-stories section. Key=crew-time-tracking, Role=Crew Member/Crew Lead, Summary="Clock in/out, track breaks, view daily/weekly hours from Hours tab", Success Metric includes story note reference and parent #331.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- present, references parent #331 and dependencies #332, #333
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- present, well-formed (crew member/lead perspective)
• [x] Context -- present, references BusyBusy UX pattern
• [x] File Targets -- present with create/modify/do-not-touch sections, upstream annotations
• [x] Feature Flag -- present (time_tracking, registered by #332)
• [x] Acceptance Criteria -- 6 criteria present
• [x] Test Expectations -- present with run command
• [x] Constraints -- present (Mon-Sun, duration format, no pagination)
• [x] Checklist -- present
• [x] Related -- present

Traceability

• [x] story:crew-time-tracking label -- present on board item
• [x] story note verified -- crew-time-tracking entry found in project-landscaping-assistant user-stories section (row 16 of 16)
• [x] arch:rails label -- present
• [x] arch note verified -- arch-rails note exists in pal-e-docs
• [x] Forgejo issue -- #334, open

File Targets

• [x] app/views/hours/_daily_entries.html.erb -- to create (new file, OK)
• [x] app/views/hours/_weekly_summary.html.erb -- to create (new file, OK)
• [x] app/views/hours/index.html.erb (created by #333) -- correctly annotated; does not exist yet (expected, upstream not yet merged)
• [x] app/controllers/hours_controller.rb (created by #332) -- correctly annotated; does not exist yet (expected)
• [x] app/models/time_entry.rb (created by #332) -- correctly annotated; does not exist yet (expected)
• [x] app/assets/stylesheets/application.css -- verified, exists
• [x] Referenced pattern work_queue_items/_queue_item.html.erb -- verified, exists in codebase

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets within the same repo. No cross-repo concerns.

Dependencies

• #332 "TimeEntry data model + API + flag" (sprint:6, backlog) -- creates TimeEntry model, hours_controller.rb, time_tracking feature flag. Explicitly listed in Lineage and file annotations.
• #333 "Hours tab: clock in/out/break UI" (sprint:7, backlog) -- creates hours/index.html.erb, adds nav tab, timer widget. Explicitly listed in Lineage and file annotations.
• #331 "Time Tracking: Hours Tab (parent)" (backlog) -- umbrella/parent issue. Listed in Lineage.
• Execution order: #332 (sprint:6) then #333 and #334 (sprint:7). Sprint ordering is correct.

Acceptance Criteria

6 criteria, all concrete and agent-verifiable. Test commands are real (bundle exec rspec). Test expectations cover request and model specs with specific file paths.

Blast Radius

Low. Net-new feature adding views and scopes to a new model/controller pair. Only modifies application.css (additive styles). No downstream consumers affected.

Decomposition Assessment

6 file targets across 1 repo. 6 acceptance criteria (borderline on the >5 AC rule). Work is highly cohesive: all changes serve a single UI feature (daily/weekly summary views). Estimated agent time: ~4-5 minutes. No decomposition needed.

Recommendation

No action needed. All issues from v1 and v2 have been resolved. Ticket is ready for implementation.

Verdict: NEEDS_REFINEMENT

Re-review of board item #1939 after refinement. Previous review: review-1939-2026-07-27. 2 of 3 issues resolved; 1 remains.

Previous Review Issues -- Status

• [x] Lineage updated -- FIXED. Lineage now reads: "Depends on #332 (TimeEntry data model + API, sprint:6) and #333 (Hours tab UI, sprint:7)." Both upstream tickets explicitly listed.
• [x] Files annotated with "(created by #NNN)" -- FIXED. All three upstream-created files now annotated:
  • hours/index.html.erb (created by #333) -- correct
  • hours_controller.rb (created by #332) -- correct (verified: #332 creates the controller with clock_in/clock_out/break actions)
  • time_entry.rb (created by #332) -- correct
• [ ] User story on project page -- NOT FIXED. crew-time-tracking entry is still absent from the project-landscaping-assistant user-stories section. The section contains 15 story rows; none is crew-time-tracking.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- present, references parent #331 and dependencies #332, #333
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- present, well-formed (crew member/lead perspective)
• [x] Context -- present, references BusyBusy UX pattern
• [x] File Targets -- present with create/modify/do-not-touch sections, upstream annotations
• [x] Feature Flag -- present (time_tracking, registered by #332)
• [x] Acceptance Criteria -- 6 criteria present
• [x] Test Expectations -- present with run command
• [x] Constraints -- present (Mon-Sun, duration format, no pagination)
• [x] Checklist -- present
• [x] Related -- present

Traceability

• [x] story:crew-time-tracking label -- present on board item
• [ ] story note MISSING -- [SCOPE] No crew-time-tracking entry in project-landscaping-assistant user-stories section. This was flagged in the first review and remains unresolved.
• [x] arch:rails label -- present
• [x] arch note verified -- arch-rails note exists in pal-e-docs (associated with Prediction Assistant project, not landscaping-assistant, but architecture note exists)
• [x] Forgejo issue -- #334, open

File Targets

• [x] app/views/hours/_daily_entries.html.erb -- to create (new file, OK)
• [x] app/views/hours/_weekly_summary.html.erb -- to create (new file, OK)
• [x] app/views/hours/index.html.erb (created by #333) -- correctly annotated; does not exist yet (expected, #333 is in backlog)
• [x] app/controllers/hours_controller.rb (created by #332) -- correctly annotated; verified #332 creates this controller. Does not exist yet (expected, #332 is in backlog)
• [x] app/models/time_entry.rb (created by #332) -- correctly annotated; does not exist yet (expected, #332 is in backlog)
• [x] app/assets/stylesheets/application.css -- verified, exists
• [x] Referenced pattern work_queue_items/_queue_item.html.erb -- verified, exists in codebase

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets within the same repo. No cross-repo concerns.

Dependencies

• #332 "TimeEntry data model + API + flag" (sprint:6, backlog) -- creates TimeEntry model, hours_controller.rb, time_tracking feature flag. Explicitly listed in Lineage. Correctly referenced in file annotations.
• #333 "Hours tab: clock in/out/break UI" (sprint:7, backlog) -- creates hours/index.html.erb, adds nav tab, timer widget. Explicitly listed in Lineage. Correctly referenced in file annotations.
• #331 "Time Tracking: Hours Tab (parent)" (backlog) -- umbrella/parent issue. Listed in Lineage.
• Execution order: #332 (sprint:6) -> #333 and #334 (sprint:7). Sprint ordering is correct.
• All dependencies documented in the issue body.

Acceptance Criteria

6 criteria, all concrete and agent-verifiable:

• AC 1-4: view-level checks -- verifiable via request specs checking response body
• AC 5: break subtraction logic -- verifiable via model spec
• AC 6: Turbo Stream update after clock out -- verifiable; Turbo Stream patterns exist in codebase

Test commands are real (bundle exec rspec). Test expectations cover request and model specs with specific file paths.

Blast Radius

Low. Net-new feature adding views and scopes to a new model/controller pair. No existing TimeEntry, for_date, for_week, or total_duration patterns in the codebase. Only modifies application.css (additive styles). No downstream consumers affected.

Decomposition Assessment

6 file targets across 1 repo. 6 acceptance criteria (borderline on the >5 AC rule). Work is highly cohesive: all changes serve a single UI feature (daily/weekly summary views). Estimated agent time: ~4-5 minutes. No decomposition needed.

Recommendation

• [SCOPE] Create user story entry crew-time-tracking on project-landscaping-assistant user-stories section. This is the sole remaining issue from the first review. Suggested row: Key=crew-time-tracking, Role=Crew member/lead, Summary="Clock in/out, view daily and weekly hour totals", Success Metric="Timer widget, daily entries list, weekly summary with break deductions"

Verdict: NEEDS_REFINEMENT

Board item #1938 — Hours tab: clock in/out/break UI (Forgejo issue #333, 5 points, sprint:7)

Re-review after refinement. Previous review: review-1938-2026-07-27. Of the 5 issues flagged, 4 were addressed correctly. One remains.

Previous Issues — Status

• [x] arch:rails label — Verified. convention-architecture-ids lists arch:rails under Application as "Rails application (models, controllers, views)". General category label, not project-specific. Acceptable.
• [x] hours_controller.rb annotation — Landed. Issue body now reads app/controllers/hours_controller.rb (created by #332).
• [x] Stimulus timer test expectation — Landed. Test expectations note server-derived correctness: timer calculates elapsed from started_at minus break durations. JS is pure display.
• [x] Decomposition rejection — Landed. Context section justifies keeping 10 AC as one ticket: all items on single page, tightly coupled. Splitting nav/page-shell from timer-widget would deliver an empty page.
• [ ] User story on project page — NOT LANDED. project-landscaping-assistant user-stories section has 15 entries; "crew-time-tracking" is not among them.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Related to #331 (parent), depends on #332 (model ticket)
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — As a crew member or lead, clock in/out/break
• [x] Context — Present, includes decomposition justification
• [x] File Targets — 2 create, 5 modify, exclusions listed
• [x] Feature Flag — time_tracking (registered by #332)
• [x] Acceptance Criteria — 10 items
• [x] Test Expectations — 6 items + run command
• [x] Constraints — 4 items
• [x] Checklist — standard
• [x] Related — project + parent + story

All template sections present and complete.

Traceability

• [x] story:crew-time-tracking label — present on board item
• [ ] story note MISSING — [SCOPE] No "crew-time-tracking" entry in project-landscaping-assistant user-stories section. Must be added before work begins.
• [x] arch:rails label — present on board item. Verified against convention-architecture-ids: general category label "Rails application (models, controllers, views)" under Application section. Not project-specific.
• [x] arch note verified — arch-rails note exists in pal-e-docs. Describes Rails architecture generally; label is a cross-project category per convention.
• [x] Forgejo issue — #333, open, valid URL

File Targets

• [x] app/views/hours/index.html.erb — TO CREATE. Directory does not exist; expected for greenfield.
• [x] app/javascript/controllers/timer_controller.js — TO CREATE. Controllers directory exists with 19 Stimulus controllers. Uses eagerLoadControllersFrom so no index.js changes needed.
• [x] app/views/layouts/application.html.erb — verified exists. Nav uses 5-slot grid (nav-slot-1 through nav-slot-5). Slot 2 is currently Week (admin-only). Hours would reuse slot 2 for member/lead since Week and Hours are mutually exclusive by role.
• [x] app/controllers/application_controller.rb — verified exists. TAB_ROLES at line 132 has: today, week, profile, properties, crew. Adding :hours for member/lead is straightforward.
• [x] app/controllers/hours_controller.rb (created by #332) — correctly annotated as created by dependency #332. File does not exist yet, as expected.
• [x] app/assets/stylesheets/application.css — verified exists.
• [x] config/routes.rb — verified exists. No hours routes present; ticket correctly notes "may already be added by #332."

Repo Placement

Correct. All work is in ldraney/landscaping-assistant. Forgejo issue filed on the same repo. No cross-repo scope.

Dependencies

• #332 (TimeEntry data model + API + flag) — sprint:6, backlog. Hard dependency. Creates the controller, models, routes, and feature flag that #333 consumes. Sprint ordering (6 before 7) is correct. Dependency documented in Lineage section.
• #331 (Time Tracking: Hours Tab) — parent umbrella, backlog. No blocking dependency.
• #334 (Hours tab: daily/weekly summary) — sprint:7, backlog. Sibling ticket. Independent — can run in parallel with #333.
• No items in in_progress or needs_approval block this ticket. #1940 (Keycloak redirect bug) is in_progress but unrelated.

Acceptance Criteria

10 acceptance criteria. Testability assessment:

• AC 1-2 (tab visibility by role): Testable via request specs. Covered by test expectations.
• AC 3 (Clock In creates entry): Testable via request spec. Covered.
• AC 4-6 (Timer display, break pause/resume): Client-side JS only. Addressed by test expectation: timer correctness is server-derived (elapsed calculated from started_at minus break durations). JS is pure display. Request spec for clock-in verifies timer data in response.
• AC 7 (Clock Out stops timer): Mix of server + client. Server side covered.
• AC 8 (Today's log shows entries): Testable via request spec content check.
• AC 9 (Timer survives page refresh): Server-derived reconstruction verified by clock-in response test.
• AC 10 (Tab hidden when flag disabled): Covered by test expectations.

All criteria have reasonable test coverage strategy.

Blast Radius

No existing time tracking code in the codebase (grep confirmed: no matches for time_tracking, time_entry, TimeEntry, clock_in, clock_out). Clean greenfield addition. Nav slot 2 reuse (Week for admin, Hours for member/lead) is architecturally sound — roles are mutually exclusive. No downstream consumers affected.

Decomposition Assessment

• File targets: 7 (2 create + 5 modify), all in 1 repo — OK
• Acceptance criteria: 10 (threshold: >5) — EXCEEDS
• Estimated agent work: Borderline 5 minutes.

Decomposition waived. Justification in issue body is sound: all 10 AC describe states of one cohesive widget on one page. Splitting nav/page-shell from timer-widget would deliver an empty page as the first ticket — artificial boundary. The AC are tightly coupled (cannot test break without clock-in, cannot test clock-out without timer). Accepted.

Recommendation

• [SCOPE] Create user story entry "crew-time-tracking" on project-landscaping-assistant user-stories section. This was flagged in v1 review and claimed as addressed, but the entry is still missing. Row should include: Key=crew-time-tracking, Role=Crew member/Lead, Summary=Clock in/out and track breaks from Hours tab, Success Metric=Timer runs with server-derived accuracy, entries logged with worked time.

Verdict: NEEDS_REFINEMENT

Board item #1938 — Hours tab: clock in/out/break UI (Forgejo issue #333, 5 points, sprint:7)

Template Completeness

• [x] Type — Feature
• [x] Lineage — Related to #331 (parent), depends on #332 (model ticket)
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — As a crew member or lead, clock in/out/break
• [x] Context — BusyBusy interaction model described
• [x] File Targets — 2 create, 5 modify, exclusions listed
• [x] Feature Flag — time_tracking (registered by model ticket)
• [x] Acceptance Criteria — 10 items
• [x] Test Expectations — 5 items + run command
• [x] Constraints — 4 items
• [x] Checklist — standard
• [x] Related — project + parent

All template sections present and complete.

Traceability

• [x] story:crew-time-tracking label — present on board item
• [ ] story note MISSING — [SCOPE] No "crew-time-tracking" entry in project-landscaping-assistant user-stories section. Must be added before work begins.
• [x] arch:rails label — present on board item
• [ ] arch note MISMATCH — [SCOPE] arch-rails note exists but describes ISS Rails Architecture (project: prediction-assistant). It does not document landscaping-assistant’s Rails architecture. Either update arch-rails to be multi-project or create a project-specific note.
• [x] Forgejo issue — #333, open, valid URL

File Targets

• [x] app/views/hours/index.html.erb — TO CREATE. Directory does not exist; expected for greenfield.
• [x] app/javascript/controllers/timer_controller.js — TO CREATE. Controllers directory exists with 19 Stimulus controllers. Uses eagerLoadControllersFrom so no index.js changes needed.
• [x] app/views/layouts/application.html.erb — verified exists. Nav uses 5-slot grid (nav-slot-1 through nav-slot-5). Slot 2 is currently Week (admin-only). Hours would reuse slot 2 for member/lead since Week and Hours are mutually exclusive by role.
• [x] app/controllers/application_controller.rb — verified exists. TAB_ROLES at line 132 has: today, week, profile, properties, crew. Adding :hours for member/lead is straightforward.
• [ ] app/controllers/hours_controller.rb — ISSUE: [BODY] Listed as "Files to modify" but does NOT exist. Model ticket #332 will CREATE this file. Should be listed under a "Files to modify (created by #332)" sub-heading or include a parenthetical note.
• [x] app/assets/stylesheets/application.css — verified exists (59KB).
• [x] config/routes.rb — verified exists. No hours routes present; ticket correctly notes "may already be added by model ticket."

Repo Placement

Correct. All work is in ldraney/landscaping-assistant. Forgejo issue filed on the same repo. No cross-repo scope.

Dependencies

• #332 (TimeEntry data model + API + flag) — sprint:6, backlog. Hard dependency. Creates the controller, models, routes, and feature flag that #333 consumes. Sprint ordering (6 before 7) is correct. Dependency is documented in Lineage section.
• #331 (Time Tracking: Hours Tab) — parent umbrella, backlog. No blocking dependency.
• #334 (Hours tab: daily/weekly summary) — sprint:7, backlog. Sibling ticket. Independent — can run in parallel with #333 since it adds separate views to the same tab.
• No items in in_progress or needs_approval block this ticket. #1940 (Keycloak redirect bug) is in_progress but unrelated.

Acceptance Criteria

10 acceptance criteria. Testability assessment:

• AC 1-2 (tab visibility by role): Testable via request specs. Covered by test expectations.
• AC 3 (Clock In creates entry): Testable via request spec. Covered.
• AC 4 (Timer displays HH:MM:SS, updates every second): Client-side JS only. Not covered by any test expectation. [BODY] Add Stimulus controller test or note that this is manually verified.
• AC 5 (Take Break pauses timer): Client-side JS only. Not covered by test expectations.
• AC 6 (End Break resumes timer): Client-side JS only. Not covered by test expectations.
• AC 7 (Clock Out stops timer): Mix of server + client. Server side covered.
• AC 8 (Today's log shows entries): Testable via request spec content check. Not explicitly covered but implied.
• AC 9 (Timer survives page refresh): Testable by verifying server response contains reconstruct data. Not explicitly covered.
• AC 10 (Tab hidden when flag disabled): Covered by test expectations.

Gap: AC 4-6 are pure Stimulus controller behavior with no test coverage specified. Either add JS test expectations or note manual verification.

Blast Radius

No existing time tracking code in the codebase (grep confirmed). This is a clean greenfield addition. The nav slot 2 reuse (Week for admin, Hours for member/lead) is architecturally sound since the roles are mutually exclusive, but should be documented via a code comment. No downstream consumers affected.

Decomposition Assessment

Exceeds threshold.

• File targets: 7 (2 create + 5 modify), all in 1 repo — OK
• Acceptance criteria: 10 (threshold: >5) — EXCEEDS
• Estimated agent work: Borderline 5 minutes. Creating nav tab entry, view, Stimulus controller, CSS, and request specs. The AC items are interrelated (all states of one widget), so the work is cohesive.

NEEDS DECOMPOSITION — route to skill-decompose-ticket. Suggested split:

1. Hours tab: nav + route + page shell (AC 1, 2, 10) — Add :hours to TAB_ROLES, nav slot 2, basic index view, flag gating. ~2 points.
2. Hours tab: timer widget + clock/break UI (AC 3-9) — Stimulus timer_controller.js, button states, Turbo Stream actions, today’s log. ~3 points.

Recommendation

• [SCOPE] Create user story entry "crew-time-tracking" on project-landscaping-assistant user-stories section.
• [SCOPE] arch-rails note describes ISS Rails, not landscaping-assistant. Update arch-rails to be multi-project or create a landscaping-assistant-specific variant.
• [BODY] Clarify app/controllers/hours_controller.rb is created by #332, not pre-existing. Move from "Files to modify" to a note like "(created by dependency #332)".
• [BODY] Add test expectations for Stimulus controller behavior (AC 4-6: timer display, break pause/resume). Currently only request specs are specified but three AC are pure client-side JS.
• [DECOMPOSE] 10 AC across 7 file targets exceeds the 5-minute rule. Split into nav/page-shell ticket and timer-widget ticket. Route to skill-decompose-ticket.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- present (references parent #331)
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- present, well-formed
• [x] Context -- present, references BusyBusy UX pattern
• [x] File Targets -- present with create/modify/do-not-touch sections
• [x] Feature Flag -- present (time_tracking, reuses parent flag)
• [x] Acceptance Criteria -- 6 criteria present
• [x] Test Expectations -- present with run command
• [x] Constraints -- present (Mon-Sun, duration format, no pagination)
• [x] Checklist -- present
• [x] Related -- present

Traceability

• [x] story:crew-time-tracking label -- present on board item
• [ ] story note MISSING -- [SCOPE] No crew-time-tracking entry in project-landscaping-assistant user-stories section. Create user story entry on project-landscaping-assistant.
• [x] arch:rails label -- present
• [x] arch note verified -- arch-rails note exists in pal-e-docs (note: associated with ISS project, not landscaping-assistant, but architecture note exists)
• [x] Forgejo issue -- #334, open

File Targets

• [x] app/views/hours/_daily_entries.html.erb -- to create (new file, OK)
• [x] app/views/hours/_weekly_summary.html.erb -- to create (new file, OK)
• [ ] app/views/hours/index.html.erb -- ISSUE: listed as "modify" but does not exist yet. Created by upstream ticket #1938 (board #1938, "Hours tab: clock in/out/break UI")
• [ ] app/controllers/hours_controller.rb -- ISSUE: listed as "modify" but does not exist yet. Created by upstream ticket #1938
• [ ] app/models/time_entry.rb -- ISSUE: listed as "modify" but does not exist yet. Created by upstream ticket #1937 (board #1937, "TimeEntry data model + API + flag", sprint:6)
• [x] app/assets/stylesheets/application.css -- verified, exists (59KB)
• [x] Referenced pattern work_queue_items/_queue_item.html.erb -- verified, exists in codebase

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets within the same repo. No cross-repo concerns.

Dependencies

• #1937 "TimeEntry data model + API + flag" (sprint:6, backlog) -- creates TimeEntry model, time_tracking feature flag, and time entry API. This ticket's model scopes (for_date, for_week, total_duration) and feature flag depend on #1937. NOT mentioned in Lineage section.
• #1938 "Hours tab: clock in/out/break UI" (sprint:7, backlog) -- creates hours_controller.rb, hours/index.html.erb, routes, and timer widget. Mentioned in Lineage ("Depends on the Hours tab UI ticket").
• #1936 "Time Tracking: Hours Tab (parent)" (backlog) -- umbrella/parent issue for all time tracking work.
• The time_tracking feature flag is not yet registered in lib/tasks/feature_flags.rake -- will be added by #1937.
• Both #1937 and #1938 are currently in backlog. Execution order: #1937 (sprint:6) first, then #1938 and #1939 (sprint:7).

Acceptance Criteria

6 criteria, all concrete and agent-verifiable:

• AC 1-4: view-level checks (entries display, weekly section, totals, zero-hours) -- verifiable via request specs checking response body
• AC 5: logic check (break subtraction) -- verifiable via model spec
• AC 6: Turbo Stream update after clock out -- verifiable; Turbo Stream patterns exist in codebase (e.g., work_queue_items/create.turbo_stream.erb, days/add_to_queue.turbo_stream.erb)

Test commands are real (bundle exec rspec). Test expectations cover both request and model specs.

Blast Radius

Low. This is a new feature adding views and scopes to a new model/controller pair. No existing code is modified except application.css (additive styles). No downstream consumers affected. No similar bug patterns to check -- this is net-new functionality.

Decomposition Assessment

6 file targets across 1 repo. 6 acceptance criteria (triggers the >5 AC rule). However, the work is highly cohesive: all changes serve a single UI feature (daily/weekly summary views), the model scopes are simple query wrappers, and the view partials are tightly coupled. Estimated agent time: ~4-5 minutes. No decomposition needed -- the >5 AC trigger is borderline and the work does not span multiple systems or repos.

Recommendation

• [SCOPE] Create user story entry crew-time-tracking on project-landscaping-assistant user-stories section. Suggested row: Key=crew-time-tracking, Role=Crew member/lead, Summary="Clock in/out, view daily and weekly hour totals", Success Metric="Timer widget, daily entries list, weekly summary with break deductions"
• [BODY] Add #1937 "TimeEntry data model + API + flag" as explicit dependency in Lineage section. Current Lineage only mentions #1938 but #1937 creates the TimeEntry model and time_tracking flag that this ticket depends on.
• [BODY] Clarify File Targets: time_entry.rb, hours_controller.rb, and hours/index.html.erb are listed under "Files to modify" but do not exist yet -- they will be created by upstream tickets #1937 and #1938. Add a note like "(created by #1937)" / "(created by #1938)" next to each.

Verdict: APPROVED

Board item #1296 — Forgejo issue ldraney/landscaping-assistant#57. Type: Feature. Points: 2. Re-review after body updates.

Previous review: review-1296-2026-07-26 (NEEDS_REFINEMENT). All [BODY] recommendations have been addressed.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, related to #43 (observability parent)
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — present (developer wants timestamps for DORA metrics)
• [x] Context — present (null timestamps in Woodpecker API response)
• [x] File Targets — present, verified (see below)
• [x] Feature Flag — present ("None — infrastructure/CI change, no user-visible behavior")
• [x] Acceptance Criteria — 3 items, all testable
• [x] Test Expectations — 2 items
• [x] Constraints — present
• [x] Checklist — present
• [x] Related — present (includes docs/dora/pipeline-timing.md reference)

Traceability

• [x] story:observability label — no formal user-stories entry, acceptable for infrastructure/DevOps work
• [x] story:dora label — no formal user-stories entry, acceptable for infrastructure/DevOps work
• [x] arch:ci-pipeline label — arch-ci-pipeline note exists in pal-e-docs (covers shared Woodpecker pipeline pattern)
• [x] Forgejo issue — ldraney/landscaping-assistant#57, state: open

File Targets

• [x] .woodpecker.yaml — verified: file exists (89 lines), defines clone/bundle-install/lint/test/build-and-push steps. Correct extension (previous review caught .yml typo, now fixed).
• [x] forgejo_admin/pal-e-platform (cross-repo) — verified: issue now explicitly names the repo and notes it is Terraform-managed. arch-ci-pipeline note confirms Woodpecker server config lives in pal-e-platform.
• [x] docs/dora/pipeline-timing.md — verified: 213-line DORA metrics doc exists with pipeline timing, mermaid diagrams, and DORA ratings. Correctly referenced in Related section.

Repo Placement

OK. Issue filed on landscaping-assistant, which is the repo whose DORA metrics are being measured. Issue now explicitly acknowledges cross-repo scope: "Woodpecker server config lives in forgejo_admin/pal-e-platform (Terraform-managed) — may require cross-repo investigation." This is clear and accurate.

Dependencies

No blocking dependencies. #1294 (Verify DORA metrics flowing in Grafana) is done. Parent #43 (observability chain) is open but non-blocking. No items in in_progress or next_up are related to DORA/observability/pipeline timestamps.

Acceptance Criteria

3 AC items, all testable via Woodpecker MCP tools (list_pipelines, get_pipeline_status). AC #3 was tightened from previous review — now reads "DORA deployment frequency calculable from push-to-main pipeline history (query list_pipelines, confirm non-null timestamps)." Binary pass/fail verifiable. Test expectations correctly reference the same MCP tools.

Blast Radius

If the fix involves a Woodpecker server upgrade or config change in pal-e-platform, it affects ALL repos using Woodpecker CI (basketball-api, pal-e-docs, westside-contracts, etc. per arch-ci-pipeline). The issue's Constraints section acknowledges this ("May require Woodpecker server upgrade or config change"). Validation should include spot-checking timestamps on at least one other repo's pipelines.

Decomposition Assessment

2 file targets (1 local, 1 cross-repo reference), 3 acceptance criteria, 2 story points. Fits in a single agent pass. No decomposition needed.

Recommendation

No action needed.

Verdict: APPROVED

Re-review after label fix: story:property-management changed to story:property-crud. Previous review slug: review-1468-2026-07-26 (r1, NEEDS_REFINEMENT).

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, follow-up to PR #207
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — proper As/I want/So that format
• [x] Context — explains PR #207 replaced alphabetical with proximity-only, motivates toggle
• [x] File Targets — 4 modify, 2 do-not-touch
• [x] Feature Flag — "none" (UI sort toggle, not new workflow — acceptable)
• [x] Acceptance Criteria — 5 criteria
• [x] Test Expectations — 3 expectations with run command
• [x] Constraints — 3 constraints (no Tailwind, no cookies, preserve filter controller)
• [x] Checklist — present
• [x] Related — present

Traceability

• [x] story:property-crud label — present on board item
• [x] story note verified — "property-crud" found in project-landscaping-assistant user-stories table ("Add/edit/delete client properties", success metric: "Full CRUD with search and filter")
• [x] arch:rails-app label — present on board item
• [x] arch note verified — arch-rails-app note exists in pal-e-docs (active)
• [x] Forgejo issue — ldraney/landscaping-assistant#225, state: open

File Targets

• [x] app/controllers/properties_controller.rb — verified: line 13 has @properties = Property.by_proximity(property_scope.includes(:services)), the exact line needing conditional sort logic
• [x] app/views/properties/manage.html.erb — verified: exists, has filter chips area (service-filters div) as a natural home for the sort toggle
• [x] app/assets/stylesheets/application.css — verified: existing CSS patterns (filter-chip, btn-toggle, toggle-switch) provide reusable patterns
• [x] spec/requests/properties_spec.rb — verified: existing tests for GET /properties/manage with sort ordering tests at lines 22 and 44
• [x] app/models/property.rb (do-not-touch) — verified: by_proximity class method exists at line 26, no model changes needed
• [x] app/controllers/weeks_controller.rb (do-not-touch) — verified: uses by_proximity at line 10, correctly excluded as separate concern

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant. All file targets are in that repo. No cross-repo concerns.

Dependencies

No blocking dependencies. Item is in backlog (sprint:3). Only active item is #1926 (keycloak/email infra) — unrelated. PR #207 (proximity sort) is already merged — this ticket builds on it.

Acceptance Criteria

5 criteria, all verifiable by an agent:

• AC1 (alphabetical default) — testable via request spec checking order
• AC2 (visible toggle) — testable via response body inspection
• AC3 (URL query param) — testable via ?sort=proximity param
• AC4 (uses existing by_proximity) — testable by verifying sort order matches model method
• AC5 (filters still work) — testable via request spec with combined params

3 test expectations with exact run command (bundle exec rspec spec/requests/properties_spec.rb). Complete and actionable.

Blast Radius

• weeks_controller.rb line 10 also uses Property.by_proximity — explicitly excluded from scope, correct.
• days_controller.rb line 16 uses order(:client_name) for alphabetical — serves as reference pattern for the default sort.
• work_queue_items_controller.rb line 358 uses Arel.sql("LOWER(client_name)") — matches AC #1's "case-insensitive" requirement, serves as reference.
• No downstream consumers affected — UI-only change on Properties manage view.

Decomposition Assessment

4 file targets in 1 repo. 5 acceptance criteria. Estimated agent work under 5 minutes — simple controller conditional, HTML toggle element, minor CSS, spec additions. No decomposition needed.

Recommendation

No action needed.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [ ] Feature Flag -- MISSING. This adds user-visible functionality (per-property photo gallery, project tracking). The repo has docs/feature-flags.md. Section required by template-issue-feature.
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:property-crud label -- "Add/edit/delete client properties" found in project-landscaping-assistant user-stories section
• [x] story note verified -- found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label -- Rails App (Shared Pattern)
• [x] arch note verified -- arch-rails-app note exists in pal-e-docs
• [x] Forgejo issue -- ldraney/landscaping-assistant#116, open

File Targets

• [x] app/views/layouts/application.html.erb -- verified exists. BUT: no Photos tab in bottom nav to remove (see Recommendation).
• [x] app/views/properties/show.html.erb -- verified exists. No upload/photo content yet, correct target for adding gallery.
• [x] app/models/upload.rb -- verified exists. Currently has no belongs_to :property. Correct target.
• [x] app/models/property.rb -- verified exists. Currently has no has_many :uploads. Correct target.
• [x] db/migrate/ -- verified exists. Uploads table currently has no property_id column. Migration needed.
• [x] app/controllers/uploads_controller.rb -- verified exists. Currently standalone, not scoped to property.
• [x] config/routes.rb -- verified exists. Uploads currently standalone: resources :uploads, not nested under properties.
• [x] app/models/project.rb (new) -- does not exist yet, correctly marked as new file.

Repo Placement

OK -- issue filed on ldraney/landscaping-assistant, all file targets are in this repo. Single-repo change.

Dependencies

• Board item #1403 "Property detail page: Projects section (depends on #122)" (3pt, backlog) covers project tracking on the property page. This ticket (#1338) also includes "per-property project tracking." Potential overlap not documented in either ticket.
• No items currently in_progress that block this ticket.
• Ticket #107 (auth/tab visibility) is referenced in Related but already landed.

Acceptance Criteria

7 acceptance criteria. Most are verifiable by an agent (model associations, route scoping, file size checks). However:

• AC #1 ("Photos tab removed from bottom nav") targets UI that does not exist. Current bottom nav tabs are: Today, Week, Profile, Properties, Crew. There is no Photos tab.
• AC #7 ("Existing photos migrated to property association") is ambiguous -- existing uploads are schedule photos (with week_start column) from the Week view. Migrating them to a property doesn't make semantic sense. The issue should specify whether these become orphaned, remain standalone, or are handled differently.

Blast Radius

• Week view schedule uploads will break. The Week view (app/views/weeks/index.html.erb) has a form posting to uploads_path for schedule photo uploads (behind the schedule_digest feature flag). If uploads are nested under properties (/properties/:id/uploads), the standalone uploads_path helper disappears, breaking this form. The issue does not mention the schedule upload workflow at all.
• Existing upload specs. spec/requests/uploads_spec.rb and spec/models/upload_spec.rb all test standalone upload behavior. Route nesting will require updating all request specs.
• Property comments already support photo attachments. property_comments (nested under properties in routes) already accept image uploads. The relationship between comment photos and the new per-property photo gallery should be clarified to avoid UX confusion.

Decomposition Assessment

7 AC, 8 file targets, 1 repo. No decomposition needed.

Recommendation

• [BODY] Add ### Feature Flag section -- new user-visible gallery and project tracking should be flagged. Consult docs/feature-flags.md for conventions.
• [BODY] Fix Context section -- "The current Photos tab" does not exist. Current bottom nav has 5 tabs (Today, Week, Profile, Properties, Crew). The upload functionality lives at /uploads as a standalone page and via the "Upload Schedule" button on the Week view. Rewrite to reflect actual current state.
• [BODY] Fix AC #1 -- "Photos tab removed from bottom nav" targets nonexistent UI. Replace with accurate criterion (e.g., remove standalone /uploads index route, or clarify what actually changes in nav).
• [BODY] Address schedule upload blast radius -- the Week view's "Upload Schedule" form posts to standalone uploads_path. If uploads are nested under properties, specify how schedule uploads (which have no property association) should work. Options: keep a standalone route for schedule uploads, or make schedule uploads a separate model.
• [BODY] Clarify AC #7 migration strategy -- existing uploads are schedule photos with week_start data. Specify whether they become orphaned, stay standalone, or get a nullable property_id.
• [BODY] Document relationship with #1403 -- board item #1403 "Property detail page: Projects section" also covers project tracking on the property page. Clarify whether #1338 supersedes #1403, or whether #1403 builds on #1338's project model.

Verdict: NEEDS_REFINEMENT

Board item #1296 — Forgejo issue ldraney/landscaping-assistant#57. Type: Feature. Points: 2.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, related to #43 (observability parent)
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — present (developer wants timestamps for DORA metrics)
• [x] Context — present (null timestamps in Woodpecker API response)
• [x] File Targets — present (but inaccurate, see below)
• [ ] Feature Flag — MISSING. Section required by template-issue-feature. Infra work should specify "none" with rationale.
• [x] Acceptance Criteria — 3 items
• [x] Test Expectations — 2 items
• [x] Constraints — present
• [x] Checklist — present
• [x] Related — present

Traceability

• [ ] story:observability label — NO entry in project-landscaping-assistant user-stories section. [SCOPE] Create user story entry "observability" on project-landscaping-assistant user-stories section.
• [ ] story:dora label — NO entry in project-landscaping-assistant user-stories section. [SCOPE] Create user story entry "dora" on project-landscaping-assistant user-stories section.
• [x] arch:ci-pipeline label — arch-ci-pipeline note exists in pal-e-docs (covers shared Woodpecker pipeline pattern)
• [x] Forgejo issue — ldraney/landscaping-assistant#57, state: open

File Targets

• [ ] .woodpecker.yml — ISSUE: Wrong extension. Actual file is .woodpecker.yaml. Additionally, pipeline YAML defines steps, not API response fields — timestamp population is a Woodpecker server behavior, unlikely fixable via pipeline config.
• [ ] "Woodpecker server config" — ISSUE: Too vague. No concrete file path or repo specified. If this refers to Woodpecker Helm values or deployment config, it likely lives in pal-e-platform (terraform/kustomize), not in landscaping-assistant.

Repo Placement

Issue filed on ldraney/landscaping-assistant, but the fix may require Woodpecker server-side changes (upgrade, config) which live in pal-e-platform. The .woodpecker.yaml in this repo defines pipeline steps, not server API behavior. If the root cause is a Woodpecker server version issue, the fix touches pal-e-platform, not this repo. The issue should clarify which repo(s) are affected, or acknowledge that the repo placement depends on root cause analysis.

Dependencies

No blocking dependencies found on board-landscaping-assistant. Parent issue #43 (Observability & DORA metrics stack) is open but does not block this work. No items currently in in_progress or next_up are related to DORA/observability/pipeline timestamps.

Acceptance Criteria

3 AC items, all testable via Woodpecker MCP tools (list_pipelines, get_pipeline_status). The test expectations correctly reference these tools. AC is reasonable and verifiable. Note: AC #3 ("DORA deployment frequency derivable from push-to-main pipeline history") is somewhat vague — "derivable" is not a binary pass/fail condition. Consider tightening to something like "pipeline history includes timestamps sufficient to calculate deploy count per time period."

Blast Radius

If the fix involves a Woodpecker server upgrade or config change, it affects ALL repos using Woodpecker CI across the platform, not just landscaping-assistant. The arch-ci-pipeline note documents the shared pipeline pattern used by basketball-api, pal-e-docs, westside-contracts, and other services. A server-side change should be validated against multiple repos. Existing DORA doc at docs/dora/pipeline-timing.md was built from manual log scraping — this ticket would enable programmatic collection.

Decomposition Assessment

2 file targets (one incorrect), 3 acceptance criteria, 2 story points. Fits in a single agent pass. No decomposition needed.

Recommendation

• [BODY] Fix file extension: .woodpecker.yml → .woodpecker.yaml
• [BODY] Add Feature Flag section with value "none" and rationale "CI/infra investigation, no user-visible behavior"
• [BODY] Replace vague "Woodpecker server config" with concrete path or repo reference. If unknown, state: "Root cause TBD — may require changes in pal-e-platform (Woodpecker Helm values / deployment config)"
• [BODY] Tighten AC #3 from "derivable" to a testable condition
• [SCOPE] Create user story entry "observability" on project-landscaping-assistant user-stories section
• [SCOPE] Create user story entry "dora" on project-landscaping-assistant user-stories section

Verdict: APPROVED

Scope is clear and actionable. All file targets verified, traceability complete, dependencies documented and resolved. One minor line-reference inaccuracy in the body does not block implementation.

Template Completeness

• [x] Type (Feature)
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag (None -- acceptable: read-only display on existing page, not a new user workflow)
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:auth label -- "Log in with Keycloak, see role-appropriate tabs and features"
• [x] story note verified -- "auth" key found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label -- Rails App (Shared Pattern)
• [x] arch note verified -- arch-rails-app note exists in pal-e-docs
• [x] Forgejo issue -- ldraney/landscaping-assistant#176, open

File Targets

• [x] app/views/properties/show.html.erb -- verified: exists, current structure has property details + comments section, projects section would be inserted between them
• [x] app/views/properties/_service_requests.html.erb -- new partial (does not exist yet, expected)
• [x] app/assets/stylesheets/application.css -- verified: exists (59k). Line reference inaccuracy: ticket says .status-indicator and .role-badge at lines 1564-1616, but actual locations are lines 1999-2048. Class names are correct and findable by grep.
• [x] app/controllers/properties_controller.rb -- verified: exists, show action at line 78 currently loads comments but not service_requests
• [x] spec/requests/properties_spec.rb -- verified: exists (17k)
• [x] ServiceRequest::STATUSES and ServiceRequest::VALID_TRANSITIONS -- verified: defined in app/models/service_request.rb at lines 5 and 7
• [x] Property has_many :service_requests -- verified: association exists at line 9 of app/models/property.rb

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo change.

Dependencies

• [x] #122 (ServiceRequest model) -- DONE on board (item 1347), merged. Prerequisite satisfied.
• [x] #126 (CSS refresh) -- DONE on board (item 1351), merged. Prerequisite satisfied.
• [x] #206 (decline transitions bug) -- DONE on board (item 1452), merged. Non-blocking per ticket.
• [x] #123 (Client request form) -- backlog (item 1348), sibling ticket. Not a dependency.
• [x] #179 (Admin project workflow) -- backlog (item 1404), depends on THIS ticket. Correctly sequenced.

All upstream dependencies resolved. Downstream dependency (#179) correctly documents dependency on this ticket.

Acceptance Criteria

6 ACs, all testable and verifiable by an agent:

• Projects section visibility -- check DOM element presence in show response
• Active request grouping -- verify correct statuses rendered together
• Completed/declined separation -- check separate rendering section
• Request detail display -- verify description, badges, price in rendered HTML
• Empty state -- test with property that has no service_requests
• Mobile layout -- verify CSS uses 44px touch targets and proper spacing

All criteria are concrete and machine-verifiable via request specs.

Blast Radius

Contained. Changes are isolated to the property detail page:

• Existing service_request usage in property_comments views/controller is separate (comment-linked requests, not a standalone list).
• New CSS classes are additive; existing .status-indicator and .role-badge patterns are reused, not modified.
• Controller change (eager-loading) adds a query, does not modify existing behavior.
• No other views render a project/request list -- this is the first.

Decomposition Assessment

5 file targets, 1 repo, 6 ACs -- all within the property detail page domain. Estimated agent work under 5 minutes. No decomposition needed.

Recommendation

• [BODY] Fix CSS line references: ticket says .status-indicator and .role-badge at lines 1564-1616, actual location is lines ~1999-2048. Class names are correct; only the line numbers need updating.

Verdict: APPROVED

Re-review of board item #1927 after refinement. Previous review (review-1927-2026-07-26) found 4 issues; all have been addressed in the updated issue body.

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 12 required sections for the Feature template are present. Context section is exceptionally thorough with Keycloak docs citations.

Traceability

• [x] story:account-email label -- "Receive password reset and email verification emails via Postmark SMTP"
• [x] story note verified -- found in project-landscaping-assistant user-stories section. Backing note story-landscaping-assistant-account-email exists with active status.
• [x] arch:rails label -- Rails framework
• [x] arch note verified -- arch-rails note exists in pal-e-docs
• [x] arch:keycloak label -- Keycloak OIDC
• [x] arch note verified -- arch-keycloak note exists in pal-e-docs
• [x] Forgejo issue -- ldraney/landscaping-assistant#324, open

File Targets

• [x] app/controllers/landing_controller.rb -- new file, does not exist yet (correct). Pattern matches existing PagesController which uses skip_before_action :authenticate_user!
• [x] app/views/landing/index.html.erb -- new file, does not exist yet (correct)
• [x] config/routes.rb -- verified: exists, current root is work_queue_items#index at line 69. Conditional root based on feature flag is a clean change.
• [x] app/assets/stylesheets/application.css -- verified: exists
• [x] keycloak-theme/landscaping/login/resources/css/login.css -- verified: #kc-registration { display: none !important; } confirmed at lines 405-407 with Apple Guideline 2.1(a) comment at lines 396-403
• [x] pal-e-services/terraform/k3s.tfvars -- conditional on #321 (in_progress). Issue correctly states "if #321 is already merged when this work begins, no pal-e-services changes are needed"
• [x] pal-e-platform/terraform/modules/keycloak/main.tf -- cross-repo, differentiated from #321: theme ConfigMap update (login.css content) vs #321's Postmark provisioning

Repo Placement

OK. Filed on landscaping-assistant (correct for primary work). Three repos identified with distinct scopes: landscaping-assistant (Rails landing page + login.css), pal-e-services (conditional SMTP config if #321 not merged), pal-e-platform (theme ConfigMap). Each repo's concern is clearly documented in File Targets.

Dependencies

• #321 (board item #1926, in_progress) -- explicitly documented as dependency in Lineage: "Depends on #321 (Postmark SMTP + verify_email for landscaping Keycloak realm) -- SMTP must be live before the registration link is unhidden." Previous review issue #1: RESOLVED.
• #290 (done) -- referenced in Lineage. This ticket undoes #290's CSS hide once registration is functional.
• #282 (done) -- multi-tenancy, referenced in Lineage as unblocking public registration with business codes.

Acceptance Criteria

10 ACs total. ACs 1-3, 8, 10 are Rails-testable and covered by Test Expectations (4 request specs). ACs 4-7, 9 are Keycloak + Postmark integration validations that depend on #321 completing first -- these are infrastructure-level checks verified during validation, not automated tests. This is acceptable given the deploy sequencing model.

Blast Radius

Previous review flagged ungated registration link unhide risking App Store rejection. Now addressed via deploy sequencing: the Lineage section states "SMTP must be live before the registration link is unhidden, otherwise Apple reviewers see a broken registration flow (Guideline 2.1(a))." The Constraints section reinforces: "Registration link CSS change must NOT ship before #321 (SMTP + verify_email) is live." The Feature Flag section correctly separates concerns: public_landing flag gates the Rails landing page, deploy sequencing gates the Keycloak CSS change. Previous review issue #2: RESOLVED.

The skip_before_action :authenticate_user! pattern is established in the codebase (PagesController, ClientErrorsController, SessionsController), so the proposed LandingController follows existing convention. The feature_enabled? helper is used in 10+ controllers -- well-established pattern.

Decomposition Assessment

Technically exceeds 5-minute rule thresholds: 6 files across 2 repos (pal-e-services conditional), 10 ACs. Project owner has explicitly decided to keep this as one ticket. At 8 points, the sizing acknowledges the scope. The work is logically cohesive -- splitting the landing page from the registration link unhide would create artificial sequencing overhead. Owner override accepted.

Previous Review Issues -- Resolution Status

1. Scope overlap with #321 -- RESOLVED. #321 is now an explicit dependency in Lineage with clear conditional language in File Targets.
2. Ungated blast radius -- RESOLVED. Deploy sequencing documented in Lineage, Context, and Constraints. Feature flag correctly scoped to Rails-only changes.
3. Cross-repo scope clarity -- RESOLVED. File Targets differentiate #324's pal-e-platform touch (theme ConfigMap) from #321's (Postmark provisioning).
4. Decomposition -- OVERRIDDEN by project owner decision. Acknowledged at 8 points.

Recommendation

No action needed. Ticket is ready for implementation once #321 (in_progress) is merged.

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 12 required sections for the Feature template are present and well-written. The Context section is thorough with source references.

Traceability

• [x] story:account-email label -- "Receive password reset and email verification emails via Postmark SMTP"
• [x] story note verified -- found in project-landscaping-assistant user-stories section
• [x] arch:rails label -- Rails framework
• [x] arch note verified -- arch-rails note exists in pal-e-docs (shared across projects, ISS-specific but describes common Rails patterns)
• [x] arch:keycloak label -- Keycloak OIDC
• [x] arch note verified -- arch-keycloak note exists in pal-e-docs (shared infra component, pal-enterprises project)
• [x] Forgejo issue -- ldraney/landscaping-assistant#324, open

File Targets

• [x] app/controllers/landing_controller.rb -- new file, does not exist yet (correct for new feature)
• [x] app/views/landing/index.html.erb -- new file, does not exist yet (correct for new feature)
• [x] config/routes.rb -- verified: exists, current root is work_queue_items#index at line 69
• [x] app/assets/stylesheets/application.css -- verified: exists (59k)
• [x] keycloak-theme/landscaping/login/resources/css/login.css -- verified: exists, #kc-registration { display: none !important; } confirmed at lines 405-407 with comment at lines 400-403 about Apple Guideline 2.1(a)
• [ ] pal-e-services/terraform/k3s.tfvars -- ISSUE: scope overlap with #321 (in_progress, same story:account-email). #321 "Configure Postmark SMTP for landscaping Keycloak realm" is already handling this file
• [x] pal-e-platform/terraform/modules/keycloak/main.tf -- cross-repo target, plausible (theme ConfigMap update)

Repo Placement

Issue is filed on landscaping-assistant (correct for primary work). Three repos identified with separate PRs planned in the Checklist. However, the pal-e-services scope overlaps with #321 which is already in_progress on the same board.

Dependencies

• #321 (board item #1926) -- "Configure Postmark SMTP for landscaping Keycloak realm" is in_progress with labels type:infra,arch:keycloak,story:account-email,track:devops. This ticket handles the pal-e-services SMTP config AND pal-e-platform Postmark provisioning. It is a direct prerequisite for #324 but is NOT referenced anywhere in the issue body, Lineage, or Related sections.
• #290 (done) -- hid the Keycloak registration link for App Store 2.1(a) compliance. #324 explicitly undoes that work. Referenced in Lineage.
• #282 (multi-tenancy, done) -- referenced in Lineage. No active dependency.
• #309, #310 (next_up, SaaS sprint 2) -- no direct dependency, but both depend on Keycloak registration working. No conflict.

Acceptance Criteria

10 acceptance criteria total. Testability assessment:

• [x] ACs 1, 2, 3, 8, 10 -- testable via Rails request specs (covered by Test Expectations section)
• [ ] ACs 4-7, 9 -- require Keycloak + Postmark integration testing. No test coverage specified for these. These are infrastructure-level validations that depend on #321 completing first. The Test Expectations section only covers 4 of the 10 ACs.

Blast Radius

CRITICAL: The ticket says "Keycloak-side changes (verify_email, SMTP, registration link unhide) are infrastructure config and do not need an app-level flag." But removing #kc-registration { display: none !important; } from login.css (line 405-407) is a change in the landscaping-assistant repo's Keycloak theme, not infrastructure config. This CSS change is NOT gated by the public_landing feature flag.

Impact: When the CSS hide is removed but public_landing flag is off, iOS app users will see the Register link on the Keycloak login page. This is the exact scenario that #290 was created to prevent (Apple Guideline 2.1(a): apps that link to external registration mechanisms). Undoing it without a gate risks another App Store rejection.

The comment in login.css (lines 400-403) itself says: "Re-enable by removing this block when client self-registration is ready for production." This suggests the unhide should be a deliberate, coordinated step -- not an ungated change.

The business_codes flag (#312, done) already processes registration data in the sessions controller, confirming that Keycloak registration IS configured. But the register link was deliberately hidden from the login page UI.

Decomposition Assessment

Even after accounting for #321 handling the pal-e-services scope:

• 5 file targets in primary repo + 1 in pal-e-platform = 6 files across 2 repos (>3 files across >2 repos -- note: threshold is "across >2 repos" and this is on the edge)
• 10 acceptance criteria (>5 threshold)
• Estimated agent work: >5 minutes (landing page design, route changes, CSS, tests, cross-repo ConfigMap)

NEEDS DECOMPOSITION -- route to skill-decompose-ticket. Suggested split:

1. Rails landing page + feature flag -- LandingController, view, routes.rb conditional root, application.css, feature flag registration, request specs
2. Keycloak registration link unhide -- login.css change, pal-e-platform theme ConfigMap update, flag-gating decision for the CSS change
3. Integration verification -- ACs 4-7 and 9, end-to-end registration flow validation (depends on #321 completing)

Recommendation

• [BODY] Remove pal-e-services file targets -- #321 (in_progress) already handles k3s.tfvars SMTP config. Remove the "pal-e-services PR" Checklist item. Add #321 as explicit prerequisite in Lineage section.
• [BODY] Address blast radius: document how the registration link unhide (login.css line 405-407) interacts with App Store Guideline 2.1(a). Either (a) gate the CSS unhide behind the public_landing flag via a separate theme file, (b) coordinate the CSS change to deploy only when the flag is enabled in production, or (c) document why it is now safe (e.g., App Store no longer enforces 2.1(a) for this case).
• [BODY] Clarify pal-e-platform scope boundary with #321 (Postmark provisioning vs theme ConfigMap are in the same repo but different concerns).
• [DECOMPOSE] 6 files across 2 repos, 10 ACs -- exceeds 5-minute rule. Route to skill-decompose-ticket.

Verdict: APPROVED

Re-review after three refinements. All issues from the prior review have been resolved. Ticket is ready for agent execution.

Template Completeness

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

Traceability

• [x] story:account-email label -- present on board item
• [x] story note verified -- story-landscaping-assistant-account-email exists (note ID 2729, status active)
• [x] story in project page -- account-email entry found in project-landscaping-assistant user-stories table
• [x] arch:keycloak label -- present on board item
• [x] arch note verified -- arch-keycloak exists (note ID 1728)
• [x] Forgejo issue -- ldraney/landscaping-assistant#321, open

File Targets

• [x] pal-e-platform/terraform/main.tf -- verified: module "postmark_iss" exists at line 168 as pattern for new postmark_landscaping module
• [x] pal-e-platform/terraform/dns.tf -- verified: ISS DKIM record (iss_postmark_dkim, line 81) and Return-Path record (iss_postmark_return_path, line 89) exist as pattern. No SPF/DMARC in Terraform -- correct per ISS pattern
• [x] secrets/pal-e-services/k3s.tfvars -- verified: landscaping realm at line 94 has no smtp block yet; ISS smtp pattern at lines 111-118 provides the template
• [x] pal-e-services/docs/postmark-email.md (reference) -- exists
• [x] pal-e-services/terraform/keycloak.tf (reference) -- exists; dynamic smtp_server block at line 49 consumes the smtp config from tfvars

Re-Review Refinements Verified

• [x] Lineage DNS ticket corrected: now references pal-e-platform#165 (was incorrectly referencing wrong repo)
• [x] AC #2 corrected: says "DKIM and Return-Path" -- matches actual ISS Terraform pattern (SPF/DMARC are not Terraform-managed)
• [x] account-email story entry added to project-landscaping-assistant user-stories table -- confirmed present
• [x] story-landscaping-assistant-account-email note already existed -- confirmed (note ID 2729)

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant (user-facing project). Work spans two repos: pal-e-platform (Postmark module + DNS records) and pal-e-services (Keycloak SMTP config via k3s.tfvars). Cross-repo nature is correctly documented in the Repo and Checklist sections. Checklist references PRs for both repos.

Dependencies

• No items in in_progress, needs_approval, or qa that block this work
• Prerequisites met: landscaping-assistant.app DNS A record exists in dns.tf (line 12); Keycloak landscaping realm exists in k3s.tfvars (line 94)
• Items in next_up (SaaS sprint 2 -- #1906, #1907) are unrelated
• Lineage correctly references superseded tickets: pal-e-platform#165 (DNS) and pal-e-services#167 (SMTP)

Acceptance Criteria

5 AC items, all specific and verifiable:

• [x] AC1: Postmark server provisioned -- verifiable via Terraform state or Postmark API
• [x] AC2: DKIM and Return-Path DNS records deployed -- verifiable via dig command
• [x] AC3: Postmark domain verification passes -- verifiable in Postmark dashboard
• [x] AC4: Keycloak SMTP config works -- verifiable via admin console "Test connection"
• [x] AC5: Password reset email sends -- end-to-end verifiable

Test Expectations section adds 4 concrete verification steps (dig, Postmark Activity, test connection, password reset). All are actionable.

Blast Radius

Minimal. Adding email to a new Keycloak realm follows the established ISS pattern. The keycloak.tf dynamic block isolates smtp config to the tfvars entry. DNS records are domain-specific. The Postmark module is already encapsulated. No shared code is modified.

Decomposition Assessment

No decomposition needed:

• 3 file targets across 2 repos (threshold: >3 across >2 -- not exceeded)
• 5 acceptance criteria (threshold: >5 -- not exceeded)
• Well-documented pattern with existing procedure doc (postmark-email.md)
• Estimated agent work: <5 minutes (pattern copy from ISS)

Recommendation

No action needed. Ticket is ready for agent execution.

Verdict: READY

Template Completeness

• [x] Type — Feature
• [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 12 required feature template sections present.

Traceability

• [x] story:saas label — SaaS subscription, business codes for crew onboarding, admin approval of join requests, Apple IAP billing
• [x] story note verified — found in project-landscaping-assistant user-stories section (key: saas, children: #309, #310, #312)
• [x] arch:rails-app label — shared Rails deployment architecture
• [x] arch note verified — arch-rails-app note exists in pal-e-docs (active, architecture type)
• [x] Forgejo issue — ldraney/landscaping-assistant#310, state: open

File Targets

• [x] app/controllers/crew_controller.rb — verified: exists (11 lines), has require_role :admin, :super_admin at line 2, currently only index and show actions. Ticket correctly states existing guard will cover new approve/deny actions.
• [x] app/views/crew/index.html.erb — verified: exists (27 lines), currently renders crew members list.
• [x] app/views/crew/_pending_request.html.erb — NEW file (confirmed does not exist yet). Correctly identified as creation target.
• [x] config/routes.rb — verified: exists (70 lines), has resources :crew, only: [:index, :show] at line 53. Ticket correctly identifies adding member routes under existing resource.
• [x] app/models/user_business.rb — verified: exists (12 lines), has STATUSES = %w[pending approved denied] and ROLES constants but no scopes yet. Ticket correctly identifies adding pending and for_business scopes.
• [x] spec/requests/crew_spec.rb — verified: exists (149 lines, 19 existing examples). Uses sign_in_as helper. Agent can follow established patterns for new approve/deny specs.
• [x] app/views/layouts/application.html.erb — verified: exists, has crew nav tab link at line 69. Badge addition target is clearly identifiable.

Repo Placement

OK — all 7 file targets are in ldraney/landscaping-assistant. Forgejo issue filed on same repo. No cross-repo changes needed.

Dependencies

• business_codes feature flag — NOT registered in lib/tasks/feature_flags.rake yet. Ticket correctly documents this as a dependency: "not yet created — needed before this or #309 can ship." The flag registration must happen in a separate task before this ticket can be deployed, but the code can be written and merged behind the flag.
• Profile join form #309 (board item #1906, backlog) — parallel sibling. Creates UserBusiness records that this ticket consumes. Can be developed independently.
• Keycloak registration field #312 (board item #1909, backlog) — parallel sibling. Another path to create UserBusiness records.
• Business code migration — documented as dependency for join_code column on Business table. Required for the overall flow but not for the UI code in this ticket.
• Multi-tenancy items — #1755 (needs_approval) and #1756 (todo) are in-flight multi-tenancy work. These may introduce a current_business helper. This ticket does not depend on them — the admin's business can be derived via UserBusiness.find_by(user_id: current_user[:sub], status: "approved") -> .business since current_user[:sub] stores the Keycloak UUID and matches UserBusiness.user_id.

Acceptance Criteria

12 acceptance criteria. All are testable by an agent:

• Show/hide pending section — testable via request specs with feature flag toggle and pending records
• Approve/deny actions — testable via PATCH requests checking UserBusiness status transitions
• Role enforcement — existing spec pattern covers admin/non-admin access (19 existing examples demonstrate the approach)
• Turbo Stream responses — established pattern exists in days_controller.rb and work_queue_items_controller.rb
• Badge count on nav tab — testable via response body assertions on the layout

AC #5 (visible tabs update on next page load) and AC #6 (denied state on Profile page) are cross-ticket effects that happen automatically via existing role-based tab logic and the Profile ticket respectively. Not directly testable in isolation but the underlying mechanism is verified.

Blast Radius

• Layout change — badge on crew nav tab in application.html.erb affects all pages. Low risk since it is additive (a badge count span) and gated by feature flag + pending count.
• Turbo Stream pattern — established in codebase. Agent can follow existing format.turbo_stream patterns from days_controller.rb.
• No blast radius to sibling services — UserBusiness is only referenced in model specs and this controller. No other controllers consume it yet.

Decomposition Assessment

7 file targets across 1 repo (within 3-file/2-repo threshold). 12 acceptance criteria (above 5-criterion threshold). However, all criteria serve one cohesive UI feature — a pending-requests section with approve/deny buttons plus a badge. Decomposing would create artificial sub-tickets with tight coupling and coordination overhead. Files are small (controller: 11 lines, model: 12 lines, view: 27 lines, routes: 70 lines). Estimated agent time: 5-8 minutes (borderline but acceptable given cohesion). No decomposition needed.

Recommendation

No action needed.

Observation (informational, not blocking): The ticket does not explicitly document how to derive the admin's business from the session. The path is: current_user[:sub] (Keycloak UUID) -> UserBusiness.find_by(user_id: sub, status: "approved") -> .business. The Context section's "CrewMember vs UserBusiness" explanation plus the session controller's sub: auth.uid storage provide enough context for an agent to derive this, so it is not a blocker.

Verdict: READY

Re-review: Previous verdict was NEEDS_REFINEMENT (2 issues). Both resolved. Upgrading to READY.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- References #307, SaaS onboarding sprint
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- "As a platform owner..."
• [x] Context -- Design decisions documented (join_code format, subscription_status enum, defaults)
• [x] File Targets -- Modify and Do NOT touch sections present
• [x] Feature Flag -- "None -- existing multi_tenancy flag gates the broader feature"
• [x] Acceptance Criteria -- 7 criteria
• [x] Test Expectations -- 6 test cases + run command
• [x] Constraints -- 4 constraints (patterns, collision resistance, no new gems, reversible migration)
• [x] Checklist -- Standard checklist
• [x] Related -- Project, dependencies, design doc

Traceability

• [x] story:multi-tenancy label -- "Business model with row-level property isolation" found in project-landscaping-assistant user-stories section
• [x] story:saas label -- "SaaS subscription, business codes for crew onboarding, admin approval of join requests, Apple IAP billing" found in project-landscaping-assistant user-stories section (FIXED since prior review)
• [x] arch:rails-app label -- arch-rails-app note exists (active, architecture type)
• [x] Forgejo issue -- ldraney/landscaping-assistant#308, state: open

File Targets

• [x] app/models/business.rb -- verified: exists (250 bytes), has name/slug validations + has_many :user_businesses and :properties. Matches ticket claim of "simple ActiveRecord validations, no concerns"
• [x] db/migrate/YYYYMMDD_add_business_code_fields.rb -- new file to create. Correct convention. Existing migration 20260705000001_create_businesses.rb confirms businesses table exists with name and slug columns only. No join_code or subscription columns yet.
• [x] spec/models/business_spec.rb -- verified: exists (2.3k), has existing validation and association tests. New test cases will be added alongside.
• [x] Do NOT touch list verified: app/models/user_business.rb exists, db/seeds.rb has 0 Business references, controllers/views/routes excluded. (FIXED since prior review: db/seeds.rb removed from modify targets, correctly placed in Do NOT touch with rationale.)

Repo Placement

OK -- all file targets are in ldraney/landscaping-assistant, matching the Forgejo issue repo. Single-repo, no cross-repo concerns.

Dependencies

• Depends on #294 (Business model creation) -- board item #1754, column: done. Dependency satisfied.
• #295 (multi-tenancy scoping) -- board item #1755, column: needs_approval. Not a dependency. Both touch Business model but no conflict -- #295 adds scoping logic, this ticket adds new columns.
• #296 (test business seed data) -- board item #1756, column: todo. Not a dependency; ticket correctly excludes db/seeds.rb.
• Blocks #309 (join form) -- board item #1906, backlog. Needs join_code field.
• Blocks #310 (admin approval) -- board item #1907, backlog. Needs subscription fields.
• Blocks #312 (Keycloak registration field) -- board item #1909, backlog.

Dependency chain is clean. Upstream dependency (#294) complete. Downstream tickets correctly wait in backlog.

Acceptance Criteria

All 7 criteria are machine-verifiable via RSpec:

• AC 1-3: join_code auto-generation, format validation, uniqueness constraint -- unit tests
• AC 4-5: subscription_status inclusion validation and default -- unit tests
• AC 6: generate_join_code method return value -- method-level unit test
• AC 7: migration column specification -- schema inspection

Run command valid: docker compose run --rm web bundle exec rspec spec/models/business_spec.rb. No missing criteria. Scope correctly limited to data layer.

Blast Radius

• No existing code references join_code, subscription_status, subscription_expires_at, or apple_original_transaction_id anywhere in the codebase
• Business model referenced only by user_business.rb (excluded) and property.rb (belongs_to, unaffected by new columns)
• No controllers, views, or routes affected -- data-layer-only as stated
• multi_tenancy flag exists in worktree (being added by #295). Ticket correctly says no new flag needed for this data-layer change
• No similar patterns in sibling models needing the same treatment

Decomposition Assessment

• File targets: 3 files in 1 repo -- within limits (threshold: >3 across >2 repos)
• Acceptance criteria: 7 -- above the >5 indicator, but all AC are tightly cohesive single-model validations and one migration. No cross-system complexity.
• Estimated agent time: ~3 minutes (one migration, one model edit, one spec update)
• No decomposition needed.

Recommendation

No action needed. Both issues from the prior NEEDS_REFINEMENT review have been resolved:

1. [SCOPE] story:saas entry missing -- now present in project-landscaping-assistant user-stories table
2. [BODY] db/seeds.rb file target incorrect -- removed from modify targets, correctly listed in Do NOT touch section

Verdict: READY

Template Completeness

• [x] Type — Feature
• [x] Lineage — SaaS / multi-tenancy sprint
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — well-formed (As a user on the Profile/Person tab...)
• [x] Context — thorough, describes current placeholder state and target flow with 6-step behavior spec
• [x] File Targets — 6 files listed in table format with current state and change needed
• [x] Feature Flag — business_codes, disabled by default, removal criteria stated (2 weeks stable)
• [x] Acceptance Criteria — 10 criteria, all testable
• [x] Test Expectations — request specs in spec/requests/join_crew_spec.rb, 6 test cases described
• [x] Constraints — 6 explicit do-NOT boundaries
• [x] Checklist — present
• [x] Dependencies — explicit hard dependency on #308
• [x] Related — links to #308, downstream tickets, and docs

Traceability

• [x] story:saas label — "SaaS subscription, business codes for crew onboarding, admin approval of join requests, Apple IAP billing"
• [x] story note verified — found in project-landscaping-assistant user-stories section. Key: "saas", role: "All roles", summary includes business codes and crew onboarding. #309 explicitly listed as child of umbrella #308.
• [x] arch:rails-app label — Rails App (Shared Pattern)
• [x] arch note verified — arch-rails-app note exists in pal-e-docs (active, covers deployment pipeline, Hotwire, CNPG, Keycloak)
• [x] Forgejo issue — https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant/issues/309, state: open

File Targets

• [x] app/views/join_crew/index.html.erb — verified (811 bytes): disabled placeholder form with business_name and join_notes fields, disabled Submit Request button. Matches issue description exactly.
• [x] app/controllers/join_crew_controller.rb — verified (102 bytes, 6 lines): empty index action only, no create. Matches issue description.
• [x] config/routes.rb — verified: line 63 has get "join-crew", to: "join_crew#index" only. No POST route. Matches issue description.
• [x] app/models/user_business.rb — verified: STATUSES = %w[pending approved denied], ROLES = %w[crew_member crew_lead admin], validates uniqueness on [user_id, business_id]. No changes needed per issue. Confirmed.
• [x] app/views/profile/index.html.erb — verified: line 35 links to join_crew_path. No change needed per issue. Confirmed.
• [x] lib/tasks/feature_flags.rake — verified: FEATURES array exists with 14 flags, business_codes not yet present. Agent will add it.

Additional verification: user_businesses table confirmed in db/schema.rb with user_id (string — stores Keycloak sub), business_id (bigint FK), role, status (default: "pending"), favorited. Unique index on [user_id, business_id]. Existing test file spec/requests/join_crew_spec.rb has 3 passing specs for GET /join-crew (unauthenticated redirect, authenticated render, placeholder form). Agent will extend this file.

Note: Issue Context section references current_sub but the actual app helper is current_user[:sub] (verified in application_controller.rb and profile_controller.rb). This is in narrative text only — file targets and AC are correct. Agent will read actual code.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant. All file targets are in the same repo. Single-repo change, no cross-repo effects.

Dependencies

• Hard dependency: #308 (board item #1905) — "Add business code and subscription fields to Business model". Adds join_code column to businesses table. Currently in backlog, state: open. Verified: join_code does NOT exist in db/schema.rb or any migration. This ticket calls Business.find_by(join_code: ...) which requires #308 merged first. Dependency correctly documented in issue.
• Downstream: #310 (board item #1907) — "Admin approval UI on Crew tab for pending join requests". In backlog, 3 points. Enabled by #309 (creates pending UserBusiness records that #310 will display).
• Downstream: #312 (board item #1909) — Keycloak registration field. In backlog, 5 points. Same story:saas but independent path.
• No items currently in in_progress or next_up that block this ticket (next_up has only #1683, an iOS pipeline bug).
• Issue correctly states exclusive ownership of business_codes feature flag registration — #310, #311, #312 should NOT also register it.

Acceptance Criteria

10 ACs, all testable via request specs. Each maps to a specific HTTP verb + path + expected response. Test expectations section names the spec file (spec/requests/join_crew_spec.rb) and describes 6 test cases covering the major ACs. Auth enforcement testable via existing sign_in_as helper (already used in the existing spec file). Feature flag gating testable via existing feature_enabled? helper. Turbo response testable via content type assertion.

Blast Radius

Low. Changes are self-contained to the join_crew namespace (controller + view + route + flag). UserBusiness model is NOT modified — only creates new records via standard ActiveRecord. Feature flag gating ensures zero impact when disabled. No cross-repo effects. No downstream consumers affected until #310 adds admin approval UI. The business_codes flag is new and independent of the existing multi_tenancy flag.

Decomposition Assessment

• 6 file targets in 1 repo — under the >3 files across >2 repos threshold
• 10 acceptance criteria — exceeds the >5 threshold
• Estimated agent work: ~4 minutes (1 controller action, 1 view rewrite, 1 route, 1 flag)

The AC count formally exceeds the decomposition threshold. However, all 10 ACs are state variations of a single controller action (create) and a single view (conditional rendering based on membership status + feature flag). Decomposing "valid code submission" from "invalid code handling" or "denied status display" would split one controller action into artificial sub-tickets with shared dependencies on the same route and view. The work is cohesive: 1 new action + 1 view rewrite + 1 route + 1 flag definition. No decomposition needed.

Recommendations

No action needed.

Verdict: READY

Re-review of board item #1901. All three issues from the prior NEEDS_REFINEMENT review have been resolved. Scope is solid, file targets verified, traceability complete.

Template Completeness

• [x] Type — Feature
• [x] Lineage — depends on #303
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — crew lead/admin wants newest-activity-first
• [x] Context — explains current oldest_first behavior and desired MAX(created_at) sort
• [x] File Targets — 4 modify targets, 2 do-not-touch targets
• [x] Feature Flag — gated by comment_threads from #303
• [x] Acceptance Criteria — 5 testable criteria
• [x] Test Expectations — 2 unit tests + bundle exec rspec
• [x] Constraints — dependency ordering, N+1 avoidance, reply sort preserved
• [x] Checklist — standard PR/tests/no-unrelated
• [x] Related — project + #303 dependency

Traceability

• [x] story:comments label — "Threaded discussion on property detail pages with photo attachments, reply threads, and activity-based sort"
• [x] story note verified — found in project-landscaping-assistant user-stories section; entry explicitly lists #304 as a child ticket
• [x] arch:rails-app label — shared Rails app deployment pattern
• [x] arch note verified — arch-rails-app note exists and is active
• [x] Forgejo issue — ldraney/landscaping-assistant#304, state: open

File Targets

• [x] app/models/property_comment.rb — verified: has oldest_first scope at line 17, no threading code yet (correct, depends on #303)
• [x] app/views/properties/show.html.erb — verified: renders @comments at lines 65-80
• [x] app/controllers/properties_controller.rb — verified: loads comments with oldest_first at line 79, includes eager loading for crew_member, service_request, photos
• [x] app/views/property_comments/create.turbo_stream.erb — verified: uses turbo_stream.append at line 3, ticket correctly describes need for conditional prepend/append

Repo Placement

OK — issue filed on ldraney/landscaping-assistant, all file targets in same repo. Single-repo change.

Dependencies

• #303 (threaded replies) — hard dependency, documented in both Lineage and Constraints. Introduces parent_id column and comment_threads feature flag that this ticket requires. #303 is board item #1900, currently in backlog. #303 also lists #304 as downstream in its Dependencies section. Mutual awareness confirmed.
• Board ordering — both #303 and #304 are in backlog. Board workflow must move #303 to done before #304 moves to in_progress.

Acceptance Criteria

All 5 criteria are agent-verifiable:

• AC 1-3: testable via unit tests with controlled timestamps — scope returns correct order
• AC 4: testable by toggling comment_threads flag and asserting fallback to oldest_first
• AC 5: testable by checking turbo stream response for prepend vs append action

Test command bundle exec rspec matches the arch-rails-app CI pipeline (Woodpecker runs rspec).

Blast Radius

Low. oldest_first scope is only referenced in two places: the model definition (line 17) and the properties controller (line 79). No other controllers, views, or models reference this scope. Comment sort is isolated to the property detail page. No downstream consumers affected.

Decomposition Assessment

No decomposition needed:

• 4 file targets in 1 repo — under threshold
• 5 acceptance criteria — at boundary, acceptable
• Estimated agent time: ~3-4 minutes (add scope, update controller, update view reference, adjust turbo stream) — within 5-minute rule
• 2 story points — appropriately sized

Prior Review Issues — Resolution Status

1. story:comments label had no backing user story — RESOLVED: "comments" entry now exists in project-landscaping-assistant user-stories section with key "comments", role "All roles", and explicit child reference to #304
2. Wrong test command (rails test vs bundle exec rspec) — FIXED: issue body now reads bundle exec rspec
3. Missing file target for create.turbo_stream.erb — FIXED: file target now listed with conditional prepend/append guidance matching comment_threads flag state

Recommendation

No action needed. Ticket is ready to move to todo once #303 (threaded replies) has progressed.

Verdict: APPROVED

Re-review of board item #1899 — ldraney/landscaping-assistant#302. All 7 issues from the first review (review-1899-2026-07-25, verdict NEEDS_REFINEMENT) have been addressed. The issue body now accurately reflects the codebase state, all required template sections are present, and traceability is complete.

Template Completeness

• [x] Type — Bug
• [x] Lineage — "Standalone — discovered during usage session."
• [x] Repo — ldraney/landscaping-assistant
• [x] What Broke — present (titled "What happened")
• [x] Repro Steps — present (titled "Steps to reproduce")
• [x] Expected Behavior — present, correctly notes photo upload feature IS implemented
• [x] Environment — present: iOS turbo-ios wrapper (primary), web browser (secondary), crash reports noted
• [x] Investigation Notes — present, accurately documents the full photo stack (model, view, controller, feature flag)
• [x] File Targets — present, split by repo with cross-repo dependency noted
• [x] Blast Radius — present, documents weeks/index.html.erb:33
• [x] Acceptance Criteria — present, 5 ACs focused on crash fix
• [x] Test Expectations — present with manual test steps and bundle exec rspec
• [x] Constraints — present
• [x] Checklist — present
• [x] Related — present

Traceability

• [x] story:comments label — present on board item
• [x] story note verified — "comments" entry found in project-landscaping-assistant user-stories section: "Threaded discussion on property detail pages with photo attachments, reply threads, and activity-based sort." References #302 as child of umbrella #303.
• [x] arch:rails-app label — present on board item
• [x] arch note verified — arch-rails-app note exists and is active in pal-e-docs
• [x] Forgejo issue — ldraney/landscaping-assistant#302, state: open

File Targets

• [x] app/views/property_comments/_form.html.erb — verified: line 8 has <input type="file" name="property_comment[photos][]" multiple accept="image/*"> gated by feature_enabled?(:photo_uploads) at line 5. Issue accurately describes this.
• [x] app/controllers/property_comments_controller.rb — verified: line 17 has @comment.photos.attach(comment_params[:photos]) if feature_enabled?(:photo_uploads) && comment_params[:photos].present?. Strong params permit photos: [] at line 45. Issue accurate.
• [x] app/models/property_comment.rb — verified: line 12 has has_many_attached :photos. ALLOWED_CONTENT_TYPES, MAX_FILE_SIZE (20MB), MAX_PHOTOS (5) all present. Issue accurate.
• [x] app/views/weeks/index.html.erb:33 (blast radius) — verified: line 33 has <input type="file" name="upload[photo]" accept="image/*"> with Stimulus upload controller.
• [x] iOS repo (ldraney/landscaping-assistant-ios) — cross-repo dependency clearly documented. Specific files to investigate listed: Info.plist, WKWebView config, turbo-ios session config.
• [x] lib/tasks/feature_flags.rake line 12 — verified: photo_uploads flag seeded enabled: true.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant (Rails). Cross-repo dependency with ldraney/landscaping-assistant-ios is clearly documented in File Targets and Acceptance Criteria. AC #5 explicitly requires a linked PR in the iOS repo if changes are needed there.

Dependencies

No blocking dependencies. No items in in_progress column. Related board items in backlog:

• #1900 — backlog, type:feature, story:comments (sibling under umbrella #303)
• #1901 — backlog, type:feature, story:comments (sibling under umbrella #303)
• #1405 — backlog, "Property comments: timestamped discussion for all roles" (parent feature)

Acceptance Criteria

5 ACs, all verifiable:

• AC1: No crash on "Add photos" — manual test on iOS, clear pass/fail
• AC2: No crash on "Upload Schedule" (blast radius) — manual test on iOS, clear pass/fail
• AC3: Photo uploads end-to-end — manual test: select, submit, verify display
• AC4: Crash reports examined and root cause documented — verifiable in PR body
• AC5: Cross-repo PR if iOS changes needed — verifiable by checking for linked PR

Test Expectations section provides manual test steps and bundle exec rspec for automated suite.

Blast Radius

Correctly documented. app/views/weeks/index.html.erb:33 uses the same accept="image/*" pattern on a file input. AC #2 explicitly covers this. The Stimulus controller (data-action="change->upload#submit") on the schedule upload may behave differently but the underlying <input type="file"> trigger is identical.

Decomposition Assessment

3 Rails file targets (investigation, not modification) + iOS cross-repo dependency. 5 acceptance criteria (at threshold, not over). Core work is focused: examine crash reports, identify root cause in turbo-ios/WKWebView layer, fix. Single agent pass is feasible (<5 min for the Rails-side investigation; iOS fix may extend but is scoped by AC #5 to a linked PR). No decomposition needed.

First Review Issues — Verification

Recommendation

No action needed. Ticket is ready for development.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, discovered during property details UX review
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — well-formed (crew lead / admin wants threaded replies)
• [x] Context — detailed background on flat comment problem
• [x] File Targets — 8 modify/create targets + 2 exclusions
• [x] Feature Flag — comment_threads, global, disabled by default, all roles, removal after 2 weeks
• [x] Acceptance Criteria — 7 items
• [x] Test Expectations — 4 items + run command
• [x] Constraints — 3 constraints documented
• [x] Checklist — present
• [x] Related — present
• [x] Dependencies — present (extra section, not in template but valuable)

All required template sections present. No gaps.

Traceability

• [x] story:comments label — "Threaded discussion on property detail pages with photo attachments, reply threads, and activity-based sort"
• [x] story note verified — found in project-landscaping-assistant user-stories section. Entry lists #303 as umbrella issue with children #302 and #304.
• [x] arch:rails-app label — shared Rails app deployment pattern
• [x] arch note verified — arch-rails-app note exists in pal-e-docs (architecture note, status: active)
• [x] Forgejo issue — ldraney/landscaping-assistant#303, state: open

All three traceability legs verified with backing notes.

File Targets

• [x] db/migrate/xxx_add_parent_id_to_property_comments.rb — new file (migration to create), expected not to exist yet
• [x] app/models/property_comment.rb — verified: currently has belongs_to :property, :crew_member, :service_request. No parent reference. Correct starting state.
• [x] app/views/property_comments/_comment.html.erb — verified: renders flat <li> items with comment-item class, author name, timestamp, service request badge, body, and photos
• [x] app/views/property_comments/_form.html.erb — verified: posts to property_property_comments_path, no parent_id field present
• [x] app/controllers/property_comments_controller.rb — verified: permits only :body and photos:[]. Needs parent_id added to permitted params.
• [x] app/views/properties/show.html.erb — verified: line 68-71 renders all @comments in comments-list ul without filtering
• [x] app/views/property_comments/create.turbo_stream.erb — verified: appends all new comments to comments-list. Issue correctly identifies this needs conditional targeting for replies.
• [x] app/controllers/properties_controller.rb line 79 — verified: exact match. Line 79 is @comments = @property.property_comments.oldest_first.includes(:crew_member, :service_request).with_attached_photos. No parent_id filtering. Issue description accurate.

All 8 file targets verified. Every existing file exists and contains exactly what the issue describes. Line references are accurate.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. No cross-repo concerns.

Dependencies

• #302 (board item #1899) — Bug: camera photo on property comments crashes the app. Column: backlog, type:bug, story:comments, 3 points. Touches same views (_comment.html.erb, _form.html.erb). Merge order coordination documented in issue. No hard blocker but merge conflict risk.
• #304 (board item #1901) — Sort comments by most recent activity. Column: backlog, type:feature, story:comments, 2 points. Depends on parent_id column from this ticket. Must land after #303. Correctly sequenced.

Dependencies are documented and correctly identified. Neither blocks #303 from starting, but #302 should ideally land first to avoid view conflicts.

Acceptance Criteria

7 acceptance criteria, all concrete and agent-verifiable:

• AC 1-5: testable via model scopes, view rendering, and validation checks
• AC 6: testable via Turbo Stream response inspection (integration test)
• AC 7: testable via feature flag toggle (existing feature_enabled? infrastructure confirmed in codebase)

Test expectations align with AC. Run command bundle exec rspec is correct for this Rails project. Feature flag infrastructure exists (FeatureFlag model, platform controller, feature_enabled? helper already used in comment views).

Blast Radius

Contained. PropertyComment is referenced in:

• property.rb (has_many :property_comments) — no change needed
• crew_member.rb (has_many :property_comments) — no change needed
• profile_controller.rb — references in comments only (lines 57, 61), no active code

No threading/parent_id/reply code exists anywhere in the codebase. Clean greenfield addition. No downstream consumers beyond the views already listed in file targets.

Decomposition Assessment

• File targets: 8 files in 1 repo — does not trigger cross-repo threshold (>3 files across >2 repos)
• Acceptance criteria: 7 — exceeds >5 threshold
• Estimated agent work: migration + model associations + model validation + controller params + 3 view templates + feature flag wiring + tests = estimated 10-15 minutes — exceeds 5-minute threshold

NEEDS DECOMPOSITION — 7 AC and estimated work time both exceed thresholds. Suggested split:

• Sub-ticket A (backend): migration, model (associations + validation + scope), controller (permit parent_id, scope reply creation), feature flag registration. AC: 1, 5, 7. ~5 min.
• Sub-ticket B (frontend): _comment.html.erb (reply link, nested rendering), _form.html.erb (parent_id hidden field), show.html.erb (top-level filter), create.turbo_stream.erb (conditional targeting). AC: 2, 3, 4, 6. ~5 min. Depends on Sub-ticket A.

Recommendation

• [DECOMPOSE] 7 AC across 8 files, estimated 10-15 min agent work. Route to skill-decompose-ticket. Suggested split: backend (migration + model + controller + flag) and frontend (views + turbo stream).

Verdict: READY

Re-review. First review returned NEEDS_REFINEMENT with 5 issues. All 5 have been addressed. Full re-review passes.

Prior Issues Resolved

• [x] File Targets updated to mention both Directions links (line 32 and line 58)
• [x] Board label corrected to story:property-crud
• [x] Lineage section added: "Standalone -- discovered during usage session."
• [x] Environment section added: "iOS turbo-ios wrapper + web browser."
• [x] Test command changed from rails test to bundle exec rspec

Template Completeness

• [x] Type -- Bug
• [x] Lineage -- "Standalone -- discovered during usage session."
• [x] Repo -- ldraney/landscaping-assistant
• [x] What Broke -- present as "What happened" (describes webview sheet behavior)
• [x] Repro Steps -- present as "Steps to reproduce" (4 steps)
• [x] Expected Behavior -- present
• [x] Environment -- "iOS turbo-ios wrapper + web browser."
• [x] Acceptance Criteria -- 3 criteria, reasonable
• [x] Related -- present

Extra sections present (not in bug template but useful): Investigation notes, File Targets, Test Expectations, Constraints, Checklist.

Traceability

• [x] story:property-crud label -- verified in project-landscaping-assistant user-stories section ("Add/edit/delete client properties")
• [x] story note verified -- found in project-landscaping-assistant user-stories table
• [x] arch:rails-app label -- arch-rails-app note verified in pal-e-docs
• [x] arch:ios label -- arch-ios note verified in pal-e-docs
• [x] Forgejo issue -- ldraney/landscaping-assistant#305, open

File Targets

• [x] app/views/properties/show.html.erb -- verified: file exists. Line 32: Directions link inside feature_enabled?(:address_detection) branch. Line 58: Directions link in else branch. Both match issue description exactly.
• [x] app/models/property.rb -- verified: maps_url method at line 58, correctly marked as DO NOT TOUCH.
• [x] turbo-ios path configuration -- correctly noted as "(if it exists)". Option 2 (data-turbo="false") keeps fix entirely in the Rails repo.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, fix is in same repo. Option 2 avoids cross-repo work.

Dependencies

No blockers found. Active board items (#1683 next_up: iOS pipeline bug, #1756 todo: multi-tenancy seed data) are unrelated. This ticket is standalone.

Acceptance Criteria

3 ACs -- reasonable scope. Two require manual iOS testing. Regression check covered by bundle exec rspec. Test command is correct.

Blast Radius

Only one other target="_blank" link exists: app/views/property_comments/_comment.html.erb:15 (photo attachment via rails_storage_proxy_path). This is an internal URL -- opening a photo in a modal/sheet is expected turbo-ios behavior. Not affected by this bug. No existing data-turbo attributes in any view templates. Blast radius is limited to the two Directions links in show.html.erb.

Decomposition Assessment

1 file target in 1 repo (2 link instances in the same file). 3 acceptance criteria. Estimated agent work: under 5 minutes (add data: { turbo: false } to two link_to calls). No decomposition needed.

Recommendation

No action needed. All prior issues resolved. Ticket is ready for implementation.

Verdict: NEEDS_REFINEMENT

Board item #1899 — ldraney/landscaping-assistant#302. The issue body contains factually incorrect investigation notes that contradict the actual codebase. Photo support on property comments is fully implemented and wired up behind the photo_uploads feature flag (seeded enabled). The scope needs to be corrected before an agent can work on this.

Template Completeness

• [x] Type — Bug
• [ ] Lineage — MISSING (required by template-issue-bug)
• [x] Repo — ldraney/landscaping-assistant
• [x] What Broke — present (titled "What happened")
• [x] Repro Steps — present (titled "Steps to reproduce")
• [x] Expected Behavior — present (titled "Expected behavior")
• [ ] Environment — MISSING (no cluster/namespace, iOS version, crash report references, service version)
• [x] Acceptance Criteria — present but assumptions are wrong (see below)
• [x] Related — present

Traceability

• [x] story:comments label — present on board item
• [ ] story note MISSING — [SCOPE] "comments" is not listed in the project-landscaping-assistant user-stories section. The existing stories are: address-lookup, property-crud, service-tracking, special-notes, work-queue, weekly-tracking, schedule-upload, auth, multi-tenancy, custom-domain, app-store-submission, ci-performance. Create user story entry "comments" on project-landscaping-assistant user-stories section.
• [x] arch:rails-app label — Rails App (Shared Pattern)
• [x] arch note verified — arch-rails-app note exists and is active in pal-e-docs
• [x] Forgejo issue — ldraney/landscaping-assistant#302, state: open

File Targets

• [x] app/views/property_comments/_form.html.erb — verified EXISTS. However, issue claims "no file input or camera capture element." This is WRONG. Line 5-11: file input <input type="file" name="property_comment[photos][]" multiple accept="image/*"> exists, gated by feature_enabled?(:photo_uploads).
• [x] app/controllers/property_comments_controller.rb — verified EXISTS. Issue claims "no photo handling exists." This is WRONG. Line 17: @comment.photos.attach(comment_params[:photos]) handles photo attachment, gated by the same flag.
• [x] app/models/property_comment.rb — verified EXISTS. Issue claims "no attachment support." This is WRONG. Line 12: has_many_attached :photos. Model also has validation for content types (PNG, JPEG, WebP, HEIC/HEIF), max file size (20MB), and max 5 photos per comment.
• [ ] "iOS project files (turbo-ios config)" — ISSUE: Not in this repo. The iOS app lives in a separate repo: ldraney/landscaping-assistant-ios (per docs/ios-pipeline.md). This file target cannot be verified in the specified repo.

Repo Placement

Partial mismatch. The Forgejo issue is filed on ldraney/landscaping-assistant (Rails), and the ### Repo header says the same. However, the crash occurs in the iOS app (turbo-ios webview), and the root cause likely involves the iOS project at ldraney/landscaping-assistant-ios. If the fix requires iOS-side changes (e.g., NSCameraUsageDescription in Info.plist, or webview file input handling), a separate issue on ldraney/landscaping-assistant-ios may be needed. The issue should clarify whether the crash stack trace points to Rails (server-side error) or iOS (native crash).

Dependencies

Related board items on board-landscaping-assistant:

• #1900 — backlog, type:feature, story:comments (no title set — possibly related photo comments feature)
• #1901 — backlog, type:feature, story:comments (no title set — possibly related)
• #1405 — backlog, "Property comments: timestamped discussion for all roles" (parent feature)
• #1338 — backlog, "Per-property photos, project tracking, and photo optimization"

No blocking dependencies in in_progress. Items #1900 and #1901 have no titles, suggesting incomplete scoping of the comments story.

Acceptance Criteria

The acceptance criteria are based on incorrect assumptions about the codebase:

• "If photo comments aren't supported yet, camera option should not appear" — Photo comments ARE supported. The photo_uploads flag is seeded enabled: true and the full implementation exists (model, controller, view). This criterion should be rewritten.
• "If photo comments are supported, photo uploads save and display correctly" — Valid but broad. Should be scoped to the specific crash scenario (camera capture in turbo-ios webview vs. photo library selection).
• "App does not crash when interacting with comments on property details" — Valid but needs crash report context. Is this an iOS native crash (SIGABRT from missing camera permission) or a Rails 500?

An agent could not verify these criteria without knowing the root cause. The crash reports mentioned in the issue body are not attached or referenced.

Blast Radius

The same accept="image/*" pattern on a file input exists in app/views/weeks/index.html.erb:33 (schedule upload). If the crash is caused by how turbo-ios handles <input type="file" accept="image/*"> (triggering native camera picker without proper permission), the schedule upload feature may have the same crash. The schedule upload uses a Stimulus controller (data-action="change->upload#submit") which may or may not change the interaction.

Decomposition Assessment

3 file targets in this repo, 1 potential cross-repo target (iOS), 3 acceptance criteria. Single-repo fix could fit in one agent pass (<5 min). However, if the fix requires iOS-side changes, it becomes a cross-repo issue needing decomposition or a second issue on landscaping-assistant-ios. No decomposition needed at this time — fix the scope first, then reassess.

Recommendations

• [BODY] Rewrite Investigation Notes section: remove incorrect claims that photo support doesn't exist. Document the actual state: has_many_attached :photos on model, file input gated by photo_uploads flag (enabled), controller handles attachment. Refocus investigation on why the camera interaction crashes (iOS permission? ActiveStorage config? MinIO connectivity?).
• [BODY] Add Lineage section (required by bug template).
• [BODY] Add Environment section: include iOS version, turbo-ios version, cluster/namespace, and attach or reference the two crash reports mentioned in the body.
• [BODY] Fix file target: replace "iOS project files (turbo-ios config)" with the actual repo path ldraney/landscaping-assistant-ios and specify which files to check (e.g., Info.plist for NSCameraUsageDescription).
• [BODY] Rewrite Acceptance Criteria to reflect the actual codebase state. Focus on: (1) camera-triggered photo upload completes without crash, (2) photo library selection works, (3) schedule upload (weeks/index) does not exhibit the same crash.
• [SCOPE] Create user story entry "comments" on project-landscaping-assistant user-stories section. Suggested summary: "Per-property timestamped comments with optional photo attachments for all roles."
• [BODY] Note blast radius: same accept="image/*" pattern in schedule upload (app/views/weeks/index.html.erb:33) may have identical crash behavior.

Verdict: APPROVED

Re-review: Previous review returned NEEDS_REFINEMENT with one blocker -- missing arch-ci-pipeline architecture note. That note has now been created as arch-ci-pipeline-landscaping-assistant. All checks pass.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, references base-images commit bd8e4cd
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- Developer wants faster CI builds via pre-compiled gem reuse
• [x] Context -- Explains base image pre-compiles 21 gems, CI bypasses them with vendor/bundle path
• [x] File Targets -- .woodpecker.yaml identified
• [x] Feature Flag -- "none" (CI infra change, appropriate)
• [x] Acceptance Criteria -- 2 criteria
• [x] Test Expectations -- 1 expectation (CI pipeline passes)
• [x] Constraints -- Only modify bundle-install step
• [x] Checklist -- Standard 3-item checklist
• [x] Related -- References ldraney/base-images

Traceability

• [x] story:ci-performance label -- "CI pipelines reuse pre-compiled gems from base image for faster builds"
• [x] story note verified -- found in project-landscaping-assistant user-stories section (Key: ci-performance, Role: Developer, Summary: "CI pipelines reuse pre-compiled gems from base image for faster builds", Success Metric: "bundle-install step seeds from pre-baked gems, pipeline time reduced")
• [x] arch:ci-pipeline label -- CI pipeline component
• [x] arch note verified -- arch-ci-pipeline-landscaping-assistant exists in pal-e-docs (note_type: architecture, status: active, project: landscaping-assistant). Comprehensive note covering Woodpecker pipeline diagram, components table, key decisions, and related notes. Previous blocker resolved.
• [x] Forgejo issue -- ldraney/landscaping-assistant#299, open

File Targets

• [x] .woodpecker.yaml -- verified: file exists (88 lines), bundle-install step at lines 15-23 uses harbor.tail5b443a.ts.net/library/ruby-rails-build:latest image. Runs bundle config set --local path vendor/bundle at line 18 then bundle install --jobs=4 at line 19. The proposed seed line (cp -a /usr/local/bundle/. vendor/bundle/) should be inserted between lines 18 and 19.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, fix targets .woodpecker.yaml in the same repo. Single repo, no mismatch.

Dependencies

• Pre-req: ldraney/base-images commit bd8e4cd (pre-baked gems) -- already merged
• Related done items: #1297 (cache bundle install, issue #60), #1261 (Harbor base image + registry URL, issue #23), #1364 (CI Postgres audit, issue #138), #1298 (Woodpecker agent scaling, issue #62), #1415 (Kaniko push incident, issue #199)
• No CI-related items in in_progress, todo, or next_up columns -- no blockers
• Pattern validated: identical change already landed in intelligentstaffingsystems PR #91

Acceptance Criteria

2 criteria, both CI-verifiable: (1) bundle-install step seeds from base image, (2) pipeline passes. An agent can verify both by reading the diff and observing pipeline status. Testable and complete.

Blast Radius

• Single file change to .woodpecker.yaml
• The lint and test steps also use vendor/bundle and depend on bundle-install, so they benefit from the seeded gems transitively
• docker-compose.yml and Dockerfile use /usr/local/bundle for dev and prod respectively -- unaffected by this CI-only change
• Other repos (e.g., westside-basketball) have the same bundle install + vendor/bundle pattern without a seed step -- they would benefit from the same change but are correctly out of scope for this ticket

Decomposition Assessment

1 file target, 1 repo, 2 acceptance criteria, estimated agent work under 2 minutes. No decomposition needed.

Recommendation

No action needed.

Verdict: APPROVED

Re-review of board item #1756. Prior review review-1756-2026-07-04 gave NEEDS_REFINEMENT with two [SCOPE] recommendations. Both have been addressed.

Prior Findings Resolution

• [x] story note -- "multi-tenancy" entry now exists in project-landscaping-assistant user-stories section. Row: Key=multi-tenancy, Role=Platform owner, Summary=Business model with row-level property isolation, Success Metric references #282/#294/#295/#296.
• [x] arch note -- arch-rails-app note confirmed to exist in pal-e-docs (found in note listing).

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- sub-ticket 3 of #282, depends on #294 and #295
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- developer wants realistic test business data
• [x] Context -- explains Business model and controller scoping dependencies
• [x] File Targets -- 1 file to create, 0 to modify, exclusions listed
• [x] Feature Flag -- consumes multi_tenancy from #294, no new flag
• [x] Acceptance Criteria -- 6 criteria
• [x] Test Expectations -- rake task specs + manual verification
• [x] Constraints -- no real data, use existing services, idempotent
• [x] Checklist -- standard PR/tests/no-unrelated
• [x] Related -- parent #282, dependencies #294, #295

Traceability

• [x] story:multi-tenancy label -- present on board item
• [x] story note verified -- "multi-tenancy" entry found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label -- present on board item
• [x] arch note verified -- arch-rails-app note exists in pal-e-docs
• [x] Forgejo issue -- #296, open, valid

File Targets

• [x] lib/tasks/test_business_seed.rake -- to be created. Does not exist yet (confirmed). Directory lib/tasks/ exists with existing rake tasks (crew.rake, feature_flags.rake) that follow the same find_or_create_by! pattern.
• [x] db/seeds.rb -- correctly listed as NOT to touch. Contains existing seed data (8 properties, Mowing/Weeding/Edging & Trimming/Sprinklers services).

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all work is in the same repo. Single-repo change.

Dependencies

• #294 (Business model, board item 1754) -- backlog. HARD DEPENDENCY. Creates Business model and business_id column on Property.
• #295 (controller scoping, board item 1755) -- backlog. SOFT DEPENDENCY. Seed data validates scoping, but rake task itself doesn't need controller changes.
• #282 (parent epic, board item 1662) -- backlog.
• All dependencies documented in issue Lineage and Related sections.
• The multi_tenancy feature flag does not exist in the codebase yet; will be created by #294.

Acceptance Criteria

6 criteria, all testable by an agent:

• AC1: Create business with slug "greenview-landscaping" -- verifiable
• AC2: ~15 properties with service combos -- references existing services confirmed in db/seeds.rb
• AC3: ~20 work_queue_items with varied completion -- verifiable with count
• AC4: Distinguishable names ("Greenview -" prefix, fictional streets) -- verifiable
• AC5: Idempotent via find_or_create_by! -- consistent with existing rake task patterns
• AC6: Logging output -- verifiable

Blast Radius

• Low risk. Standalone rake task creating test data. No modifications to existing code.
• References existing models (Property, Service, WorkQueueItem) plus Business model from #294.
• Existing db/seeds.rb uses WorkQueueItem.delete_all; the new task correctly avoids touching it.
• No downstream consumers affected. Test data namespaced under "Greenview Landscaping".

Decomposition Assessment

• 1 file to create, 0 to modify -- below threshold
• 6 acceptance criteria -- slightly above 5-AC threshold but all are simple data-creation assertions
• Single repo -- below threshold
• Estimated agent work: ~3-4 minutes
• No decomposition needed.

Recommendation

No action needed. All prior refinement items have been resolved. Ticket is ready for implementation (after dependencies #294 and #295 are complete).

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- sub-ticket 3 of #282, depends on #294 and #295
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- developer wants realistic test business data
• [x] Context -- explains Business model and controller scoping dependencies
• [x] File Targets -- 1 file to create, 0 to modify, exclusions listed
• [x] Feature Flag -- consumes multi_tenancy from #294, no new flag
• [x] Acceptance Criteria -- 6 criteria
• [x] Test Expectations -- rake task specs + manual verification
• [x] Constraints -- no real data, use existing services, idempotent
• [x] Checklist -- standard PR/tests/no-unrelated
• [x] Related -- parent #282, dependencies #294, #295

Traceability

• [x] story:multi-tenancy label -- present on board item
• [ ] story note MISSING -- no "multi-tenancy" entry in project-landscaping-assistant user-stories section. Existing stories: address-lookup, property-crud, service-tracking, special-notes, work-queue, weekly-tracking, schedule-upload, auth, custom-domain, app-store-submission. [SCOPE] Create user story entry on project-landscaping-assistant
• [x] arch:rails-app label -- present on board item
• [ ] arch note MISSING -- search for "arch-rails-app" returned no results in pal-e-docs. [SCOPE] Create architecture note arch-rails-app
• [x] Forgejo issue -- #296, open, valid

File Targets

• [x] lib/tasks/test_business_seed.rake -- to be created. Does not exist yet (confirmed). Directory lib/tasks/ exists with existing rake tasks (crew.rake, feature_flags.rake) that follow the same find_or_create_by! pattern.
• [x] db/seeds.rb -- correctly listed as NOT to touch. Verified it contains the existing seed data (8 properties, service records for Mowing, Weeding, Edging & Trimming, Sprinklers).

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all work is in the same repo. Single-repo change, no cross-repo concerns.

Dependencies

• #294 (Business model, board item 1754) -- backlog. HARD DEPENDENCY. This ticket creates the Business model and business_id column on Property. The seed task cannot set business_id on properties until this migration exists.
• #295 (controller scoping, board item 1755) -- backlog. SOFT DEPENDENCY. The seed data validates that scoping works, but the rake task itself doesn't need controller changes to run.
• #282 (parent epic, board item 1662) -- backlog.
• All three dependencies are documented in the issue's Lineage and Related sections.
• The multi_tenancy feature flag referenced in the Feature Flag section does not exist in the codebase yet (no hits for "multi_tenancy" in app/, lib/, config/, spec/). It will be created by #294.

Acceptance Criteria

6 criteria, all testable by an agent:

• AC1: Create business with specific slug -- straightforward, verifiable with Business.find_by(slug: "greenview-landscaping")
• AC2: ~15 properties with services -- references existing services (Edging & Trimming, Mowing, Weeding, Sprinklers) which are confirmed in db/seeds.rb
• AC3: ~20 work_queue_items -- verifiable with count
• AC4: Distinguishable names -- "Greenview -" prefix pattern, fictional streets. Existing seed data uses generic names (Johnson, Smith, etc.), so distinction is achievable.
• AC5: Idempotent -- find_or_create_by! pattern, consistent with crew.rake and db/seeds.rb
• AC6: Logging output -- verifiable

Blast Radius

• Low risk. Standalone rake task that creates test data. No modifications to existing code.
• References models (Property, Service, WorkQueueItem) that exist today, plus Business model that will be created by #294.
• The existing db/seeds.rb uses WorkQueueItem.delete_all on line 38. The new rake task correctly avoids touching db/seeds.rb, preventing conflict with its destructive reset pattern.
• No downstream consumers affected. Test data is clearly namespaced under "Greenview Landscaping".

Decomposition Assessment

• 1 file to create, 0 to modify -- below threshold
• 6 acceptance criteria -- slightly above the 5-AC threshold, but the criteria are simple data-creation assertions, not complex logic
• Single repo -- below threshold
• Estimated agent work: ~3-4 minutes
• No decomposition needed.

Recommendation

• [SCOPE] Create user story entry "multi-tenancy" on project-landscaping-assistant user-stories section. Suggested row: Key=multi-tenancy, Role=All roles, Summary=Isolate business data so each landscaping company sees only its own properties/crew/queue, Success Metric=Properties/work-queue scoped to current_business; seed second business verifies isolation.
• [SCOPE] Create architecture note arch-rails-app for the Rails application component. This is a systemic gap affecting all board items with the arch:rails-app label.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [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:auth label -- "Log in with Keycloak, see role-appropriate tabs and features"
• [x] story note verified -- found in project-landscaping-assistant user-stories section
• [ ] story:auth is a loose fit -- multi-tenancy is about data isolation and business scoping, not authentication. [SCOPE] Consider creating a dedicated "multi-tenancy" user story entry on project-landscaping-assistant.
• [x] arch:rails-app label
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-rails-app for the Rails app component. No matching note found via search.
• [x] Forgejo issue -- ldraney/landscaping-assistant#282, open

File Targets

• [x] app/models/property.rb -- verified exists, has no current business association
• [x] app/controllers/application_controller.rb -- verified exists, contains feature_enabled? and find_property_or_reject (unscoped Property.find_by)
• [x] app/controllers/properties_controller.rb -- verified exists, has unscoped Property.by_proximity, Property.find, Property.create!
• [x] app/controllers/work_queue_items_controller.rb -- verified exists, has unscoped Property.active, Property.create!, Property.nearest_to
• [x] app/controllers/weeks_controller.rb -- verified exists, has unscoped Property.by_proximity(Property.active)
• [x] lib/tasks/feature_flags.rake -- verified exists, no multi_tenancy flag yet
• [x] config/initializers/omniauth.rb -- verified exists (do-not-touch, correct)
• [x] docs/app-architecture.md -- verified exists, already describes Business and UserBusiness under "Planned" section (do-not-touch, correct)
• [ ] app/controllers/days_controller.rb -- MISSING from file targets. Has 3 unscoped Property queries: Property.active.order(:client_name), .joins(:property).merge(Property.active), Property.active.where(id:). [BODY] Add to file targets.
• [ ] app/controllers/property_comments_controller.rb -- MISSING from file targets. Has unscoped Property.find(params[:property_id]). [BODY] Add to file targets.
• [ ] New files (migrations, models, seed task) -- cannot verify, will be created. Paths look correct for Rails conventions.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in that repo. PR 2 (Keycloak role migration) is deferred to a separate ticket, which is appropriate since it may touch Keycloak config in pal-e-services.

Dependencies

• #118 (Onboarding flow, solo-to-business transition) -- backlog, story:auth, phase:4. This ticket is a prerequisite for #118. Not documented in the issue's Related section as a dependency direction (only says "Related to #118").
• #262 (Crew/team grouping) -- backlog, story:auth. Related but not a hard dependency. Crew grouping may need to integrate with the Business model. Documented in issue.
• No items in in_progress or next_up that block or are blocked by this ticket.
• PR 2 (UserBusiness roles) is an explicit follow-up dependency, correctly deferred to a separate ticket.

Acceptance Criteria

PR 1 has 12 acceptance criteria (7 model/scoping + 5 seed data). PR 2 has 3 AC but is deferred to a separate ticket. Individual AC items are testable and specific. The test expectations section lists 6 concrete specs with a run command. However:

• Missing test for days_controller scoping (not in file targets, not in test expectations)
• Missing test for property_comments_controller scoping
• The AC "Property queries scoped to current_business when multi_tenancy flag is ON" is broad -- which controllers specifically?

Blast Radius

• days_controller.rb -- 3 unscoped Property queries, not listed in file targets. Day detail pages would show cross-business properties without scoping.
• property_comments_controller.rb -- unscoped Property.find, not listed. Could allow commenting on another business's property.
• profile_controller.rb -- uses owner_sub scoping, not business scoping. Likely acceptable for PR 1 since owner_sub uniquely identifies the user, but account deletion (Property.where(owner_sub:).destroy_all) might need business-awareness in PR 2.
• find_property_or_reject in application_controller.rb -- used by weeks_controller toggle_assign. Unscoped Property.find_by(id:). Listed in targets, but the description only says "current_business helper" -- should also note scoping this method.

Decomposition Assessment

NEEDS DECOMPOSITION -- route to skill-decompose-ticket.

• 12 file targets in 1 repo -- below the cross-repo threshold but high file count
• 12 AC items for PR 1 -- exceeds the 5 AC threshold
• Estimated agent work: 15-20 minutes (3 migrations, 2 new models, 1 new rake task, scoping across 5+ controllers, feature flag, 6+ test files)

Suggested decomposition:

1. Sub-ticket A: Business model + migrations + feature flag -- Create Business, UserBusiness models, add business_id FK to properties, data migration, register multi_tenancy feature flag. ~5 AC.
2. Sub-ticket B: Property scoping + controller updates -- current_business helper, scope all Property queries in properties/work_queue_items/weeks/days/property_comments controllers behind flag. ~4 AC.
3. Sub-ticket C: Test business seed data -- Seed rake task for Greenview Landscaping with realistic properties and work_queue_items. ~5 AC.

Recommendation

• [BODY] Add missing file target: app/controllers/days_controller.rb (3 unscoped Property queries)
• [BODY] Add missing file target: app/controllers/property_comments_controller.rb (unscoped Property.find)
• [BODY] Clarify which controllers are covered by "Property queries scoped to current_business" AC
• [SCOPE] Create architecture note arch-rails-app for the Rails app component
• [SCOPE] Consider creating a dedicated "multi-tenancy" user story entry on project-landscaping-assistant (story:auth is a loose fit for data isolation work)
• [DECOMPOSE] 12 AC across model/scoping/seed, estimated 15-20 min agent work. Split into 3 sub-tickets: (A) models+migrations+flag, (B) controller scoping, (C) seed data. Route to skill-decompose-ticket.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Child of #107
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- present
• [x] Context -- present (detailed)
• [x] File Targets -- present but marked "TBD"
• [ ] Feature Flag -- MISSING (required for Feature type)
• [x] Acceptance Criteria -- present (12 items)
• [x] Test Expectations -- present
• [x] Constraints -- present
• [x] Checklist -- present
• [x] Related -- present

Traceability

• [x] story:auth label -- "Auth: Log in with Keycloak, see role-appropriate tabs and features"
• [x] story note verified -- found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label -- present on board item
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-rails-app for the Rails app component
• [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant/issues/118, open

File Targets

• [x] app/controllers/registrations_controller.rb (new) -- does not exist yet, OK
• [x] app/controllers/business_requests_controller.rb (new) -- does not exist yet, OK
• [x] app/models/business.rb (new) -- does not exist yet, OK
• [x] app/models/property.rb -- verified: exists, has_many associations, scope :owned_by, no business_id yet
• [x] app/models/user_business.rb (new) -- does not exist yet, OK
• [x] app/views/sessions/new.html.erb -- verified: exists
• [x] app/controllers/activity_feed_controller.rb (new) -- does not exist yet, OK
• [ ] app/models/property_comment.rb -- ISSUE: listed as "(new)" but already exists. Has belongs_to :property, belongs_to :crew_member, photo attachments (up to 5 photos), body validation. Crew can already post comments with photos on properties.
• [ ] app/controllers/join_crew_controller.rb -- ISSUE: exists in codebase (empty controller) but not mentioned in file targets. Directly relevant to "join business" flow.

Repo Placement

Issue filed on ldraney/landscaping-assistant -- correct for the Rails app work. However, cross-repo work is not explicitly scoped:

• Keycloak self-registration may require realm config changes (pal-e-services or keycloak-theme repo)
• Telegram alert routing is in pal-e-platform (PR #410 mentioned in constraints)
• Multiple repos affected but no separate Forgejo issues planned for non-Rails work

Dependencies

• #107 (parent auth issue) -- referenced, not on board
• #115 / #1337 (Phase 1: Keycloak login) -- done
• #117 / #1339 (Crew tab) -- done
• #1403 (Property detail: Projects section) -- in todo, also story:auth phase:3. Potential ordering dependency.
• #1574 (Crew/team grouping) -- in backlog. Title: "Crew/team grouping: model, scoping, controller updates, and digester integration". Significant overlap with this ticket's business/crew model concepts. Relationship not documented.

Acceptance Criteria

12 acceptance criteria. Assessment:

• AC 1-7, 9-12: testable via request specs
• AC 8: "Properties created while solo are preserved (exact handling TBD)" -- NOT TESTABLE. Contains explicit TBD. Must specify exact behavior (archive, transfer, or hide) before implementation.
• AC 10: "Crew can post questions and photos on properties" -- partially already implemented (PropertyComment model exists with photo support). Needs clarification on what's new vs existing.
• AC 5: "Business admin receives Telegram alert" -- testable but cross-system, requires pal-e-platform integration

Blast Radius

• Property model multi-tenancy: Adding business_id to Property affects ALL property queries. Current scoping uses owned_by(sub) (Keycloak subject). Switching to business_id-based scoping touches: properties_controller, work_queue_items_controller, weeks_controller, days_controller, uploads_controller, and all property-dependent views.
• Role system: Current role enforcement uses Keycloak realm roles (member, lead, admin, super_admin) via ApplicationController#require_role. The "solo" concept (user is their own admin) has no current analog. Tab visibility is hardcoded in TAB_ROLES constant.
• Existing crew model: CrewMember model already exists and is used for property comments. The new UserBusiness join table concept may conflict or need to integrate with existing CrewMember associations.

Decomposition Assessment

NEEDS DECOMPOSITION -- exceeds all thresholds:

• 9+ file targets across 3+ repos (landscaping-assistant, keycloak/pal-e-services, pal-e-platform)
• 12 acceptance criteria (threshold: 5)
• Estimated agent work: days, not minutes
• The issue itself states: "This ticket is a planning/umbrella ticket -- break into sub-tickets before implementation"
• Checklist item "Sub-tickets created for each deliverable" is unchecked

Recommendations

• [BODY] Add Feature Flag section -- this multi-part feature needs a flag strategy (likely multiple flags: one for self-registration, one for business join, one for activity feed)
• [BODY] Fix property_comment.rb: listed as "(new)" but already exists with photo upload support. Clarify what's new vs existing.
• [BODY] AC #8: remove TBD -- must specify exact property transition behavior (archive, transfer, or hide) before implementation can begin
• [BODY] Add join_crew_controller.rb to file targets -- it already exists and is directly relevant to the "join business" flow
• [BODY] Document relationship with #1574 (Crew/team grouping) -- significant concept overlap needs resolution
• [BODY] Scope cross-repo work explicitly: Keycloak realm config changes, pal-e-platform Telegram integration
• [SCOPE] Create architecture note arch-rails-app for the Rails app component
• [DECOMPOSE] 12 AC across 9+ files and 3+ repos. Route to skill-decompose-ticket. Suggested sub-ticket breakdown: (1) Self-registration + Keycloak config, (2) Business model + multi-tenancy migration, (3) Join-business request flow + Telegram alert, (4) Role transition (solo-to-crew) + property scoping, (5) Activity feed for admin, (6) Tab layout updates

Verdict: APPROVED

Re-review of board item #1684. Previous review (review-1684-2026-07-03) returned NEEDS_REFINEMENT with 6 issues. All have been addressed.

Template Completeness

• [x] Type (Bug)
• [x] Lineage
• [x] Repo
• [x] What Broke
• [x] Repro Steps
• [x] Expected Behavior
• [x] Environment
• [x] Acceptance Criteria
• [x] Related

All required sections for the template-issue-bug template are present and complete.

Traceability

• [x] story:app-store-submission label -- "Submit and maintain iOS App Store listing (privacy declarations, review compliance, metadata)"
• [x] story note verified -- found in project-landscaping-assistant user-stories section
• [x] arch:keycloak label -- Keycloak infrastructure component
• [x] arch note verified -- arch-keycloak note exists in pal-e-docs (project: pal-enterprises)
• [x] Forgejo issue -- ldraney/landscaping-assistant#290, open

File Targets

• [x] keycloak-theme/landscaping/login/resources/css/login.css -- verified: exists (341 lines), #kc-register-form::before at line 122 (matches "line ~122"), #kc-registration selectors at lines 261, 273, 280
• [x] docs/keycloak-setup.md -- verified: exists, contains registration_allowed = true at line 74 with documentation at line 84
• [x] docs/app-store-review/2026-07-02-rejection-v1.0.md -- verified: exists in docs/app-store-review/ directory

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in this repo. Fix approach is CSS hide -- no Terraform changes needed in pal-e-services. Previous review flagged a repo placement mismatch; this has been corrected.

Dependencies

• #1683 (issue #289, backlog): App Store rejection -- privacy declarations (Guideline 5.1.2(i)). Same story:app-store-submission but different arch component (arch:ios-pipeline). Independent -- can be worked in parallel.
• #1685 (issue #291, backlog): Another app-store-submission feature item. Independent.
• No blocking dependencies. All three App Store rejection items (#1683, #1684, #1685) are independent and can be worked in any order.

Acceptance Criteria

5 criteria -- all agent-verifiable:

• [x] "No Register link/button visible" -- verifiable by CSS inspection of login.css
• [x] "Login flow works correctly on iPad" -- verifiable by testing login flow (iPad simulator or device)
• [x] "Existing login with demo credentials still works" -- verifiable by functional test
• [x] "docs/keycloak-setup.md updated" -- verifiable by reading doc content
• [x] "#kc-register-form::before styling cleaned up" -- verifiable by CSS inspection

All criteria are clear, testable, and complete. The doc update AC was added in response to previous review feedback.

Blast Radius

Low. #kc-registration and #kc-register-form selectors appear only in keycloak-theme/landscaping/login/resources/css/login.css. No other files reference them. The fix is purely visual CSS hiding -- no server-side changes, no Terraform modifications. Self-registration remains enabled at the realm level (registration_allowed = true), so the change is trivially reversible by removing the CSS rule.

Decomposition Assessment

No decomposition needed.

• File targets: 2 files to modify (login.css, keycloak-setup.md) in 1 repo
• AC count: 5 (within limit)
• Estimated agent work: <5 minutes (add one CSS rule, clean up another, update one doc section)

Previous Review Issues -- Resolution

1. Architectural conflict (self-registration vs disabling) -- RESOLVED: Fix changed from Terraform realm-level disable to CSS hide, keeping registration_allowed = true
2. Repo placement mismatch -- RESOLVED: All work now stays in landscaping-assistant repo, no pal-e-services changes
3. Missing ACs for doc updates -- RESOLVED: AC added for keycloak-setup.md update
4. Missing AC for CSS cleanup -- RESOLVED: AC added for #kc-register-form::before cleanup
5. story:app-store-submission user story -- RESOLVED: Entry exists in project-landscaping-assistant user-stories section
6. arch-keycloak note -- RESOLVED: arch-keycloak note exists in pal-e-docs

Recommendation

No action needed.

Verdict: READY

Re-review of board item #1683. Previous review (review-1683-2026-07-03) returned NEEDS_REFINEMENT citing two missing traceability notes. Both have now been created and verified.

Template Completeness

• [x] Type — Bug
• [x] Lineage — Standalone, discovered during App Store review of v1.0
• [x] Repo — ldraney/landscaping-assistant
• [x] What Broke — Clear description of over-declared privacy data categories
• [x] Repro Steps — 3 steps to reproduce in App Store Connect
• [x] Expected Behavior — Accurate mapping of data types to purposes
• [x] Environment — App Store Connect web UI, review device identified
• [x] Acceptance Criteria — 3 criteria
• [x] Related — References rejection doc

Traceability

• [x] story:app-store-submission label — present on board item
• [x] story note verified — found in project-landscaping-assistant user-stories section (key=app-store-submission, role=All roles, summary="Submit and maintain iOS App Store listing")
• [x] arch:ios-pipeline label — present on board item
• [x] arch note verified — arch-ios-pipeline note exists in pal-e-docs (project: landscaping-assistant, covers Xcode project, Fastlane, App Store Connect, TestFlight, signing)
• [x] Forgejo issue — ldraney/landscaping-assistant#289, open

File Targets

• [x] docs/app-store-review/2026-07-02-rejection-v1.0.md — verified: file exists (3.7k), contains full rejection details
• No code file targets — fix is in App Store Connect web UI, not in the codebase

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, which is the app this App Store submission belongs to. The fix is a metadata change in App Store Connect (web UI only), but filing on the app's repo is appropriate. No other repos affected.

Dependencies

Three sibling items from the same App Store rejection (all story:app-store-submission):

• Board #1683 (this item) — Guideline 5.1.2(i) privacy declarations (web UI fix)
• Board #1684 — Guideline 2.1(a) Keycloak register button error (arch:keycloak, code fix)
• Board #1685 — Guideline 5.1.1(v) account deletion (arch:rails-app, feature work)

All three must be resolved before App Store resubmission. They are independent of each other — no blocking relationship. No items in in_progress block this ticket. The only todo item (#1403, property detail page) is unrelated.

Acceptance Criteria

3 criteria, all clear and testable. All are manual-only (App Store Connect web UI). An agent cannot verify these programmatically — there is no API for App Store Connect privacy declarations. Acceptable for a web-UI-only metadata fix. A human must verify by inspecting the privacy page after updating.

Blast Radius

Minimal. No code changes involved. The fix only changes metadata in Apple's App Store Connect portal. No downstream code consumers, no API changes, no database changes. Privacy declarations are specific to this app.

Decomposition Assessment

No decomposition needed. 0 code file targets, 3 acceptance criteria, estimated completion time well under 5 minutes. Manual web UI task.

Recommendation

No action needed. Previous NEEDS_REFINEMENT issues resolved:

• [RESOLVED] story note "app-store-submission" created on project-landscaping-assistant user-stories section
• [RESOLVED] architecture note arch-ios-pipeline created in pal-e-docs

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type (Bug)
• [x] Lineage
• [x] Repo
• [x] What Broke
• [x] Repro Steps
• [x] Expected Behavior
• [x] Environment
• [x] Acceptance Criteria
• [x] Related

All required sections for template-issue-bug are present and well-written.

Traceability

• [x] story:app-store-submission label present
• [ ] story note MISSING — [SCOPE] No app-store-submission entry exists in the project-landscaping-assistant user-stories section. Create user story entry on project-landscaping-assistant.
• [x] arch:keycloak label present
• [ ] arch note MISSING — [SCOPE] No arch-keycloak note exists in pal-e-docs. Create architecture note arch-keycloak for the Keycloak realm/client/theme component.
• [x] Forgejo issue — #290, open

File Targets

• [x] docs/app-store-review/2026-07-02-rejection-v1.0.md — verified: exists, documents all three rejection issues including the Register button error (Issue 2)
• [x] keycloak-theme/landscaping/login/resources/css/login.css — verified: exists (340 lines). Styles the #kc-registration link but does NOT hide it. Also styles #kc-register-form::before with the plant icon, meaning the registration form is part of the themed experience.
• [ ] Keycloak realm config — ISSUE: The recommended fix (registrationAllowed: false) lives in pal-e-services/terraform/k3s.tfvars, not in this repo. No specific file path given in the issue.

Repo Placement

MISMATCH. The issue says ### Repo: ldraney/landscaping-assistant and is filed on that repo. However, the recommended fix ("disable registration in Keycloak realm settings") is a Terraform change in pal-e-services/terraform/k3s.tfvars (line ~72: registration_allowed = true). Two possible fix paths exist:

1. Terraform fix (pal-e-services): Set registration_allowed = false in k3s.tfvars, then tofu apply. This removes the Register link at the Keycloak realm level.
2. CSS fix (landscaping-assistant): Add #kc-registration { display: none !important; } to keycloak-theme/landscaping/login/resources/css/login.css, then deploy the updated ConfigMap via pal-e-platform. This hides the link visually but leaves registration enabled.

Either way, at least two repos are involved. If option 1, the issue should be filed on pal-e-services (or a companion issue created there). If option 2, the theme CSS change is in landscaping-assistant but the ConfigMap deploy requires pal-e-platform. The issue needs to clarify which fix path and list all affected repos.

Dependencies

• Board item #1683 (Forgejo #289) — sibling App Store rejection bug (arch:ios-pipeline), in backlog. No blocking relationship.
• Board item #1685 (Forgejo #291) — sibling App Store rejection feature (story:app-store-submission), in backlog. No blocking relationship.
• Board item #1507 (pal-e-services#122, done) — previous Keycloak client config fix (root_url update). NOT a duplicate — different issue.
• No items currently in in_progress that block or are blocked by this ticket.

Acceptance Criteria

Three criteria listed. Assessment:

• "No Register link/button visible on Keycloak login page" — verifiable by navigating to the login page
• "Login flow works correctly on iPad (no error messages)" — verifiable but requires iPad or iPad simulator, which is appropriate given the rejection context
• "Existing login with demo credentials still works" — verifiable via standard login test

Missing criteria:

• Update docs/keycloak-setup.md to reflect the registration policy change (currently documents registration_allowed = true as intentional)
• Clean up theme CSS if registration is fully disabled (remove #kc-register-form::before styling on line 122)

Blast Radius

ARCHITECTURAL CONFLICT. The ticket proposes disabling registration, but docs/keycloak-setup.md (line 83-84) explicitly documents registration_allowed = true as an intentional design decision:

"registration_allowed = true: new users self-register as clients (the default role on signup per user-stories-auth.md). This is the 'solo client' onboarding flow."

docs/user-stories-auth.md also references the Client role as "Default role on signup," implying self-registration is part of the product design.

Disabling registration would abandon the client self-registration flow entirely. This may be acceptable (the app currently manages users via admin), but the ticket does not acknowledge this tradeoff. A human decision is needed: is self-registration being deferred or permanently removed?

If the intent is to defer (re-enable later when registration works correctly), the CSS hide approach is safer. If the intent is to remove permanently, the Terraform approach is correct but requires doc updates across keycloak-setup.md and user-stories-auth.md.

Decomposition Assessment

1-2 file targets across 1-2 repos, 3 acceptance criteria, estimated agent work under 5 minutes. No decomposition needed.

Recommendation

• [SCOPE] Human decision needed: Is client self-registration being permanently removed or temporarily deferred? This determines the fix path (Terraform vs CSS) and documentation scope. docs/keycloak-setup.md and docs/user-stories-auth.md both document self-registration as intentional.
• [BODY] Clarify fix path: Terraform (registration_allowed = false in pal-e-services) vs CSS (#kc-registration { display: none } in landscaping-assistant). List all affected repos for the chosen path.
• [BODY] Add acceptance criterion: update docs/keycloak-setup.md registration_allowed rationale to reflect the new state.
• [BODY] If Terraform path chosen, file a companion issue on pal-e-services or move this issue there.
• [SCOPE] Create user story entry app-store-submission on project-landscaping-assistant user-stories section.
• [SCOPE] Create architecture note arch-keycloak for the Keycloak realm/client/theme component.

Verdict: APPROVED

Round 3 re-review. Previous rounds flagged missing spec files. The issue body now correctly enumerates all 7 spec files with their WorkQueueItem.create!/new call counts. All file targets verified against the codebase. Scope is tight and accurate.

Template Completeness

• [x] Type — Feature
• [x] Lineage — child of #260, sub-ticket 4/4, depends on #262 and #263
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — admin wants digested items assigned to team
• [x] Context — explains ScheduleDigester, team_id requirement, caller change
• [x] File Targets — 9 files listed (2 app, 7 spec), with "NOT to touch" exclusions
• [x] Feature Flag — none (internal model change, correct)
• [x] Acceptance Criteria — 5 ACs
• [x] Test Expectations — service test + 7 spec files + run command
• [x] Constraints — 3 constraints listed
• [x] Checklist — present
• [x] Related — #260, #262, #263

Traceability

• [x] story:auth label — "auth" story found in project-landscaping-assistant user-stories section (role-based auth covers team-scoped access)
• [x] story note verified — "auth" row exists: "All roles / Log in with Keycloak, see role-appropriate tabs and features"
• [x] arch:rails-app label — rails-app architecture component
• [ ] arch note MISSING — [SCOPE] No arch-rails-app note found in pal-e-docs. This is a pre-existing gap across multiple board items, not a blocker for this ticket.
• [x] Forgejo issue — ldraney/landscaping-assistant#265, state: open

File Targets

• [x] app/services/schedule_digester.rb — verified: create_work_queue_items at line 38, creates WorkQueueItems at line 54 without team_id. Correctly targeted for adding team_id parameter.
• [x] app/controllers/uploads_controller.rb — verified: line 92 calls ScheduleDigester.create_work_queue_items. One-line change to pass team_id confirmed feasible.
• [x] spec/services/schedule_digester_spec.rb — verified: 1 WorkQueueItem.create! call (line 123)
• [x] spec/requests/weeks_spec.rb — verified: 10 WorkQueueItem.create! calls
• [x] spec/requests/uploads_spec.rb — verified: 1 WorkQueueItem.create! call (line 231)
• [x] spec/requests/work_queue_items_spec.rb — verified: 28 WorkQueueItem.create! calls (ticket does not claim a specific count, just lists it for update)
• [x] spec/models/paper_trail_spec.rb — verified: 1 WorkQueueItem.create! call (line 41)
• [x] spec/requests/days_spec.rb — verified: 17 WorkQueueItem.create!/new calls — matches ticket claim of 17
• [x] spec/models/work_queue_item_spec.rb — verified: 7 WorkQueueItem.create!/new calls — matches ticket claim of 7 (3 .new + 4 .create!)

No other spec files contain WorkQueueItem.create!/new calls — the 7-file list is exhaustive.

Repo Placement

OK. Issue is filed on ldraney/landscaping-assistant. All file targets are within this repo. Single-repo change.

Dependencies

• #262 (Team model) — HARD DEPENDENCY. Adds Team model, team_id column to work_queue_items, and NOT NULL constraint. This ticket cannot be implemented until #262 is merged. Board item 1574, currently in backlog. Documented in issue Lineage section.
• #263 (current_team helper) — HARD DEPENDENCY. Provides the current_team method used in uploads_controller.rb. Neither Team model nor current_team helper exist yet. Board item 1575, currently in backlog. Documented in issue Lineage section.
• Both dependencies are correctly documented in the issue body.

Acceptance Criteria

5 ACs, all verifiable by an agent:

• AC1: ScheduleDigester accepts team_id — testable via service spec
• AC2: uploads_controller passes current_team.id — testable via grep/read
• AC3: Default team fallback — testable via spec. Note: the fallback must be consistent with ApplicationController's current_team fallback from #263, which doesn't exist yet.
• AC4: All 7 spec files updated — testable by running rspec
• AC5: bundle exec rspec passes — direct test command

All ACs are automatable. Run command provided: bundle exec rspec.

Blast Radius

Low blast radius. The ScheduleDigester change is additive (new parameter). All spec files that inline-create WorkQueueItems are correctly identified — no other spec files were missed. The "NOT to touch" exclusion list is correct for separating scope from sub-tickets 2 and 3.

Decomposition Assessment

9 file targets in 1 repo, 5 ACs. The 7 spec file changes are mechanical (add team association to existing create!/new calls). The 2 app changes are small (add parameter + pass it). Estimated agent time: ~3 minutes. No decomposition needed.

Recommendation

No action needed. Scope is solid after round 3 refinement. All 7 spec files now correctly enumerated with verified occurrence counts. Dependencies are documented and ordered correctly (must wait for #262 and #263 before implementation).

Pre-existing gap (not blocking):

• [SCOPE] Create architecture note arch-rails-app for the rails-app component (affects many board items, not specific to this ticket)

Verdict: NEEDS_REFINEMENT

Re-review of board item #1577 after refinement. The 3 [BODY] items from review-1577-2026-06-23 were addressed. One new [BODY] issue found: incomplete spec file list. The [LABEL] and [SCOPE] items from the prior review remain as systemic gaps (not blocking).

Template Completeness

• [x] Type — Feature
• [x] Lineage — Child of #260, sub-ticket 4/4, depends on sub-ticket 1
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — As an admin, schedule digestion assigns to team
• [x] Context — explains ScheduleDigester, team_id requirement, uploads_controller call site
• [x] File Targets — listed with modify/not-touch sections, specific spec files named
• [x] Feature Flag — none (internal model change, appropriate)
• [x] Acceptance Criteria — 5 criteria
• [x] Test Expectations — service test + 5 spec files + run command
• [x] Constraints — no OCR changes, consistent with current_team fallback, uploads_controller scoped
• [x] Checklist — present
• [x] Related — references parent epic, sub-ticket 1, sub-ticket 2

Traceability

• [ ] story:auth label — MISMATCH (carried from prior review). This work is crew/team grouping, not authentication. [LABEL] Change story:auth to story:crew-grouping or similar. Systemic gap — not blocking this ticket.
• [ ] story note — No crew-grouping story in project-landscaping-assistant user-stories table. [SCOPE] Create user story entry for crew/team grouping. Systemic gap — not blocking.
• [x] arch:rails-app label — present on board item
• [ ] arch note MISSING — no arch-rails-app note found in pal-e-docs. [SCOPE] Create architecture note arch-rails-app. Systemic gap — not blocking.
• [x] Forgejo issue — ldraney/landscaping-assistant#265, state: open

Prior [BODY] Items — Verification

• [x] [BODY] Specific spec files — FIXED. Issue now lists 5 named spec files instead of vague catch-all. However, list is incomplete (see below).
• [x] [BODY] uploads_controller.rb as file target — FIXED. Listed as file target with clear description: "pass current_team.id as team_id: when calling ScheduleDigester.create_work_queue_items (one-line change at line 92)." Verified: line 92 is the correct call site (ScheduleDigester.create_work_queue_items call).
• [x] [BODY] Unique index ownership — FIXED. "Files NOT to touch" section now states: "Unique index on work_queue_items — owned by sub-ticket 1 (#262)."

File Targets

• [x] app/services/schedule_digester.rb — verified: exists, create_work_queue_items class method at line 38. WorkQueueItem.create! at line 54 passes work_date, property_id, position only. Correct modification target.
• [x] app/controllers/uploads_controller.rb — verified: exists, line 92 calls ScheduleDigester.create_work_queue_items(week_start:, day_assignments:). Correct call site for passing team_id.
• [x] spec/services/schedule_digester_spec.rb — verified: 1 WorkQueueItem.create! call (line 123)
• [x] spec/requests/weeks_spec.rb — verified: 10 WorkQueueItem.create! calls
• [x] spec/requests/uploads_spec.rb — verified: 1 WorkQueueItem.create! call (line 231)
• [x] spec/requests/work_queue_items_spec.rb — verified: 33 WorkQueueItem.create!/new calls
• [x] spec/models/paper_trail_spec.rb — verified: 1 WorkQueueItem.create! call (line 41)
• [ ] spec/requests/days_spec.rb — MISSING from file targets. Contains 17 WorkQueueItem.create!/new calls. Will break when team_id becomes NOT NULL. [BODY]
• [ ] spec/models/work_queue_item_spec.rb — MISSING from file targets. Contains 7 WorkQueueItem.create!/new calls. Will break when team_id becomes NOT NULL. [BODY]

No spec/factories/ directory exists — confirmed. All tests use inline creation.

Files NOT to touch section is clear and accurate: work_queue_items_controller.rb (sub-ticket 2), days_controller.rb/weeks_controller.rb/crew_controller.rb (sub-ticket 3), unique index (sub-ticket 1).

Repo Placement

OK. All file targets are in ldraney/landscaping-assistant. Single-repo change.

Dependencies

• Hard dependency on sub-ticket 1 (#262, board item 1574) — Team model, team_id FK on work_queue_items. Currently in backlog, not started. This ticket cannot be implemented until #262 is merged.
• Soft dependency on sub-ticket 2 (#263, board item 1575) — ApplicationController current_team helper. The uploads_controller change references current_team.id, which sub-ticket 2 creates. This is now a hard dependency for the uploads_controller change.
• Dependencies documented in the issue Lineage section and Related section. Adequate.

Acceptance Criteria

• [x] "ScheduleDigester.create_work_queue_items accepts and assigns team_id" — testable via service spec
• [x] "uploads_controller.rb passes current_team.id when calling the digester" — testable, clear call site identified
• [x] "If no team can be derived, fall back to the default team" — testable
• [x] "All 5 spec files updated with team association" — testable, but should say "all 7 spec files" (see missing files above)
• [x] "bundle exec rspec passes with zero failures" — testable

5 AC — within the 5-minute rule threshold.

Blast Radius

• Missing spec files — spec/requests/days_spec.rb (17 calls) and spec/models/work_queue_item_spec.rb (7 calls) create WorkQueueItems without team_id. When sub-ticket 1 adds NOT NULL on team_id, these tests will fail. They must be listed as file targets.
• Controller creates (days_controller, weeks_controller, work_queue_items_controller) — correctly scoped to sub-tickets 2 and 3. No overlap concern.
• db/seeds.rb — 5 WorkQueueItem.create! calls without team_id. Will need updating but is appropriately outside this ticket's scope (seed data follows model changes).

Decomposition Assessment

1 service file + 1 controller file + 7 spec files across 1 repo. 5 acceptance criteria. Estimated agent work under 5 minutes. No decomposition needed.

Recommendation

• [BODY] Add spec/requests/days_spec.rb (17 WorkQueueItem.create!/new calls) to the File Targets section. This file will break when team_id becomes NOT NULL.
• [BODY] Add spec/models/work_queue_item_spec.rb (7 WorkQueueItem.create!/new calls) to the File Targets section. This file will break when team_id becomes NOT NULL.
• [BODY] Update AC #4 from "All 5 spec files" to "All 7 spec files" to match the complete list.
• [LABEL] Change story:auth to a crew-grouping story label (systemic gap, not blocking).
• [SCOPE] Create user story entry for crew/team grouping on project-landscaping-assistant (systemic gap, not blocking).
• [SCOPE] Create architecture note arch-rails-app (systemic gap, not blocking).

Verdict: READY

Template Completeness

• [x] Type — Feature
• [x] Lineage — Child of #260 (Epic), sub-ticket 3 of 4, depends on sub-ticket 2
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — crew lead/admin scoped views
• [x] Context — explains relationship to sub-ticket 2
• [x] File Targets — 3 files to modify, 2 exclusions
• [x] Feature Flag — none (correct: scoping change, no user-visible toggle)
• [x] Acceptance Criteria — 7 items
• [x] Test Expectations — 3 controller tests + run command
• [x] Constraints — references current_team helper pattern
• [x] Checklist — standard 3-item
• [x] Related — parent epic + dependency

Traceability

• [x] story:auth label — "auth" story found in project-landscaping-assistant user-stories table: "Log in with Keycloak, see role-appropriate tabs and features"
• [x] story note verified — auth entry exists in project-landscaping-assistant user-stories section
• [x] arch:rails-app label — component is the Rails application
• [ ] arch note MISSING — no arch-rails-app note found in pal-e-docs. This is acceptable: arch:rails-app is the primary app itself, not a separable component. Documenting it as an architecture note would add no value beyond what the project page already covers.
• [x] Forgejo issue — https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant/issues/264, state: open

File Targets

• [x] app/controllers/days_controller.rb — verified: exists (127 lines). Queries WorkQueueItem unscoped in show (line 9-12), add_to_queue (line 36, 52, 56), and load_previously (line 103-108). All need current_team scoping as described.
• [x] app/controllers/weeks_controller.rb — verified: exists (85 lines). Queries WorkQueueItem unscoped in index (line 12-14) and toggle_assign (line 54, 68). Both need current_team scoping as described.
• [x] app/controllers/crew_controller.rb — verified: exists (11 lines). Queries CrewMember.active.by_name unscoped in index (line 5). Needs current_team scoping as described.
• [x] app/controllers/work_queue_items_controller.rb — verified: correctly excluded. Sub-ticket 2 covers this (issue #263).
• [x] app/services/schedule_digester.rb — verified: correctly excluded. Sub-ticket 4 covers this (issue #265).

Repo Placement

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

Dependencies

• Sub-ticket 1 (#262) — Team model + migration. Must be merged first so team_id FK exists on crew_members and work_queue_items. Currently in backlog. Board item #1574.
• Sub-ticket 2 (#263) — current_team helper in ApplicationController + WorkQueueItemsController scoping. Must be merged first so current_team helper is available. Currently in backlog. Board item #1575.
• Both dependencies are documented in the issue (Lineage section and Related section). Dependency chain is clear: #262 → #263 → #264.
• No in_progress items block this ticket.

Acceptance Criteria

All 7 AC are verifiable by an agent:

• AC 1-3 (days controller scoping): testable via controller specs — mock current_team, create items for multiple teams, assert only matching team's items returned
• AC 4-5 (weeks controller scoping): same pattern
• AC 6 (crew controller scoping): same pattern with CrewMember
• AC 7 (rspec passes): run command provided

Test expectations match AC well: 3 controller test files for the 3 controllers. Existing spec files found at spec/requests/days_spec.rb, spec/requests/weeks_spec.rb, and spec/requests/crew_spec.rb — agent will modify these.

Blast Radius

• uploads_controller.rb — also creates WorkQueueItems via ScheduleDigester (line 92). Correctly excluded: sub-ticket 4 handles schedule_digester.rb scoping. uploads_controller delegates to the service, so scoping there will cover it.
• sessions_controller.rb — creates CrewMember records on login (line 33). Not affected: it creates the record, not queries scoped data. Team assignment will be handled by sub-ticket 1's migration (default team backfill).
• application_controller.rb — current_crew_member helper (line 48). Not affected: this ticket consumes current_team, doesn't modify ApplicationController.
• No sibling controllers query WorkQueueItem or CrewMember beyond what's documented.

Decomposition Assessment

3 file targets in 1 repo, 7 acceptance criteria, estimated agent work under 5 minutes. The changes follow a repetitive pattern (add .where(team_id: current_team.id) to each query). No decomposition needed.

Recommendation

No action needed. Scope is solid, all file targets verified, traceability complete, dependencies documented, fits in a single agent pass.

Verdict: READY

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Child of #260, sub-ticket 2 of 4, dependency on sub-ticket 1 documented
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- As a crew member / scoped Today view
• [x] Context -- Explains relationship to sub-ticket 1 (Team model)
• [x] File Targets -- 2 files to modify, 3 files explicitly excluded
• [x] Feature Flag -- "none" (internal model/controller change, appropriate)
• [x] Acceptance Criteria -- 6 criteria
• [x] Test Expectations -- 3 test cases + run command
• [x] Constraints -- memoization, fallback, model validation boundary
• [x] Checklist -- present
• [x] Related -- parent epic and dependency referenced

Traceability

• [x] story:auth label -- "auth" story covers role-based features including crew grouping
• [x] story note verified -- "auth" entry found in project-landscaping-assistant user-stories section: "Log in with Keycloak, see role-appropriate tabs and features"
• [x] arch:rails-app label -- rails-app architecture component
• [ ] arch note MISSING -- no arch-rails-app note found in pal-e-docs. However, this is a long-standing pattern across the board (all landscaping-assistant issues use arch:rails-app). This is a systemic gap, not specific to this ticket. Acceptable for now.
• [x] Forgejo issue -- ldraney/landscaping-assistant#263, state: open

File Targets

• [x] app/controllers/application_controller.rb -- verified exists (114 lines). Already has current_crew_member helper (line 45-49) using the same lookup pattern. Adding current_team following this pattern is natural.
• [x] app/controllers/work_queue_items_controller.rb -- verified exists (285 lines). All WorkQueueItem queries confirmed unscoped (no team filtering). Actions mentioned (index, create, update, destroy, mark_other, reorder) and private helpers (compute_unqueued_this_week, recent_properties) all confirmed present.
• [x] app/controllers/days_controller.rb -- verified exists, correctly listed as NOT to touch (sub-ticket 3)
• [x] app/controllers/weeks_controller.rb -- verified exists, correctly listed as NOT to touch (sub-ticket 3)
• [x] app/controllers/crew_controller.rb -- verified exists, correctly listed as NOT to touch (sub-ticket 3)

Minor note: The issue describes current_team as looking up session[:username], but the existing current_crew_member pattern uses current_user[:username]. These are equivalent (current_user reads from session), but the implementing agent should follow the existing current_crew_member pattern and use current_crew_member&.team rather than duplicating the lookup.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in this repo. Single-repo change.

Dependencies

• Hard dependency: Sub-ticket 1 (#262, "Feature: Team model, migration, and associations") must merge first. Confirmed: no Team model exists yet, no team_id column on crew_members or work_queue_items, no migration. This dependency is correctly documented in the Lineage section.
• Board item #1574 (issue #262) is in backlog column -- sub-ticket 1 has not started yet.
• Sub-tickets 3 (#264) and 4 (#265) depend on this ticket (documented in epic #260).

Acceptance Criteria

All 6 criteria are testable by an agent:

• "current_team returns the Team" -- unit testable via controller test
• "current_team returns the default team if user has no CrewMember record" -- testable with fixture setup
• "Today view index only shows WorkQueueItems for current_team" -- controller test with two teams
• "Creating a work queue item assigns current_team.id" -- controller test
• "Two users on the same team see the same Today list" -- integration test
• "bundle exec rspec passes" -- run command

Test expectations align with acceptance criteria. Run command is real.

Blast Radius

• days_controller.rb queries WorkQueueItem (6 references) -- correctly excluded, scoped to sub-ticket 3
• weeks_controller.rb queries WorkQueueItem (4 references) -- correctly excluded, scoped to sub-ticket 3
• schedule_digester.rb -- correctly excluded, scoped to sub-ticket 4
• No other controllers query WorkQueueItem directly
• Views that render WorkQueueItem data may need team-aware partials, but since the controller scopes the data, views should work without changes

Decomposition Assessment

2 file targets in 1 repo, 6 acceptance criteria (one over threshold but simple), estimated agent work under 5 minutes. This is already a sub-ticket from a decomposed epic. No further decomposition needed.

Recommendation

No action needed. Scope is solid, file targets verified, traceability complete, dependencies documented and sequenced correctly. The ticket is blocked on sub-ticket 1 (#262) which must merge first.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, session-requested
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- present, well-formed
• [x] Context -- good background on current global scope and motivation
• [x] File Targets -- 6 files listed (1 new, 5 existing)
• [x] Feature Flag -- "none" with rationale (data model change, not UI toggle)
• [x] Acceptance Criteria -- 6 criteria
• [x] Test Expectations -- 3 test items + run command
• [x] Constraints -- 4 constraints listed
• [x] Checklist -- present
• [x] Related -- docs referenced

All required sections for the Feature template are present.

Traceability

• [x] story:auth label -- "Auth" user story (login with Keycloak, role-appropriate tabs)
• [x] story note verified -- "auth" entry found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label -- Rails application component
• [ ] arch note MISSING -- [SCOPE] No note found for "arch-rails-app" in pal-e-docs. Create architecture note arch-rails-app for the Rails application component.
• [x] Forgejo issue -- ldraney/landscaping-assistant#260, state: open

File Targets

• [x] app/models/team.rb (new) -- confirmed does NOT exist yet, correct to create
• [x] app/models/crew_member.rb -- verified: exists, currently has no team association. Has has_many :service_requests, validates name/keycloak_username/role. Adding belongs_to :team is appropriate.
• [x] app/models/work_queue_item.rb -- verified: exists, currently belongs_to :property only. Adding belongs_to :team is appropriate.
• [x] app/controllers/work_queue_items_controller.rb -- verified: exists, currently queries WorkQueueItem globally with no crew/team scoping. All queries (index, create, update, destroy, mark_other, reorder) need scoping.
• [x] app/controllers/application_controller.rb -- verified: exists, already has current_crew_member helper. Adding current_team derived from current_crew_member.team is natural.
• [x] db/migrate/ -- verified: migration directory exists, latest migration is 20260617000000

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in that repo. No cross-repo work needed.

Dependencies

• No blocking dependencies found on the board. No items in in_progress or next_up that conflict.
• Item #1572 (next_up) is a Keycloak issuer mismatch bug -- unrelated, no conflict.
• Item #1403 (todo, "Property detail page: Projects section") -- unrelated.
• The ticket correctly identifies that config/initializers/omniauth.rb should NOT be touched (separate bug fix).

Acceptance Criteria

6 AC items, all reasonably testable by an agent:

• AC 1-4 are verifiable via request specs (create items as one user, verify visibility as another)
• AC 5 (no regression) is verifiable by running existing test suite
• AC 6 (seeds/migration) is verifiable by checking migration and seed files

However, AC 1-4 assume multi-user sessions which require Keycloak integration test setup. The test expectations section describes model and controller tests which are more realistic for agent verification.

Blast Radius

CRITICAL: The issue underestimates the blast radius. The File Targets list 4 controllers to modify but the actual codebase shows WorkQueueItem is queried in 4 controllers, not just 1:

• app/controllers/work_queue_items_controller.rb -- listed in ticket
• app/controllers/days_controller.rb -- NOT listed. Has 3 independent WorkQueueItem queries (show, add_to_queue, load_previously). All need team scoping.
• app/controllers/weeks_controller.rb -- NOT listed. Queries WorkQueueItem in index and toggle_assign. All need team scoping.
• app/controllers/uploads_controller.rb -- NOT listed (indirectly via ScheduleDigester). app/services/schedule_digester.rb creates WorkQueueItems without team_id.

Additionally:

• app/controllers/crew_controller.rb -- queries CrewMember but does not filter by team. If team scoping is added, the Crew tab should show only the current team's members.
• The work_queue_items table has a unique index on [work_date, property_id]. With team scoping, this uniqueness constraint may need to become [work_date, property_id, team_id] if different teams can queue the same property on the same day.

Decomposition Assessment

NEEDS DECOMPOSITION

• File targets: 6 listed + at least 4 additional files not mentioned = ~10 files
• Acceptance criteria: 6 AC + test expectations = 9 verifiable items
• Controllers affected: 4 controllers + 1 service, spanning multiple concerns (model layer, scoping layer, view layer)
• Estimated agent work: >5 minutes -- the migration alone (teams table + 2 FK columns + data backfill + unique index change) is non-trivial, and scoping 4 controllers is substantial

This exceeds the 5-minute rule on all three criteria. Route to skill-decompose-ticket.

Recommendation

• [BODY] Add missing file targets: app/controllers/days_controller.rb, app/controllers/weeks_controller.rb, app/controllers/crew_controller.rb, app/services/schedule_digester.rb
• [BODY] Address unique index change: the existing [work_date, property_id] unique index on work_queue_items may need to become [work_date, property_id, team_id] for multi-team support
• [BODY] Add blast radius note about uploads/schedule_digester creating WorkQueueItems without team_id
• [SCOPE] Create architecture note arch-rails-app for the Rails application component in pal-e-docs
• [DECOMPOSE] 10 files across model/controller/service layers, 6+ AC, estimated >5 min agent work -- route to skill-decompose-ticket. Suggested split: (1) Migration + Team model + belongs_to associations, (2) ApplicationController current_team helper + WorkQueueItemsController scoping, (3) DaysController + WeeksController + CrewController scoping, (4) ScheduleDigester team-aware creation + test updates

Verdict: APPROVED

Re-review of board item #1572 after refinement. All 4 [BODY] recommendations from review-1572-2026-06-23 have been addressed. 1 [SCOPE] item (arch-rails-app note) carried forward but does not block this ticket.

Template Completeness

• [x] Type -- Bug
• [x] Lineage -- Standalone, discovered during session. Now includes cross-reference to pal-e-platform#455 with explicit independence statement.
• [x] Repo -- ldraney/landscaping-assistant
• [x] What Broke -- Issuer mismatch error with log evidence and code reference
• [x] Root Cause Fix -- NEW. Clearly specifies Rails-side fix with two options (discovery fetch vs KEYCLOAK_ISSUER env var). Explicitly scopes out Keycloak-side KC_HOSTNAME changes.
• [x] Repro Steps -- Clear 5-step repro
• [x] Expected Behavior -- present
• [x] Environment -- Cluster, pod env vars, Keycloak discovery issuer all documented
• [x] Acceptance Criteria -- 6 criteria, all testable (expanded from 4)
• [x] Related -- file paths, docs, and cross-repo reference to pal-e-platform#455

All required sections for a Bug template are present and well-filled.

Traceability

• [x] story:custom-domain label -- verified: "custom-domain" entry exists in project-landscaping-assistant user-stories section. Summary: "Access app via landscaping-assistant.app instead of Tailscale hostname."
• [x] story note verified -- found in project-landscaping-assistant user-stories table
• [ ] arch:rails-app label -- no matching arch note found in pal-e-docs (search for "arch-rails-app" returned empty). [SCOPE] Create architecture note arch-rails-app for the Rails application component. Carried forward from first review -- does not block this ticket since arch:rails-app is a shared label used on 30+ board items; the fix is fully scoped without it.
• [x] Forgejo issue -- ldraney/landscaping-assistant#259, open

File Targets

• [x] config/initializers/omniauth.rb (line 20) -- verified: line 20 contains issuer: keycloak_configured ? "#{ENV["KEYCLOAK_URL"]}/realms/#{ENV["KEYCLOAK_REALM"]}" : "https://keycloak.test/realms/test". This is exactly where the mismatch originates.
• [x] app/controllers/sessions_controller.rb (line 48) -- verified: line 48 builds logout_url from ENV["KEYCLOAK_URL"]. Issue correctly notes this should continue using KEYCLOAK_URL.
• [x] app/services/keycloak_admin_service.rb -- verified: line 7 fetches ENV.fetch("KEYCLOAK_URL") as base_url. Admin API calls should not be affected by issuer-only fix.
• [x] docs/auth-strategy.md -- verified: exists, documents Auth Code + PKCE architecture
• [x] docs/keycloak-setup.md -- verified: exists, documents realm/client config

Repo Placement

OK. The Root Cause Fix section now explicitly states "Rails-side fix (this repo only)" and scopes out Keycloak hostname reconfiguration. The relationship to pal-e-platform#455 is documented in Lineage as independent.

Dependencies

• Board item #1504 (pal-e-platform#455, backlog, type:bug, story:custom-domain) -- documented in Lineage as the Keycloak server-side companion. Issue explicitly states this ticket does NOT depend on #455.
• Board item #1478 (landscaping-assistant#246, done) -- previous OmniAuth redirect_uri fix. Provides context for the custom-domain story arc.
• No blocking dependencies. Independent fix.

Acceptance Criteria

6 criteria, all testable:

• AC1 (login via landscaping-assistant.app): verifiable by manual test
• AC2 (login via Tailscale URL): regression check, verifiable
• AC3 (logout works): NEW -- addresses previous review finding. Verifiable by checking end-session redirect.
• AC4 (KeycloakAdminService): NEW -- addresses previous review finding. Verifiable by testing profile edit.
• AC5 (endpoint specs pass): verifiable via bundle exec rspec
• AC6 (KEYCLOAK_URL stays as auth.palinks.app): verifiable by inspecting k8s secret

All criteria are clear and agent-verifiable.

Blast Radius

• KEYCLOAK_URL is referenced in 4 production files: omniauth.rb, application_controller.rb (presence check only), sessions_controller.rb (logout URL), keycloak_admin_service.rb (admin API base URL). The fix only changes issuer derivation in omniauth.rb -- other files continue using KEYCLOAK_URL as-is.
• 8 spec files mock KEYCLOAK_URL (12+ references). Specs should not need changes unless a new env var is introduced, in which case only omniauth.rb-related specs need updating.
• Root Cause Fix section correctly identifies that KEYCLOAK_URL must remain usable for logout and admin API -- only issuer validation changes.

Decomposition Assessment

2-3 file targets in 1 repo, 6 acceptance criteria. Estimated agent work under 5 minutes for the Rails-side issuer override. No decomposition needed.

Refinement Verification (re-review)

Previous review: review-1572-2026-06-23 (NEEDS_REFINEMENT, 5 items)

• [x] [BODY] Root Cause Fix section added -- specifies Rails-side fix with two options, scopes out Keycloak-side changes
• [x] [BODY] Dependencies documented in Lineage -- pal-e-platform#455 referenced, independence stated
• [x] [BODY] AC for logout added -- AC3 covers end-session redirect
• [x] [BODY] AC for KeycloakAdminService added -- AC4 covers profile edit
• [ ] [SCOPE] arch-rails-app note still missing -- carried forward, does not block ticket

Recommendations

• [SCOPE] Create architecture note arch-rails-app for the Rails application component (carried forward from first review -- low priority, affects 30+ board items, not specific to this ticket).

No other action needed. Ticket is APPROVED for implementation.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Bug
• [x] Lineage -- Standalone, discovered during session
• [x] Repo -- ldraney/landscaping-assistant
• [x] What Broke -- Issuer mismatch error with log evidence and code reference
• [x] Repro Steps -- Clear 5-step repro
• [x] Expected Behavior -- present
• [x] Environment -- Cluster, pod env vars, Keycloak discovery issuer all documented
• [x] Acceptance Criteria -- 4 criteria, testable
• [x] Related -- file paths and docs referenced

All required sections for a Bug template are present and well-filled.

Traceability

• [x] story:custom-domain label -- verified: "custom-domain" entry exists in project-landscaping-assistant user-stories section. Summary: "Access app via landscaping-assistant.app instead of Tailscale hostname."
• [x] story note verified -- found in project-landscaping-assistant user-stories table
• [ ] arch:rails-app label -- no matching arch note found in pal-e-docs (search for "arch-rails-app" returned empty). [SCOPE] Create architecture note arch-rails-app for the Rails application component.
• [x] Forgejo issue -- ldraney/landscaping-assistant#259, open

File Targets

• [x] config/initializers/omniauth.rb (line 20) -- verified: line 20 contains issuer: keycloak_configured ? "#{ENV["KEYCLOAK_URL"]}/realms/#{ENV["KEYCLOAK_REALM"]}" : "https://keycloak.test/realms/test". This is exactly where the mismatch originates.
• [x] docs/auth-strategy.md -- verified: exists, documents Auth Code + PKCE architecture
• [x] docs/keycloak-setup.md -- verified: exists, documents realm/client config. Notes KEYCLOAK_URL as https://keycloak.tail5b443a.ts.net (the old value before custom domain)

Repo Placement

ISSUE: The fix may not be fully contained in ldraney/landscaping-assistant. The issue states "KEYCLOAK_URL remains https://auth.palinks.app in the k8s secret (do NOT revert to Tailscale URL)." This means the fix must either:

1. Override the issuer in OmniAuth config to use a separate env var (e.g., KEYCLOAK_ISSUER_URL) pointing to the Tailscale URL, OR
2. Configure Keycloak's KC_HOSTNAME to recognize auth.palinks.app as its frontend URL -- this is a pal-e-platform/pal-e-services change.

Option (1) is a Rails-only fix in this repo. Option (2) is the proper fix but spans pal-e-platform and/or pal-e-services. The issue body does not clarify which approach to take. [BODY] Add a "Root Cause Fix" section specifying whether this is a Rails-side workaround (issuer override) or a Keycloak-side fix (KC_HOSTNAME), and if cross-repo, reference the companion issues.

Note: board item #1504 (pal-e-platform#455, type:bug, story:custom-domain) is in backlog and may be the companion Keycloak-side fix. If so, these two tickets should reference each other.

Dependencies

• Board item #1504 (pal-e-platform#455, backlog, type:bug, story:custom-domain) -- likely the Keycloak server-side companion. If this ticket does a Rails-side workaround, #1504 may be the proper Keycloak fix. If this ticket expects a Keycloak fix, it is blocked by #1504.
• Board item #1478 (landscaping-assistant#246, done) -- the previous OmniAuth redirect_uri fix. This ticket is a continuation of the custom-domain story.
• Board item #1461 (landscaping-assistant#224, done) -- Rails config.hosts + Keycloak redirect URIs. Already completed, provides context.
• Dependencies are not documented in the issue body. [BODY] Add a Dependencies section noting the relationship to pal-e-platform#455 and whether this ticket is blocked or independent.

Acceptance Criteria

The 4 criteria are testable:

• AC1 (login via landscaping-assistant.app): verifiable by manual test or curl
• AC2 (login via Tailscale URL): verifiable, good regression check
• AC3 (endpoint specs pass): verifiable via bundle exec rspec
• AC4 (KEYCLOAK_URL stays as auth.palinks.app): verifiable by inspecting k8s secret

Missing: No AC for logout working correctly. The sessions_controller.rb line 48 also uses KEYCLOAK_URL for the logout redirect URL. If the fix introduces a separate issuer URL, logout must also be verified. [BODY] Add AC: "Logout via auth.palinks.app still redirects correctly."

Missing: No AC for KeycloakAdminService. The app/services/keycloak_admin_service.rb uses KEYCLOAK_URL for admin API calls (profile updates). If a separate issuer env var is introduced, admin calls should still route through the correct URL. [BODY] Add AC: "Profile edit (KeycloakAdminService) still works via auth.palinks.app."

Blast Radius

• KEYCLOAK_URL is referenced in 4 production files: omniauth.rb, application_controller.rb (presence check only), sessions_controller.rb (logout URL), keycloak_admin_service.rb (admin API base URL). All 4 use the same env var. If the fix splits issuer from base URL, only omniauth.rb should change -- the others should continue using the proxy URL.
• 12+ spec files mock KEYCLOAK_URL. A new env var would need corresponding spec updates.
• docs/keycloak-setup.md still documents KEYCLOAK_URL as https://keycloak.tail5b443a.ts.net -- this is stale now that production uses auth.palinks.app. Not in scope for this bug fix but worth noting.

Decomposition Assessment

2 file targets in 1 repo, 4 acceptance criteria. Estimated agent work under 5 minutes IF the approach is a Rails-side issuer override (add env var, update omniauth.rb, update specs). No decomposition needed for that approach. If the fix requires Keycloak-side changes (KC_HOSTNAME), that is a separate ticket in pal-e-platform -- but this ticket's scope is the Rails side only, so no decomposition needed here.

Recommendations

• [BODY] Add a "Root Cause Fix" section specifying whether this is a Rails-side workaround (issuer override env var) or a Keycloak-side fix (KC_HOSTNAME), and if cross-repo, reference companion issues.
• [BODY] Add a Dependencies section noting the relationship to pal-e-platform#455 and whether this ticket is blocked or independent.
• [BODY] Add AC: "Logout via auth.palinks.app still redirects correctly."
• [BODY] Add AC: "Profile edit (KeycloakAdminService) still works via auth.palinks.app."
• [SCOPE] Create architecture note arch-rails-app for the Rails application component (missing from pal-e-docs).

Verdict: READY

Template Completeness

• [x] Type — Bug
• [x] Lineage — references #224
• [x] Repo — ldraney/landscaping-assistant
• [x] What Broke — detailed description with redirect_uri mismatch
• [x] Repro Steps — 5 concrete steps
• [x] Expected Behavior — dynamic redirect_uri matching Host header
• [x] Environment — prod namespace, public domain, Keycloak realm/client specified
• [x] Root Cause — extra section identifying OmniAuth initializer hardcoding (accurate)
• [x] Acceptance Criteria — 4 criteria, all testable
• [x] Related — 4 references to upstream/sibling tickets

Traceability

• [x] story:custom-domain label — "Access app via landscaping-assistant.app instead of Tailscale hostname"
• [x] story note verified — found in project-landscaping-assistant user-stories section (custom-domain row)
• [x] arch:rails-app label — Rails application component
• [ ] arch note MISSING — no arch-rails-app note exists in pal-e-docs. However, this is a platform-wide architecture note covering dozens of tickets across all Rails work. Not blocking for this bug review.
• [x] Forgejo issue — ldraney/landscaping-assistant#246, open

File Targets

• [x] config/initializers/omniauth.rb (line 28) — verified: redirect_uri uses ENV.fetch('APP_URL', 'https://landscaping-assistant.tail5b443a.ts.net') with hardcoded Tailscale fallback. Root cause confirmed.
• [x] config/environments/production.rb (lines 97-99) — verified: config.hosts whitelists multiple hostnames but doesn't affect OmniAuth redirect_uri
• [x] app/controllers/sessions_controller.rb (line 50) — verified: logout redirect uses dynamic root_url, but OmniAuth callback URL is static

Repo Placement

Correct. Issue filed on ldraney/landscaping-assistant, fix is in the same repo (OmniAuth initializer). Keycloak client redirect URIs may also need updating but that was covered by #224.

Dependencies

• #224 (config.hosts + Keycloak redirect URIs) — in validation column. This bug is a follow-up discovery from #224's incomplete scope (redirect_uri not addressed).
• #434 (Caddy reverse proxy for landscaping-assistant.app) — in validation column. Must be working for this fix to be testable.
• #231 (HostAuthorization fix) — done. Prerequisite resolved.

No blockers. Dependencies are either done or in validation.

Acceptance Criteria

All 4 criteria are concrete and agent-verifiable:

• AC1: redirect_uri check via browser or curl — testable
• AC2: Tailscale hostname regression check — testable
• AC3: Keycloak valid_redirect_uris — verifiable via Keycloak admin API or config
• AC4: Full login flow on public domain — testable via browser automation

Note: AC3 (Keycloak redirect URIs) may already be covered by #224. If so, it's a no-op verification rather than new work. This doesn't change the scope estimate.

Blast Radius

Low. The fix is isolated to the OmniAuth initializer. The same pattern (ENV.fetch with Tailscale fallback) should be checked for any other URL-generating code, but the agent search found only the OmniAuth initializer and sessions controller (which already uses dynamic URLs). No sibling services affected.

Decomposition Assessment

1 primary file target, 1 repo, 4 acceptance criteria. Estimated agent work: under 5 minutes. No decomposition needed.

Recommendation

No action needed. Ticket is well-scoped and ready for implementation.

Note: The missing arch-rails-app note is a platform-wide gap affecting many tickets, not specific to this bug. It should be tracked separately if desired.

Verdict: APPROVED

Re-review after NEEDS_REFINEMENT on prior pass. The issue body has been updated to address all previous findings. Scope is solid, file targets verified, dependency documented. Ready for agent implementation.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- PR #241 QA review origin
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- admin role, input validation + security posture
• [x] Context -- detailed background with 3 nit categories
• [x] File Targets -- modify list, create list, and "should NOT touch" list all present
• [x] Feature Flag -- none (correct for security hardening)
• [x] Acceptance Criteria -- 7 criteria, all verifiable
• [x] Test Expectations -- 11 specific specs with run command
• [x] Constraints -- 5 constraints including pattern guidance
• [x] Checklist -- present
• [x] Related -- project, PRs, parent issue referenced

Traceability

• [x] story:security label -- present on board item
• [ ] story note -- MISSING: no "security" entry in project-landscaping-assistant user-stories table. Acceptable: this is foundational/cross-cutting security work, not a user-facing feature story. The user story in the issue body is well-formed. Not blocking.
• [x] arch:rails-app label -- present on board item
• [ ] arch note -- MISSING: no arch-rails-app note in pal-e-docs. This is a pre-existing gap across the entire board (all rails-app items use this label). Not blocking for this ticket specifically.
• [x] Forgejo issue -- ldraney/landscaping-assistant#243, state: open

File Targets

• [x] app/controllers/days_controller.rb -- exists at HEAD (commit 40044da, PR #240). Does NOT yet have add_to_queue action; that comes from PR #241 (still open, not merged). Issue correctly documents this dependency.
• [x] app/controllers/work_queue_items_controller.rb -- verified: create (line 65) and mark_other (line 183) both pass params[:property_id] directly to WorkQueueItem without existence check.
• [x] app/controllers/weeks_controller.rb -- verified: toggle_assign (line 45) guards property_id <= 0 (line 49) but does not guard non-existent positive IDs. WorkQueueItem.create! at line 65 would raise ActiveRecord::InvalidForeignKey.
• [x] app/controllers/application_controller.rb -- verified: before_action :authenticate_user! at line 13. Shared helper target is reasonable.
• [x] spec/requests/work_queue_items_spec.rb -- exists, no unauthenticated tests currently.
• [x] spec/requests/weeks_spec.rb -- exists, no unauthenticated tests currently.
• [x] spec/requests/properties_spec.rb -- exists, no unauthenticated tests currently (role_access_spec covers /properties redirect but per-controller coverage is the goal here).
• [x] spec/requests/crew_spec.rb -- exists, has 2 mentions of unauthenticated/redirect.
• [x] spec/requests/uploads_spec.rb -- exists, no unauthenticated tests currently.
• [x] spec/requests/days_spec.rb -- exists at HEAD (PR #240). Depends on PR #241 for add_to_queue spec.
• [x] docs/security.md -- does not yet exist (correctly listed as "create").
• [x] "Should NOT touch" list -- properties_controller.rb (uses Property.find, correct 404), sessions_controller.rb (skips auth), client_errors_controller.rb (skips auth), property_picker_controller.js (client-side). All verified accurate.

Repo Placement

OK. Issue is filed on ldraney/landscaping-assistant. All file targets are within this repo. No cross-repo work needed.

Dependencies

• PR #241 (property picker for day detail page) -- not yet merged, state: open. DaysController#add_to_queue and spec/requests/days_spec.rb changes depend on this. Issue correctly documents this dependency. Agent should handle DaysController changes conditionally or this ticket should wait for PR #241 merge.
• PR #240 (commit 40044da) -- already merged to main. DaysController base (show action) exists at HEAD. Previous reviewer incorrectly flagged this as phantom; confirmed present.
• No board-level blockers found. Item #1476 is in backlog, no other items explicitly depend on or block it.

Acceptance Criteria

All 7 AC are verifiable by an agent:

• AC 1-4: property_id validation returns 422 -- testable with request specs using non-existent IDs
• AC 5: unauthenticated redirect specs -- testable with raw HTTP requests without session
• AC 6: docs/security.md content requirements -- verifiable by file read
• AC 7: existing tests pass -- verifiable by running test suite

AC 1 depends on PR #241. The remaining 6 AC can be implemented independently.

Blast Radius

• Missing controllers in unauthenticated spec list: join_crew_controller.rb and profile_controller.rb are protected (inherit authenticate_user! from ApplicationController, no skip_before_action), but are NOT listed as unauthenticated spec targets. However, this is a minor scope gap -- the issue's stated goal is "at least one spec per protected controller," and these two controllers have existing spec files (join_crew_spec.rb, profile_spec.rb) that also lack unauthenticated coverage. Not blocking since the issue focuses on the controllers surfaced by the PR #241 QA review, but worth noting for the implementing agent.
• role_access_spec.rb overlap: This file already covers unauthenticated redirects for /today, /properties, /weeks, /crew. The ticket's per-controller approach is complementary (defense in depth), not redundant. No conflict.
• WeeksController#toggle_assign line 65: WorkQueueItem.create!(property_id: property_id, ...) with a non-existent property_id will raise ActiveRecord::InvalidForeignKey (500 error). The guard at line 49 only catches <= 0. Confirmed the ticket's diagnosis is correct.

Decomposition Assessment

7 AC, 11 test expectations, all in one repo. File targets: 5 controllers to modify + 6 spec files to modify + 1 doc to create = 12 files total. However, the property_id guard is a repetitive pattern (same fix applied 4 times), and the unauthenticated specs are boilerplate. The security doc is standalone writing. Estimated agent time: 4-5 minutes. Borderline but fits in a single pass at 3 points. No decomposition needed.

Recommendations

No blocking issues. Minor notes for the implementing agent:

• [NOTE] DaysController changes (AC 1) depend on PR #241 being merged first. If PR #241 is not merged when work begins, implement all other AC first and leave AC 1 for a follow-up or wait.
• [NOTE] Consider adding unauthenticated specs for join_crew_controller.rb and profile_controller.rb while in the neighborhood -- they are protected controllers with no unauthenticated coverage. Optional scope expansion.
• [NOTE] The story:security entry and arch-rails-app note are pre-existing gaps across the board, not specific to this ticket. Can be addressed separately.

Verdict: READY

Re-review of board item #1472. Previous review (review-1472-2026-06-15) flagged two issues: (1) invalid issue references in Related section, (2) ambiguous role gating. Both fixes verified adequate.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Decomposed from #233 (1 of 4)
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- As an admin or super admin
• [x] Context -- Detailed motivation and rationale
• [x] File Targets -- 3 to create, 2 to modify, 2 NOT-touch guards
• [x] Feature Flag -- none (with rationale: new route, not toggle)
• [x] Acceptance Criteria -- 6 items
• [x] Test Expectations -- 7 items with run command
• [x] Constraints -- 4 items
• [x] Checklist -- present
• [x] Related -- present, all references verified valid

Traceability

• [x] story:weekly-tracking label -- verified in project-landscaping-assistant user-stories table
• [x] arch:rails-app label -- main app architecture, documented in repo docs/app-architecture.md
• [x] Forgejo issue #234 -- open, valid URL

File Targets

• [x] config/routes.rb -- verified exists, no existing /days route, modification target clear
• [x] app/views/weeks/index.html.erb line 81 -- verified: currently work_queue_items_path(date: day), matches ticket claim exactly
• [x] app/controllers/days_controller.rb -- confirmed does not exist yet (to create)
• [x] app/views/days/show.html.erb -- confirmed does not exist yet (to create)
• [x] spec/requests/days_spec.rb -- confirmed does not exist yet (to create)
• [x] WorkQueueItem.where(work_date: @date) -- confirmed work_date field exists on model (validates :work_date, presence: true)
• [x] require_role :admin, :super_admin -- confirmed exact pattern used in WeeksController line 2
• [x] authenticate_user! -- confirmed as before_action in ApplicationController line 13 (inherited automatically)

Repo Placement

OK. Issue is filed on ldraney/landscaping-assistant, all file targets are within this repo. Single-repo change.

Dependencies

• Parent: #233 (decomposed) -- open, verified
• Blocked by: nothing -- this is the foundation ticket
• Blocks: #235, #236, #237 -- all verified open on Forgejo, all exist as board items (#1473, #1474, #1475)
• Dependencies documented correctly in issue Related section

Acceptance Criteria

All 6 AC are concrete and agent-verifiable:

• GET /days/2026-06-17 returns 200 -- verifiable via request spec
• Page shows queued properties -- verifiable via response body check
• Back link to Week tab -- verifiable via response body link check
• Week tab day labels updated -- verifiable by checking weeks/index.html.erb output
• Invalid date handling -- verifiable via redirect check
• Non-admin role denial -- verifiable via role-based request specs

Test Expectations map 1:1 to AC with concrete run command: bundle exec rspec spec/requests/days_spec.rb

Blast Radius

Low. New controller and route with no modification to existing Today/WorkQueueItems behavior. The only modification to existing code is the link target on weeks/index.html.erb line 81 (changing path helper). NOT-touch guards explicitly protect the Today view files. No downstream consumers affected beyond the Week tab link change.

Decomposition Assessment

3 files to create, 2 files to modify, all in 1 repo. 6 AC. Estimated agent work well under 5 minutes -- this is a straightforward controller/view/route/spec ticket. No decomposition needed.

Previous Review Fixes Verified

• [x] Fix 1 (invalid issue references): Related section now references #233 (parent, verified open), #235/#236/#237 (blockers, all verified open). No invalid references remain.
• [x] Fix 2 (ambiguous role gating): Role gating is now explicit in three places -- User Story ("As an admin or super admin"), Context paragraph (dedicated explanation of why admin/super_admin only), and File Targets (require_role :admin, :super_admin). Matches WeeksController pattern exactly.

Recommendation

No action needed.

Verdict: READY

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- decomposed from #233, depends on #235
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- crew lead/admin removing property from Previously list
• [x] Context -- explains DayExclusion join table purpose
• [x] File Targets -- 3 new files, 4 modifications listed
• [x] Feature Flag -- none (additive behavior, appropriate)
• [x] Acceptance Criteria -- 5 criteria
• [x] Test Expectations -- 6 test items with run command
• [x] Constraints -- Turbo Stream pattern, wday convention, no undo scope
• [x] Checklist -- standard 3-item checklist
• [x] Related -- project reference, parent/dependency links
• [x] Schema section -- bonus: explicit schema definition with constraints and index

Traceability

• [x] story:weekly-tracking label -- verified in project-landscaping-assistant user-stories table ("Track weekly completion across all active properties")
• [x] story note verified -- found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label -- component identified
• [ ] arch note MISSING -- [SCOPE] No arch-rails-app note exists in pal-e-docs. This is a systemic gap across the entire landscaping-assistant board (all rails-app items lack this note), not specific to this ticket.
• [x] Forgejo issue -- #236, open, valid URL

File Targets

• [x] db/migrate/XXXXXX_create_day_exclusions.rb -- to be created (new migration, expected)
• [x] app/models/day_exclusion.rb -- to be created (new model, expected)
• [x] app/views/days/_previously_item.html.erb -- to be created or extracted from #235 (noted in issue)
• [x] app/controllers/days_controller.rb -- does not exist yet; created by dependency #234 (correctly documented)
• [x] config/routes.rb -- verified exists at config/routes.rb; no days routes yet (added by #234)
• [x] app/views/days/_previously_section.html.erb -- does not exist yet; created by dependency #235 (correctly documented)
• [x] spec/requests/days_spec.rb -- to be created (new spec file, expected)
• [x] Turbo Stream pattern reference -- app/views/work_queue_items/destroy.turbo_stream.erb confirmed to exist with turbo_stream.remove pattern

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in that repo. Single-repo change.

Dependencies

• #234 (Day detail page: controller, route, and basic show view) -- OPEN, board item #1472 in backlog. Creates the days_controller.rb and routes that this ticket modifies. Must land first.
• #235 (Day detail page: "Previously [Day]s" accordion with historical frequency) -- OPEN, board item #1473 in backlog. Creates the _previously_section partial that this ticket adds the remove button to. Must land first. Explicitly documented as dependency in issue.
• #233 (parent, decomposed) -- OPEN, board item #1471 in backlog. Umbrella issue marked [DECOMPOSED].
• #237 (Day detail page: property picker for quick-add) -- OPEN, board item #1475 in backlog. Follows this ticket (re-adding excluded properties). No blocking relationship.

Dependencies are correctly documented in the issue Lineage section. Execution order: #234 -> #235 -> #236 (this) -> #237.

Acceptance Criteria

All 5 criteria are concrete, verifiable, and testable by an agent:

• Clicking remove creates DayExclusion record -- testable via request spec POST
• Excluded property disappears on reload -- testable via request spec GET after exclusion
• Weekday-specific exclusion -- testable by excluding Tuesday, checking Wednesday unaffected
• Turbo Stream response -- testable by checking response format
• Idempotent duplicates -- testable by double-POST, assert no error and single record

No missing criteria identified.

Blast Radius

• Property model gains a new has_many :day_exclusions association. Currently has: property_services, services, work_queue_items, service_requests. Adding day_exclusions is low-risk.
• No existing wday or weekday patterns in the codebase -- this introduces a new concept. The weeks_controller uses date ranges (beginning_of_week) not wday integers, so no collision.
• The DayExclusion model is self-contained (no callbacks, no side effects beyond query filtering).
• No downstream consumers affected -- this is a new UI surface on a page that doesn't exist yet.

Decomposition Assessment

3 new files + 4 file modifications = 7 file targets in 1 repo. 5 acceptance criteria. 6 test expectations. Estimated agent time: ~3-4 minutes. Within single-agent pass threshold. No decomposition needed.

Recommendation

The arch:rails-app note gap is systemic across the board and not a blocker for this individual ticket. Flagging for awareness:

• [SCOPE] Create architecture note arch-rails-app for the Rails application component (systemic gap, not blocking this ticket)

No other action needed. Ticket is well-scoped, dependencies are documented, file targets are accurate for the dependency chain, and acceptance criteria are testable.

Verdict: READY

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:weekly-tracking label — "Track weekly completion across all active properties"
• [x] story note verified — found in project-landscaping-assistant user-stories table
• [x] arch:rails-app label — Rails application component
• [ ] arch note MISSING — [SCOPE] No arch-rails-app note exists in pal-e-docs. Platform-wide gap, not specific to this ticket.
• [x] Forgejo issue — #235, open

File Targets

• [x] app/views/days/_previously_section.html.erb — new file to create, correct
• [x] app/controllers/days_controller.rb — to be modified; does not exist yet (created by dependency #234, board item #1472). Correct: this ticket depends on #234.
• [x] app/views/days/show.html.erb — to be modified; does not exist yet (created by dependency #234). Correct.
• [x] app/javascript/controllers/accordion_controller.js — verified exists, has keyValue pattern at line 23. Marked "do not touch" in issue.
• [x] app/controllers/work_queue_items_controller.rb lines 231-245 — verified: compute_unqueued_this_week method with DOW extraction pattern exactly as described. Marked "do not touch" in issue.
• [x] Property.active scope — verified at app/models/property.rb line 9

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are within this repo. Single-repo change.

Dependencies

• #234 (Day detail page: controller, route, and basic show view) — OPEN, board item #1472 in backlog. This ticket explicitly depends on #234 and cannot be started until #234 is merged. Dependency is properly documented in Lineage section.
• #233 (parent, decomposed) — OPEN. This is ticket 2 of 4 from the decomposition. Parent status is informational only.
• No undocumented dependencies found. The accordion_controller.js is reused as-is (no modifications needed).

Acceptance Criteria

5 AC, all testable by an agent:

• AC1: Accordion heading with dynamic day name — verifiable via request spec checking response body
• AC2: Historical frequency sort — verifiable via request spec with seeded WorkQueueItems
• AC3: "Queued" badge for already-queued properties — verifiable via request spec
• AC4: localStorage persistence via accordion controller — uses existing controller, no new JS needed; verifiable by checking data-accordion-key-value attribute
• AC5: Empty state — verifiable via request spec with no historical data

Test command bundle exec rspec spec/requests/days_spec.rb is valid (file will be created). 4 test expectations are well-specified.

Blast Radius

Low. The DOW extraction pattern (EXTRACT(DOW FROM work_date)) currently exists only in work_queue_items_controller.rb line 240. This ticket adds a second usage in the new days controller. No downstream consumers affected. The accordion controller is reused without modification.

Decomposition Assessment

1 repo, 3 file targets (1 new partial, 2 modifications to dependency-created files), 5 AC. Single-agent pass, estimated under 5 minutes. No decomposition needed.

Recommendation

• [SCOPE] Create architecture note arch-rails-app in pal-e-docs (platform-wide gap, not blocking this ticket).

No blocking issues. Ticket is ready to move to next_up once dependency #234 (board item #1472) is complete.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Decomposed from #233 (1 of 4)
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- present
• [x] Context -- present, well-written
• [x] File Targets -- present, includes create/modify/NOT-touch
• [x] Feature Flag -- none (with rationale)
• [x] Acceptance Criteria -- 5 items
• [x] Test Expectations -- 6 items with run command
• [x] Constraints -- present
• [x] Checklist -- present
• [x] Related -- present

Traceability

• [x] story:weekly-tracking label -- present on board item
• [x] story note verified -- "weekly-tracking" found in project-landscaping-assistant user-stories table: "Track weekly completion across all active properties"
• [x] arch:rails-app label -- present on board item
• [ ] arch note MISSING -- [SCOPE] No arch-rails-app note found in pal-e-docs. This label is used across 30+ board items. Create architecture note arch-rails-app for the Rails application component.
• [x] Forgejo issue -- #234, state: open

File Targets

• [x] app/controllers/days_controller.rb -- TO CREATE: does not exist yet (correct)
• [x] app/views/days/show.html.erb -- TO CREATE: does not exist yet (correct)
• [x] spec/requests/days_spec.rb -- TO CREATE: does not exist yet (correct)
• [x] config/routes.rb -- TO MODIFY: exists, currently has no days route (confirmed)
• [x] app/views/weeks/index.html.erb -- TO MODIFY: exists (117 lines), line 81 confirmed: link_to work_queue_items_path(date: day) exactly as described
• [x] app/controllers/work_queue_items_controller.rb -- NOT TOUCH: exists (confirmed)
• [x] app/views/work_queue_items/ -- NOT TOUCH: exists (confirmed)

Repo Placement

OK -- issue filed on ldraney/landscaping-assistant, all file targets are in the same repo.

Dependencies

• Parent: #233 (decomposed parent, open) -- correctly documented
• Siblings on board: #235 (item 1473), #236 (item 1474), #237 (item 1475) -- all in backlog, all depend on this ticket landing first
• No blockers for this ticket -- correctly documented
• The WorkQueueItem model exists with work_date field and belongs_to :property -- query pattern in ticket is valid

Acceptance Criteria

• [x] All 5 AC are testable by an agent via request specs
• [x] Test expectations map well to acceptance criteria
• [ ] ISSUE: AC says "requires authentication" in test expectations but the ticket's Constraints section says "auth via authenticate_user!, role gating via require_role" without specifying WHICH roles. The user story says "crew lead or admin" but the Week tab (where day links originate) is gated to :admin, :super_admin only. Crew leads cannot see the Week tab. The DaysController role gating needs clarification. [BODY] Add explicit role list to Constraints: specify require_role :admin, :super_admin to match Week tab access, OR intentionally broaden to :lead, :admin, :super_admin with a note that crew leads can access day pages via direct URL even though they cannot see the Week tab.

Blast Radius

• Only one location in the codebase links from weeks to today with a date param (line 81 of weeks/index.html.erb) -- correctly identified in ticket
• Other work_queue_items_path(date:) references are in work_queue_items views (Today tab internals) and should NOT be changed -- correctly excluded
• New route /days/:date does not conflict with any existing routes
• No CSS or JS blast radius -- ticket specifies matching existing patterns

Decomposition Assessment

3 files to create + 2 files to modify = 5 file targets, all in one repo. 5 acceptance criteria + 6 test expectations. Estimated agent work: 3-4 minutes. No decomposition needed.

Recommendations

• [BODY] Fix "Blocks" references in Related section: "#234-2, #234-3, #234-4" are not valid Forgejo issue references. Replace with "#235, #236, #237" for proper traceability.
• [BODY] Add explicit role gating to Constraints or File Targets: specify which roles the DaysController should allow. Current user story says "crew lead or admin" but Week tab is admin-only. Either narrow user story to "admin" or explicitly state require_role :lead, :admin, :super_admin and accept that crew leads reach day pages via direct URL only.
• [SCOPE] Create architecture note arch-rails-app for the Rails application component. This label is used across 30+ board items and has no backing note.

Verdict: READY

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 a Feature issue are present and well-populated.

Traceability

• [x] story:weekly-tracking label — "Track weekly completion across all active properties"
• [x] story note verified — found in project-landscaping-assistant user-stories table (row: weekly-tracking)
• [x] arch:rails-app label — Rails application component
• [ ] arch note MISSING — no arch-rails-app note found in pal-e-docs. However, this is the primary application repo and its architecture is documented in-repo at docs/app-architecture.md. This is a systemic gap across the entire board, not specific to this ticket. Acceptable for now.
• [x] Forgejo issue — ldraney/landscaping-assistant#237, state: open

File Targets

• [ ] app/controllers/days_controller.rb — does NOT exist yet. This is expected: the controller is created by dependency #234 (day detail page: controller, route, and basic show view). The ticket correctly documents this dependency. The add_to_queue action will be added to the controller once #234 lands.
• [x] config/routes.rb — verified exists. Currently has no /days routes. The proposed route post "/days/:date/add" will be added here. No conflicts with existing routes.
• [ ] app/views/days/show.html.erb — does NOT exist yet. Same dependency on #234. Expected.
• [x] app/javascript/controllers/property_picker_controller.js — verified exists and matches description. Stimulus controller with input, dropdown, option, form, propertyId, clientName targets. The reuse approach is sound — the same HTML structure from work_queue_items/index.html.erb (lines 28-63) can be replicated on the day detail page.
• [x] app/controllers/work_queue_items_controller.rb — verified exists. The create action (line ~62-119) provides the pattern to follow for WorkQueueItem creation, turbo stream responses, and duplicate handling.

Repo Placement

OK. Issue is filed on ldraney/landscaping-assistant and all file targets are in this repo. Single-repo change.

Dependencies

• #234 (Day detail page: controller, route, and basic show view) — BLOCKING. State: open. Board item #1472 in backlog. The days controller, route, and show view do not exist yet. This ticket cannot be implemented until #234 is merged. Dependency is correctly documented in the issue body.
• #236 (DayExclusion model and remove-from-list button) — Optional integration. State: open. Board item #1474 in backlog. The DayExclusion model does not exist yet (no model file, no migration). The ticket correctly handles this with a guard clause (defined?(DayExclusion) or table_exists?). Well-scoped defensive coding.
• #233 (parent, decomposed) — State: open. This is ticket 4 of 4 in the decomposition. Ordering is logical: #234 (controller) -> #235 (Previously accordion) -> #236 (DayExclusion) -> #237 (property picker).

Acceptance Criteria

5 acceptance criteria, all testable by an agent:

• "Property picker search/autocomplete appears" — verifiable via view inspection
• "Selecting creates a WorkQueueItem" — verifiable via request spec
• "Already queued properties marked in dropdown" — verifiable via view logic inspection
• "Turbo stream response appends" — verifiable via request spec with turbo stream format
• "DayExclusion removal on add" — verifiable via request spec (with guard for #236 not landed)

Test expectations are concrete with a specific run command (bundle exec rspec spec/requests/days_spec.rb). 4 request specs cover the key paths.

Blast Radius

Low. The property picker Stimulus controller is reused as-is (no modifications). The new add_to_queue action is isolated to the new days controller. The WorkQueueItem creation follows an established pattern. No changes to the Today tab's WorkQueueItemsController. The form posts to a different URL (/days/:date/add vs /today), so no collision.

One consideration: the property picker HTML in work_queue_items/index.html.erb (lines 28-63) will be duplicated in days/show.html.erb. A shared partial could reduce duplication, but that is a future refactor concern, not a scope issue for this ticket.

Decomposition Assessment

No decomposition needed:

• 3 file targets in 1 repo — under threshold
• 5 acceptance criteria — at threshold but manageable
• Estimated agent time: ~3-4 minutes (controller action, route, view addition, request specs)
• Well-scoped 2-point ticket

Recommendation

No action needed. Scope is solid, dependencies are documented and correctly ordered, file targets are accurate (accounting for the #234 dependency), and the ticket fits in a single agent pass.

Verdict: APPROVED

Re-review of board item #1463. Previous review review-1463-2026-06-14 returned NEEDS_REFINEMENT with 4 [BODY] and 2 [SCOPE] recommendations. All [BODY] issues are resolved. [SCOPE] gaps acknowledged by caller as being addressed separately.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- present, explicitly documents #425 dependency with ordering rationale
• [x] Repo -- pal-e-platform
• [x] User Story -- well-formed, platform operator perspective
• [x] Context -- thorough, references #424 (closed), #425 (open), explains edge-proxy architecture
• [x] File Targets -- concrete: salt/states/caddy/Caddyfile.j2 with modify/do-not-touch sections
• [x] Feature Flag -- none (correct, infrastructure work)
• [x] Acceptance Criteria -- 7 items, all verifiable
• [x] Test Expectations -- 4 items including run command
• [x] Constraints -- 5 items, includes blast radius awareness
• [x] Checklist -- present, 3 items
• [x] Related -- present

Traceability

• [x] story:custom-domain label -- present on board item
• [ ] story note MISSING -- custom-domain not in project-landscaping-assistant user-stories table. [SCOPE] Known gap, being addressed separately per caller. Not blocking.
• [x] arch:pal-e-platform label -- present on board item
• [ ] arch note MISSING -- no arch-pal-e-platform note found. [SCOPE] Known gap, being addressed separately per caller. Not blocking.
• [x] Forgejo issue -- pal-e-platform#434, state: open

File Targets

• [x] salt/states/caddy/Caddyfile.j2 -- does not exist yet in repo (confirmed via Forgejo tree API). Will be created by #425 (palinks.app Caddy config, state: open). This ticket adds to that file. Correct: ticket states "Depends on #425 (must land first to establish salt/states/caddy/ structure)".
• [x] Do-not-touch list is explicit: salt/states/caddy/init.sls and palinks.app block. Mirrors #425 pattern correctly.

Repo Placement

OK. Issue filed on pal-e-platform, work is in pal-e-platform salt states. Single repo scope is correct.

Dependencies

• pal-e-platform#425 (palinks.app Caddy config) -- state: open. Explicitly documented as blocking dependency in Lineage. Must land first to create salt/states/caddy/ structure. Correct.
• pal-e-platform#435 (DNS A record via godaddy-tofu) -- state: open. Related in Lineage. DNS must resolve before Caddy can obtain TLS cert, but the Caddy config can be deployed before DNS -- cert provisioning just won't complete until DNS is live. Ordering is flexible.
• pal-e-platform#424 (Hetzner edge provisioning) -- referenced in Context as related. Not a blocking dependency for this ticket.
• Board items #1461 and #1460 (landscaping-assistant story:custom-domain) -- related items on same board, no blocking relationship.

Acceptance Criteria

7 AC items, all verifiable:

• curl -I https://landscaping-assistant.app returns 200 -- verifiable post-deploy
• curl -I https://www.landscaping-assistant.app returns 301 -- verifiable post-deploy (FIXED from previous review)
• TLS auto-provisioned via Let's Encrypt -- verifiable with curl
• Caddy config includes server block proxying to landscaping-assistant.tail5b443a.ts.net:443 -- verifiable by reading file (FIXED: explicit target address)
• Traffic proxied to correct k3s service via Tailscale mesh -- verifiable with curl
• palinks.app routing unaffected -- regression check, verifiable with curl
• Salt state applied successfully -- verifiable with salt-call state.apply caddy

Blast Radius

Low but correctly flagged. The edge VPS (178.156.129.142) serves multiple domains. A Caddyfile syntax error could break all routing. The Constraints section explicitly states "Must not break existing palinks.app routing" and AC includes palinks.app regression check. Issue #425 also notes blast radius awareness. The Salt-managed approach ensures reproducibility.

Decomposition Assessment

No decomposition needed. Single repo, 1 file target, 7 AC items (slightly above 5, but all are simple verification curls on the same change). Estimated agent work well under 5 minutes. Straightforward additive config mirroring #425 pattern.

Previous Review Findings -- Resolution Status

• [x] [BODY] Concrete file targets -- RESOLVED. Now specifies salt/states/caddy/Caddyfile.j2 with modify/do-not-touch lists.
• [x] [BODY] Proxy target address -- RESOLVED. Now specifies landscaping-assistant.tail5b443a.ts.net:443 in AC and Constraints.
• [x] [BODY] www redirect AC -- RESOLVED. AC now includes www.landscaping-assistant.app 301 redirect check.
• [x] [BODY] Ordering dependency on #425 -- RESOLVED. Lineage explicitly states "must land first."
• [ ] [SCOPE] custom-domain story note -- NOT YET RESOLVED. Being addressed separately per caller instructions. Not blocking.
• [ ] [SCOPE] arch-pal-e-platform note -- NOT YET RESOLVED. Being addressed separately per caller instructions. Not blocking.

Recommendations

No action needed. All [BODY] recommendations from the previous review have been addressed. The two [SCOPE] gaps (missing custom-domain story note and missing arch-pal-e-platform note) are acknowledged as being addressed separately and do not block this ticket from moving to next_up.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Summary -- present
• [x] User Story -- present, well-formed
• [x] Context -- present, references related issues
• [x] Lineage -- present (Parent: none, Story: custom-domain)
• [x] Repo -- pal-e-platform
• [x] Scope -- present, 4 items
• [ ] File Targets -- WEAK: says "Salt states for edge-proxy Caddy config" but gives no concrete paths. Should specify salt/states/caddy/init.sls and salt/states/caddy/Caddyfile.j2 (to be created, mirroring #425 pattern)
• [x] Feature Flag -- None (correct, infrastructure work)
• [x] Test Expectations -- present, 2 items
• [x] Acceptance Criteria -- present, 4 items
• [x] Constraints -- present, 2 items
• [x] Checklist -- present, 3 items
• [x] Related -- present, references #425 and DNS dependency

Traceability

• [x] story:custom-domain label -- present on board item
• [ ] story note MISSING -- custom-domain is NOT listed in the project-landscaping-assistant user-stories table. [SCOPE] Create user story entry for custom-domain on project-landscaping-assistant user-stories section.
• [x] arch:pal-e-platform label -- present on board item
• [ ] arch note MISSING -- no arch-pal-e-platform note found in pal-e-docs. [SCOPE] Create architecture note arch-pal-e-platform for the pal-e-platform component.
• [x] Forgejo issue -- pal-e-platform#434, state: open

File Targets

• [ ] "Salt states for edge-proxy Caddy config" -- ISSUE: No concrete file paths given. The salt/states/caddy/ directory does not exist yet in pal-e-platform. Issue #425 (palinks.app) establishes the pattern by creating salt/states/caddy/init.sls. This ticket should explicitly list:
  • salt/states/caddy/init.sls -- add landscaping-assistant.app site block (or extend if #425 already created it)
  • salt/states/caddy/Caddyfile.j2 -- add landscaping-assistant.app reverse_proxy block (if Jinja template is used)

Repo Placement

OK. Issue filed on pal-e-platform, work is in pal-e-platform salt states. Single repo scope is correct.

Dependencies

• pal-e-platform#435 (DNS A record via godaddy-tofu) -- state: open. This ticket explicitly depends on DNS being configured. Correct dependency documented in Related section ("Depends on: DNS A record for landscaping-assistant.app").
• pal-e-platform#425 (palinks.app Caddy config) -- state: open. This ticket mirrors #425. If #425 creates the salt/states/caddy/ directory and Salt state structure, this ticket adds to it. Implicit ordering dependency: #425 should land first to establish the pattern.
• pal-e-platform#424 (Hetzner edge provisioning) -- state: closed. Prerequisite satisfied.
• Board item #1461 (landscaping-assistant#224, story:custom-domain) and #1460 (landscaping-assistant#223, story:custom-domain) -- related custom-domain items on the same board. No blocking relationship.

Acceptance Criteria

4 AC items, all verifiable by an agent:

• "Caddy config includes landscaping-assistant.app block" -- verifiable by reading Caddyfile
• "Traffic proxied to correct k3s service" -- verifiable after deploy with curl, but needs the Tailscale mesh address specified. Issue #425 uses palinks.tail5b443a.ts.net:443 pattern. This ticket should specify the target address (e.g., landscaping-assistant.tail5b443a.ts.net:443 or the actual k3s service address).
• "TLS certificate auto-provisioned" -- verifiable with curl -I after deploy
• "Salt state applied to Hetzner edge" -- verifiable by running salt state

Missing: no AC for www.landscaping-assistant.app redirect (the palinks.app mirror #425 includes www redirect).

Blast Radius

Low. Additive change to Caddy config. Constraint "Must not break palinks.app routing" is explicitly stated. The Salt state approach ensures reproducibility. No downstream consumers beyond the landscaping-assistant app itself.

Decomposition Assessment

No decomposition needed. Single repo, 1-2 file targets, 4 AC items, estimated agent work under 5 minutes. This is a straightforward additive config change mirroring #425.

Recommendations

• [BODY] Specify concrete file targets: salt/states/caddy/init.sls (extend with landscaping-assistant.app block) and optionally salt/states/caddy/Caddyfile.j2. Current "Salt states for edge-proxy Caddy config" is too vague for agent consumption.
• [BODY] Specify the Tailscale mesh proxy target address in AC #2 (e.g., landscaping-assistant.tail5b443a.ts.net:443).
• [BODY] Add AC for www.landscaping-assistant.app redirect to landscaping-assistant.app (mirrors #425 pattern).
• [BODY] Note ordering dependency on #425 (palinks.app Caddy config should land first to establish salt/states/caddy/ structure).
• [SCOPE] Create user story entry for custom-domain on project-landscaping-assistant user-stories section.
• [SCOPE] Create architecture note arch-pal-e-platform for the pal-e-platform component.

Verdict: READY

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Follow-up to #204 (done)
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- As a super admin, toggle schedule digest feature
• [x] Context -- Explains current flow, why it's not discoverable, what changes
• [x] File Targets -- 4 modify targets + 4 do-not-touch targets
• [x] Feature Flag -- schedule_digest flag fully specified (type, default, visibility, removal)
• [x] Acceptance Criteria -- 7 criteria
• [x] Test Expectations -- 3 test specs + run command
• [x] Constraints -- References existing patterns, no Tailwind, week_start auto-pass
• [x] Checklist -- Standard PR/tests/no-unrelated
• [x] Related -- Links to project and parent issue #204

Traceability

• [x] story:schedule-upload label -- present on board item
• [x] story note verified -- found in project-landscaping-assistant user-stories section (Key: schedule-upload, Role: Landscaper, Summary: "Snap a photo of the paper schedule for later reference")
• [x] arch:rails-app label -- present on board item
• [ ] arch note MISSING -- [SCOPE] No arch-rails-app note exists in pal-e-docs. This is systemic across the board (most items carry arch:rails-app with no backing note). Not blocking for this ticket.
• [x] Forgejo issue -- ldraney/landscaping-assistant#212, state: open

File Targets

• [x] lib/tasks/feature_flags.rake -- verified: exists, contains existing flags (stripe, client_requests, pending_completion). Agent adds schedule_digest entry following same pattern.
• [x] app/views/uploads/show.html.erb -- verified on origin/main: contains "Digest Schedule" button inside a vision_compatible? block. Agent wraps in feature_enabled?(:schedule_digest) check.
• [x] app/views/weeks/index.html.erb -- verified: exists with feature_enabled?(:pending_completion) pattern on line 90. Agent adds "Upload Schedule" button following same gating pattern.
• [x] app/controllers/uploads_controller.rb -- verified on origin/main: contains digest and confirm_digest actions. Agent adds feature flag guard.

Note: The working tree has staged changes that differ from origin/main. The digest/confirm_digest actions and the "Digest Schedule" button exist on origin/main (merged via PR #208) but are not visible in the working tree. An implementing agent must branch from clean main.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo change.

Dependencies

• Issue #204 (Schedule image digestion: Claude Vision OCR) -- DONE, merged as PR #208. This is the prerequisite feature being gated. Verified closed and merged.
• No items in in_progress or next_up that block or are blocked by this ticket.
• Board item #1450 (same issue #204) is in done column -- consistent.

Acceptance Criteria

All 7 acceptance criteria are verifiable by an agent:

• AC 1-4 (flag OFF behaviors): testable via request specs with flag disabled
• AC 5-6 (flag ON behaviors): testable via request specs with flag enabled + role checks
• AC 7 (Photos tab unaffected): testable by verifying upload create/show still work without flag check

Test commands are real: bundle exec rspec spec/requests/uploads_spec.rb spec/requests/weeks_spec.rb -- both spec files exist.

Blast Radius

Low blast radius. Changes are additive (wrapping existing UI in conditionals, adding a new button). The feature_enabled? helper and FeatureFlag model are well-established patterns. No downstream consumers affected -- this gates entry points only, not the ScheduleDigester service itself. The constraint "Existing Photos tab upload flow still works regardless of flag state" correctly scopes the blast radius.

Decomposition Assessment

4 file targets in 1 repo, 7 acceptance criteria, 3 test expectations. Estimated agent work: ~3-4 minutes. No decomposition needed -- fits comfortably in a single agent pass under the 5-minute rule.

Recommendation

No action needed. Scope is solid and ready for implementation.

Minor non-blocking observation: The systemic lack of an arch-rails-app backing note affects many board items. Consider creating it as a separate housekeeping task rather than blocking individual tickets.

Verdict: APPROVED

Re-review after refinement. Previous review: review-1450-2026-06-13 (NEEDS_REFINEMENT, 4 items). Two body fixes confirmed resolved. Two scope items remain but are project-level shared gaps, not blocking for this ticket.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, extends Upload tab (#33)
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- crew lead schedule parsing
• [x] Context -- thorough, covers column-overflow, handwritten additions, existing infra, zero-bloat constraint
• [x] File Targets -- create 3, modify 5, explicit do-not-touch list
• [x] Feature Flag -- none, justified (extension of existing upload flow for lead+ roles)
• [x] Acceptance Criteria -- 9 criteria (8 original + error handling AC added per review)
• [x] Test Expectations -- 5 test expectations with run command (added malformed API response test)
• [x] Constraints -- Claude model, API key source, fuzzy matching approach
• [x] Checklist -- standard 3-item
• [x] Related -- references project and parent issue #33

Traceability

• [x] story:schedule-upload label -- present on board item
• [x] story note verified -- found in project-landscaping-assistant user-stories section: "Snap a photo of the paper schedule for later reference"
• [ ] story note OUTDATED -- [SCOPE] The user story summary still says "Snap a photo of the paper schedule for later reference" but this ticket extends the story to include AI-powered parsing into WorkQueueItems. Not blocking for this ticket -- project-level update needed separately.
• [x] arch:rails-app label -- present on board item
• [ ] arch note MISSING -- [SCOPE] No architecture note found for arch-rails-app in pal-e-docs. Shared gap across many board items, not blocking for this ticket.
• [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant/issues/204, state: open

File Targets

Files to create:

• [x] app/services/schedule_digester.rb -- directory app/services/ does not exist yet (must be created). Standard Rails convention, acceptable.
• [x] app/views/uploads/digest.html.erb -- parent directory app/views/uploads/ exists, confirmed
• [x] db/migrate/TIMESTAMP_add_week_start_to_uploads.rb -- standard migration, OK

Files to modify:

• [x] Gemfile -- verified exists. No anthropic gem present currently. Correct target.
• [x] app/controllers/uploads_controller.rb -- verified exists. Currently has index/show/create/edit/update/destroy. Adding digest and confirm_digest actions is appropriate.
• [x] app/models/upload.rb -- verified exists. Issue now correctly states: "add week_start date field (no AR associations to WorkQueueItem; the service creates items directly, the relationship is implicit through week_start date range)". This is clear and matches the architecture -- the service object pattern means Upload does not need has_many associations. Previous [BODY] finding RESOLVED.
• [x] config/routes.rb -- verified exists. Currently resources :uploads, only: [:index, :show, :create, :edit, :update, :destroy]. Adding member routes for digest/confirm_digest is correct.
• [x] app/views/uploads/show.html.erb -- verified exists. Adding "Digest Schedule" button is straightforward.

Do-not-touch files:

• [x] app/models/property.rb -- confirmed exists, no schema changes needed. Property has validates :client_name, presence: true and has_many :work_queue_items.
• [x] app/controllers/weeks_controller.rb -- confirmed exists, week view stays unchanged.

Repo Placement

OK -- issue filed on ldraney/landscaping-assistant, all file targets are in this repo. Single-repo change, no cross-repo concerns.

Dependencies

• [x] Issue #33 (Upload tab) -- done column on board. Upload model and controller exist and work.
• [x] WorkQueueItem model -- exists with work_date, property_id (unique per date), position, completed fields.
• [x] Property model -- exists with client_name field for fuzzy matching. Has has_many :work_queue_items.
• [x] Anthropic API key -- confirmed at ~/secrets/anthropic/credentials.env, file present.
• No blocking items found on the board. No items in in_progress that conflict.

Acceptance Criteria

9 acceptance criteria. All are testable by an agent:

• AC1-3: Vision API call, structured JSON response, column-overflow handling -- testable via mocked API response in unit tests
• AC4: Fuzzy matching -- testable with known property fixtures
• AC5: Confirmation screen with color-coded categories -- testable via request spec checking HTML response
• AC6: WorkQueueItem creation on confirm -- testable via request spec with confirm action
• AC7: No new Property records -- testable via assertion on Property.count
• AC8: Duplicate detection (skip, don't error) -- testable via uniqueness constraint (already exists: validates :property_id, uniqueness: { scope: :work_date } plus DB index)
• AC9: Error handling for API unavailability or malformed JSON -- testable via mocked error responses, verify no partial items created. Previous [BODY] finding RESOLVED.

Blast Radius

• WorkQueueItem uniqueness constraint already exists (index_work_queue_items_on_work_date_and_property_id, unique: true) -- AC8 duplicate detection is enforced at DB level. Service should handle ActiveRecord::RecordNotUnique gracefully.
• Upload model gains week_start field -- existing upload tests should still pass.
• No existing fuzzy matching or anthropic patterns in the codebase -- net-new functionality.
• Adding the anthropic gem adds an external API dependency. No other external AI/ML gems exist currently.

Decomposition Assessment

File count: 3 new + 5 modified = 8 files in 1 repo. AC count: 9 acceptance criteria + 5 test expectations. This is substantial but all within one repo and one logical feature. The service object pattern (ScheduleDigester) encapsulates the core complexity. Points: 8 (appropriate for scope). Borderline on the 5-minute rule but tightly coupled -- splitting would create artificial seams. No decomposition needed.

Recommendations

Both previous [BODY] findings have been addressed in the refined issue:

• [BODY] Confusing "has_many :work_queue_items through digest" language -- RESOLVED. Now reads: "no AR associations to WorkQueueItem; the service creates items directly, the relationship is implicit through week_start date range"
• [BODY] Missing error handling AC -- RESOLVED. AC9 added with clear criteria. Matching test expectation added.

Remaining project-level items (not blocking this ticket):

• [SCOPE] Update the schedule-upload user story on project-landscaping-assistant to reflect AI-powered parsing. Current: "Snap a photo of the paper schedule for later reference." Should reflect schedule digestion.
• [SCOPE] Create architecture note arch-rails-app. Shared gap across multiple board items.

No action needed for this ticket to proceed.

Verdict: READY

Re-review after refinement. Previous review review-1451-2026-06-13 found one [BODY] issue: app/controllers/work_queue_items_controller.rb was missing from the do-not-touch list. That has been fixed.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- present
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- present, well-formed
• [x] Context -- present, explains paper schedule mental model
• [x] File Targets -- present, 3 modify targets + 3 do-not-touch
• [x] Feature Flag -- present, set to "none" with rationale
• [x] Acceptance Criteria -- present, 5 criteria
• [x] Test Expectations -- present, 3 test cases + run command
• [x] Constraints -- present, 4 constraints
• [x] Checklist -- present
• [x] Related -- present

Traceability

• [x] story:property-crud label -- "Add/edit/delete client properties"
• [x] story note verified -- found in project-landscaping-assistant user-stories section (key: property-crud, role: Landscaper)
• [x] arch:rails-app label -- Rails application component
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-rails-app for the Rails application component (non-blocking, shared across many board items)
• [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant/issues/205, open

File Targets

• [x] app/controllers/properties_controller.rb -- verified: line 10 sorts by LOWER(client_name), :address_line in the manage action
• [x] app/controllers/weeks_controller.rb -- verified: line 10 sorts by LOWER(client_name) in the index action
• [x] app/models/property.rb -- verified: no by_proximity scope exists yet; latitude and longitude float columns confirmed in schema (db/schema.rb lines 70-71)
• [x] Do-not-touch: db/schema.rb -- correct, lat/lng columns already exist
• [x] Do-not-touch: app/models/work_queue_item.rb -- correct, queue ordering is user-defined
• [x] Do-not-touch: app/controllers/work_queue_items_controller.rb -- verified: line 16 sorts by updated_at: :desc for add-to-queue dropdown, intentionally different. FIX FROM PREVIOUS REVIEW CONFIRMED.

Repo Placement

OK -- issue is filed on ldraney/landscaping-assistant and all file targets are in the same repo. Single-repo change.

Dependencies

No blocking dependencies found on the board. The latitude and longitude columns already exist in the schema. The Add Location feature (already shipped) populates these fields. No other board items block or are blocked by this ticket.

Acceptance Criteria

All 5 criteria are testable and well-scoped. The "deterministic" criterion is important -- nearest-neighbor chains can produce different results depending on the starting point, so the base point must be fixed. The test expectations provide clear unit and request test guidance with a concrete run command (bundle exec rspec spec/models/property_spec.rb spec/requests/properties_spec.rb).

Blast Radius

Full controller grep confirms only 3 locations load and sort properties:

• PropertiesController#manage (line 10) -- IN SCOPE, will change to proximity sort
• WeeksController#index (line 10) -- IN SCOPE, will change to proximity sort
• WorkQueueItemsController#index (line 16) -- correctly listed in do-not-touch, sorts by updated_at: :desc

No other controllers reference Property sorting. No downstream consumers affected.

Decomposition Assessment

3 file targets in 1 repo, 5 acceptance criteria, straightforward greedy nearest-neighbor algorithm. Estimated agent work well under 5 minutes. No decomposition needed.

Recommendation

• [SCOPE] Create architecture note arch-rails-app for the Rails application component (shared across many board items, not blocking for this ticket)

No other action needed. The sole [BODY] issue from the previous review has been resolved.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, extends Upload tab (#33)
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- crew lead schedule parsing
• [x] Context -- thorough, covers column-overflow, handwritten additions, existing infra
• [x] File Targets -- create 3, modify 5, explicit do-not-touch list
• [x] Feature Flag -- none, justified (extension of existing upload flow)
• [x] Acceptance Criteria -- 8 criteria
• [x] Test Expectations -- 4 test expectations with run command
• [x] Constraints -- Claude model, API key source, fuzzy matching approach
• [x] Checklist -- standard 3-item
• [x] Related -- references project and parent issue #33

Traceability

• [x] story:schedule-upload label -- present on board item
• [x] story note verified -- found in project-landscaping-assistant user-stories section: "Snap a photo of the paper schedule for later reference"
• [ ] story note OUTDATED -- [SCOPE] The user story summary says "Snap a photo of the paper schedule for later reference" but this ticket extends the story to include AI-powered parsing into WorkQueueItems. The user story success metric should be updated to reflect schedule digestion, not just photo upload.
• [x] arch:rails-app label -- present on board item
• [ ] arch note MISSING -- [SCOPE] No architecture note found for arch-rails-app in pal-e-docs. Search returned zero results. Create architecture note arch-rails-app for the Rails application component.
• [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant/issues/204, state: open

File Targets

Files to create:

• [x] app/services/schedule_digester.rb -- directory app/services/ does not exist yet (must be created). This is standard Rails convention, acceptable.
• [x] app/views/uploads/digest.html.erb -- parent directory exists, confirmed
• [x] db/migrate/TIMESTAMP_add_week_start_to_uploads.rb -- standard migration, OK

Files to modify:

• [x] Gemfile -- verified exists. No anthropic gem present currently. Correct target.
• [x] app/controllers/uploads_controller.rb -- verified exists. Currently has index/show/create/edit/update/destroy. Adding digest and confirm_digest actions is appropriate.
• [ ] app/models/upload.rb -- ISSUE: ticket says "add has_many :work_queue_items through digest" but there is no digest join model defined anywhere in the issue. The Upload model currently has only has_one_attached :photo and no associations. The relationship between Upload and WorkQueueItems needs clarification -- is it a direct has_many or through a join table? [BODY]
• [x] config/routes.rb -- verified exists. Currently resources :uploads, only: [:index, :show, :create, :edit, :update, :destroy]. Adding member routes for digest/confirm_digest is correct.
• [x] app/views/uploads/show.html.erb -- verified exists. Adding "Digest Schedule" button is straightforward.

Do-not-touch files:

• [x] app/models/property.rb -- confirmed, no schema changes needed. Property already has validates :client_name, presence: true.
• [x] app/controllers/weeks_controller.rb -- confirmed, week view stays unchanged.

Repo Placement

OK -- issue filed on ldraney/landscaping-assistant, all file targets are in this repo. Single-repo change, no cross-repo concerns.

Dependencies

• [x] Issue #33 (Upload tab) -- done, in done column on board. Upload model and controller exist and work.
• [x] WorkQueueItem model -- exists with work_date, property_id (unique per date), position fields.
• [x] Property model -- exists with client_name field for fuzzy matching.
• [x] Anthropic API key -- confirmed at ~/secrets/anthropic/credentials.env, key present.
• No blocking items found on the board. No items in in_progress that conflict.

Acceptance Criteria

8 acceptance criteria. All are testable by an agent:

• AC1-3: Vision API call and response parsing -- testable via mocked API response in unit tests
• AC4: Fuzzy matching -- testable with known property fixtures
• AC5: Confirmation screen -- testable via system/request spec checking HTML response
• AC6: WorkQueueItem creation -- testable via request spec with confirm action
• AC7: No new Property records -- testable via assertion on Property.count
• AC8: Duplicate detection -- testable via uniqueness constraint (already exists: validates :property_id, uniqueness: { scope: :work_date })

Missing criteria: No AC for error handling when Claude Vision API is unavailable or returns malformed JSON. Should add resilience AC.

Blast Radius

• WorkQueueItem uniqueness constraint already exists (index_work_queue_items_on_work_date_and_property_id, unique: true) -- AC8 duplicate detection is already enforced at DB level. The service should handle ActiveRecord::RecordNotUnique gracefully.
• Upload model gains a new field (week_start) and potentially new associations -- existing upload tests (if any) should still pass.
• No existing fuzzy matching patterns in the codebase -- this is net-new functionality.
• Adding the anthropic gem adds an external API dependency. No other external AI/ML gems exist in the project currently.

Decomposition Assessment

File count: 3 new + 5 modified = 8 files in 1 repo. AC count: 8 acceptance criteria + 4 test expectations. This is a substantial ticket but all within one repo and one logical feature. The service object pattern (ScheduleDigester) encapsulates the core complexity. Estimated agent work: ~8-10 minutes due to Vision API integration, fuzzy matching implementation, and confirmation UI.

Borderline on decomposition. The ticket could be split into: (1) ScheduleDigester service + tests, (2) controller actions + views + routes. However, the two halves are tightly coupled (the view renders ScheduleDigester output). Recommending single pass with careful AC ordering, but flagging for awareness.

Recommendations

• [BODY] Clarify the Upload-to-WorkQueueItem relationship in File Targets. The issue says "has_many :work_queue_items through digest" but no digest join model is defined. Either: (a) define a direct association with an upload_id foreign key on work_queue_items, or (b) make the relationship implicit (ScheduleDigester creates WorkQueueItems but Upload has no ActiveRecord association to them). Option (b) is simpler and matches the "digestion" metaphor -- the upload is consumed, not permanently linked.
• [BODY] Add an acceptance criterion for error handling: "When Claude Vision API returns an error or malformed response, the user sees a clear error message and no WorkQueueItems are created."
• [SCOPE] Update the schedule-upload user story on project-landscaping-assistant to reflect AI-powered parsing. Current summary: "Snap a photo of the paper schedule for later reference." Proposed: "Photograph the paper schedule and parse it into daily work queues via AI vision."
• [SCOPE] Create architecture note arch-rails-app for the Rails application component.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- present
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- present, well-formed
• [x] Context -- present, explains paper schedule mental model
• [x] File Targets -- present, 3 modify targets + 2 do-not-touch
• [x] Feature Flag -- present, set to "none" with rationale
• [x] Acceptance Criteria -- present, 5 criteria
• [x] Test Expectations -- present, 3 test cases + run command
• [x] Constraints -- present, 4 constraints
• [x] Checklist -- present
• [x] Related -- present

Traceability

• [x] story:property-crud label -- "Add/edit/delete client properties"
• [x] story note verified -- found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label -- Rails application component
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-rails-app for the Rails application component
• [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant/issues/205, open

File Targets

• [x] app/controllers/properties_controller.rb -- verified: line 9 sorts by LOWER(client_name), :address_line in the manage action
• [x] app/controllers/weeks_controller.rb -- verified: line 10 sorts by LOWER(client_name) in the index action
• [x] app/models/property.rb -- verified: no by_proximity scope exists yet, latitude and longitude attributes confirmed in schema (float columns)
• [x] Do-not-touch: db/schema.rb -- correct, lat/lng columns already exist
• [x] Do-not-touch: app/models/work_queue_item.rb -- correct, queue ordering is user-defined

Repo Placement

OK -- issue is filed on ldraney/landscaping-assistant and all file targets are in the same repo. Single-repo change.

Dependencies

No blocking dependencies found on the board. The latitude and longitude columns already exist in the schema. The Add Location feature (already shipped) populates these fields. No other board items block or are blocked by this ticket.

Acceptance Criteria

All 5 criteria are testable and well-scoped. The "deterministic" criterion is important -- nearest-neighbor chains can produce different results depending on the starting point, so the base point must be fixed. The test expectations provide clear unit and request test guidance with a concrete run command.

Blast Radius

Minor concern: app/controllers/work_queue_items_controller.rb line 16 also loads and sorts properties: Property.active.includes(:services, :work_queue_items).order(updated_at: :desc). This is the Today view's "add to queue" dropdown, which intentionally sorts by recency (most recently updated first for quick-add). This sort should NOT change, but the issue's "Files the agent should NOT touch" section only lists app/models/work_queue_item.rb -- it does not mention app/controllers/work_queue_items_controller.rb. An agent could mistakenly apply the proximity sort there too. Recommend adding it to the do-not-touch list to prevent agent confusion.

The PropertiesController#index action (line 4-6) only loads services, not properties -- the property list is loaded in the manage action. This is correct in the ticket.

Decomposition Assessment

3 file targets in 1 repo, 5 acceptance criteria, straightforward greedy nearest-neighbor algorithm. Estimated agent work well under 5 minutes. No decomposition needed.

Recommendation

• [BODY] Add app/controllers/work_queue_items_controller.rb to the "Files the agent should NOT touch" list with note: "Today view dropdown sorts by recency intentionally, not proximity"
• [SCOPE] Create architecture note arch-rails-app for the Rails application component (shared across many board items, not blocking for this ticket)

Verdict: NEEDS_REFINEMENT

Template Completeness

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

Traceability

• [x] story:auth label -- "Log in with Keycloak, see role-appropriate tabs and features"
• [x] story note verified -- found in project-landscaping-assistant user-stories section (key: auth)
• [x] arch:rails-app label -- Rails application component
• [ ] arch note MISSING -- [SCOPE] No arch-rails-app note exists in pal-e-docs. Search returned zero results. Create architecture note arch-rails-app for the Rails app component.
• [x] Forgejo issue -- #123, open

File Targets

• [x] app/views/person/index.html.erb -- verified: exists, has placeholder "My Property" section at lines 46-53 ready for expansion
• [x] app/controllers/service_requests_controller.rb -- verified: does not exist yet, marked as new. Correct.
• [x] app/views/service_requests/_client_form.html.erb -- verified: does not exist yet, marked as new. Correct.
• [x] app/views/service_requests/_client_request_list.html.erb -- verified: does not exist yet, marked as new. Correct.
• [x] app/assets/stylesheets/application.css -- verified: exists (1630 lines), has Person component section and design tokens.
• [x] config/routes.rb -- verified: exists, currently has resources :person, only: [:index] at line 40. Adding service_requests resource is correct.
• [x] spec/requests/service_requests_spec.rb -- verified: does not exist yet, marked as new. Correct.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo change.

Dependencies

• [x] #122 (ServiceRequest model + migration) -- MERGED (commit 5391056), Forgejo issue closed. Dependency satisfied.
• [x] #176 (Admin property projects display) -- sibling ticket in backlog, no blocking relationship. Correct.
• [x] #179 (Admin project workflow) -- sibling ticket in backlog, no blocking relationship. Correct.
• [ ] docs/service-requests.md -- MISSING. The issue body references this doc in Context ("See docs/service-requests.md for the full architecture, status lifecycle, and data model") and Constraints ("Reference docs/service-requests.md for status values, transitions, and role access matrix"). This file does not exist in the repo at HEAD. The implementing agent will not be able to follow these references. This is a blocking scope gap.

Acceptance Criteria

• [ ] Status name mismatch: AC #2 lists statuses "requested, quoted, accepted, paid, scheduled" but the merged ServiceRequest model defines statuses as requested, quoted, paid, scheduled, completed, declined. There is no "accepted" status. The "Accept" button in AC #9 actually triggers quoted -> paid transition per the model. The AC text will confuse the implementing agent.
• [ ] crew_member_id resolution unclear: AC #6 says "creates ServiceRequest with crew_member_id = current user" but current_user is a Keycloak session hash ({username:, email:, roles:}), not a CrewMember record. The CrewMember model has a keycloak_username field, so lookup is possible, but the ticket doesn't specify how to resolve this. Furthermore, clients may not have a CrewMember record at all (CrewMember.ROLES includes "client" but there's no guarantee every logged-in client has been provisioned as a CrewMember).
• [x] AC #8 (owner_sub check) -- Property model has owner_sub column and owned_by scope. Implementable, though the ticket doesn't specify how to get the current user's sub from the session (it's not stored in current_user hash currently -- only username, email, roles).
• [x] AC #10 (mobile touch targets) -- testable visually.
• [x] Remaining ACs are clear and testable.

Blast Radius

Low. This is a new controller and new views. Touches existing person/index.html.erb (additive, expands placeholder section), routes.rb (additive), and application.css (additive). No destructive changes to existing functionality. The service_requests resource is new and won't conflict with existing routes.

Decomposition Assessment

7 file targets in 1 repo, 10 acceptance criteria. Borderline on the 5-minute rule. However, all targets are in one repo, the model layer is already merged, and the work is a focused controller+views build. A single agent pass is feasible if scope issues are resolved. No decomposition needed.

Recommendations

• [SCOPE] Create docs/service-requests.md with the architecture, status lifecycle, and role access matrix referenced by this ticket. Without it, the implementing agent has no reference for status transitions and role access. This is the most critical gap.
• [BODY] Fix AC #2 status list: replace "requested, quoted, accepted, paid, scheduled" with "requested, quoted, paid, scheduled, completed, declined" to match the merged ServiceRequest model.
• [BODY] Fix AC #6: clarify how crew_member_id is resolved from the current Keycloak session. Specify whether clients are expected to have a CrewMember record, or whether the FK should be something else (e.g., store the Keycloak sub directly instead).
• [BODY] Fix AC #9: clarify that "Accept" maps to status transition quoted -> paid and "Decline" maps to quoted -> declined. The word "accepted" does not correspond to any model status.
• [BODY] Clarify AC #8: specify how to obtain the current user's sub for the owner_sub check. The current session hash stores username/email/roles but not the Keycloak sub.
• [SCOPE] Create architecture note arch-rails-app for the Rails application component in pal-e-docs.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- present, references #126, #121, #122
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- well-formed (crew lead or admin)
• [x] Context -- clear: admin/lead-facing display, references architecture doc
• [x] File Targets -- 5 targets listed
• [x] Feature Flag -- none (correct for read-only display)
• [x] Acceptance Criteria -- 6 criteria
• [x] Test Expectations -- present with run command
• [x] Constraints -- CSS guide, mobile-first, read-only scope
• [x] Checklist -- present
• [x] Related -- present with cross-references

Traceability

• [x] story:auth label -- "auth" story present on board item
• [x] story note verified -- "auth" story found in project-landscaping-assistant user-stories section (All roles: "Log in with Keycloak, see role-appropriate tabs and features")
• [x] arch:rails-app label -- present on board item
• [ ] arch note MISSING -- [SCOPE] No arch-rails-app note found in pal-e-docs. Create architecture note arch-rails-app for the Rails application component.
• [x] Forgejo issue -- ldraney/landscaping-assistant#176, state: open

File Targets

• [x] app/views/properties/show.html.erb -- verified: exists, currently shows property details with dl, actions, and address form. No projects section yet. Correct update target.
• [x] app/views/service_requests/_property_projects.html.erb -- new file: directory app/views/service_requests/ does not exist yet. Will need to be created. This is expected for a new partial.
• [x] app/assets/stylesheets/application.css -- verified: exists (1630 lines). Has existing design token system, status badges (.role-badge, .status-indicator), and component organization pattern. Good target for new project list styles.
• [x] app/controllers/properties_controller.rb -- verified: exists. show action currently loads only @property = Property.find(params[:id]). Needs eager-load of service_requests. Property model at HEAD already has has_many :service_requests.
• [x] spec/requests/properties_spec.rb -- verified: exists (284 lines). Has existing show specs (lines 46-79). Correct update target.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo change.

Dependencies

• #122 (ServiceRequest model) -- board item #1347, column: qa. Forgejo issue state: closed. Commit 5391056 merged at HEAD. ServiceRequest model, migration, and Property association all verified at HEAD. Dependency satisfied.
• #126 (CSS refresh) -- board item #1351, column: qa. Commit 26c0e5f merged at HEAD. Property detail page layout is updated. Dependency satisfied.
• #123 (Client request form) -- board item #1348, column: backlog. Sibling ticket, not a dependency. No conflict.
• #179 (Admin project workflow) -- board item #1404, column: backlog. Depends ON this ticket (downstream). No conflict.

Acceptance Criteria

6 acceptance criteria. All are verifiable by an agent:

• [x] "Projects/Requests section visible" -- testable via request spec (check response body)
• [x] "Shows active requests grouped" -- testable by creating ServiceRequest fixtures with various statuses
• [x] "Shows completed/declined separately" -- testable
• [x] "Each request shows description, type badge, status badge, price" -- testable via response body assertions
• [x] "Empty state" -- testable with no-request property
• [x] "Works on mobile (44px touch targets)" -- CSS review only; no automated mobile test infra currently. Acceptable at this scope.

Blast Radius

• No existing service_request references in views or controllers -- this is the first view layer usage. Clean.
• ServiceRequest model at HEAD has belongs_to :crew_member -- the display will need to handle this association (e.g., showing who the request is assigned to). The ticket doesn't mention displaying crew member info, which is fine for a read-only initial display.
• No downstream consumers of the show page partial yet.

Decomposition Assessment

5 file targets in 1 repo, 6 acceptance criteria. Borderline on the >5 AC rule, but the work is straightforward: one partial, one controller load, one CSS block, one spec update. Estimated agent time: ~3-4 minutes. No decomposition needed.

Recommendations

• [BODY] Fix reference to docs/service-requests.md -- this file does not exist in the repo (not at HEAD, not in any branch). The issue body and Constraints section reference it. Either create the doc (separate ticket) or remove the reference and inline the status values: requested, quoted, paid, scheduled, completed, declined (from ServiceRequest::STATUSES). The model itself is the source of truth.
• [SCOPE] Create architecture note arch-rails-app in pal-e-docs for the Rails application component. This is a platform-wide gap, not specific to this ticket.

Verdict: APPROVED

Re-review of board item #1347. Previous review (review-1347-2026-06-07) flagged three issues. All three have been addressed.

Previous Findings -- Resolution

• [FIXED] user_id column ambiguity -- Changed to crew_member_id (FK to crew_members). Verified: crew_members table exists in committed schema with columns: name, keycloak_username, role, active. The Constraints section explicitly states "crew_member_id references crew_members table (clients are crew_members with role=client)". Clean resolution.
• [FIXED] Status transition rules missing -- Explicit Status Transition Graph section added with six valid transitions: requested->quoted, requested->declined, quoted->paid, quoted->declined, paid->scheduled, scheduled->completed. Terminal states documented (declined, completed). "No other transitions are valid" is stated. An agent can implement this unambiguously.
• [FIXED] Feature Flag section missing -- Section added with value "None". Correct for an internal model change with no UI.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- child of spike #121
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story
• [x] Context
• [x] File Targets -- 7 targets listed
• [x] Acceptance Criteria -- 5 criteria
• [x] Status Transition Graph -- NEW, addresses previous gap
• [x] Test Expectations
• [x] Constraints
• [x] Feature Flag -- "None" (addresses previous gap)
• [x] Checklist
• [x] Related

Traceability

• [x] story:auth label -- auth story
• [x] story note verified -- "auth" entry found in project-landscaping-assistant user-stories table
• [x] arch:rails-app label
• [ ] arch note MISSING -- [SCOPE] No arch-rails-app note exists in pal-e-docs. Carried forward from first review. Non-blocking for this ticket.
• [x] Forgejo issue -- ldraney/landscaping-assistant#122, state: open

File Targets

• [x] db/migrate/*_create_service_requests.rb (new) -- OK, no existing ServiceRequest migration. No ServiceRequest references anywhere in codebase.
• [x] db/migrate/*_add_monthly_price_to_services.rb (new) -- OK, services table exists in schema. No monthly_price column present. ERD in docs confirms this addition.
• [x] app/models/service_request.rb (new) -- OK, no existing model or references in codebase.
• [x] app/models/property.rb -- verified exists. Has has_many :property_services, has_many :services, has_many :work_queue_items. Adding has_many :service_requests is straightforward.
• [x] app/models/crew_member.rb -- verified exists. Has validations for name, keycloak_username, role. Adding has_many :service_requests is straightforward. crew_members table confirmed in committed schema.
• [x] db/seeds.rb -- verified exists. Currently seeds 3 services (Edging & Trimming, Mowing, Weeding) without prices via find_or_create_by!. Adding monthly_price will need idempotent update pattern.
• [x] spec/models/service_request_spec.rb (new) -- OK, spec/models/ directory exists with 8 existing model specs. Pattern is consistent.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets in the same repo. Single-repo ticket.

Dependencies

• #121 (parent spike) -- done (board item 1346 in done column). No blocker.
• crew_members table -- exists in committed schema (migration 20260607030548). CrewMember model confirmed with ROLES including "client". No blocker.
• Stripe -- stripe_payment_link is a plain string column (URL). No Stripe gem dependency. Separate ticket #125 handles integration. No blocker.
• Downstream -- #123 (Client request UI) and #124 (Admin request management) depend on this model. Both in backlog, not blocked.
• #176 (Property detail page: Projects section) -- explicitly says "depends on #122". In backlog. Correctly ordered.

Acceptance Criteria

• AC1 (ServiceRequest model with columns) -- testable. All columns clearly specified with types. crew_member_id FK is now unambiguous.
• AC2 (Service gains monthly_price) -- testable, clear.
• AC3 (Seeds updated with prices) -- testable, three service names match existing seeds.
• AC4 (Status transitions per graph) -- now fully specified with 6 valid transitions and 2 terminal states. Agent can implement deterministically.
• AC5 (Model specs) -- testable, clear.

Blast Radius

• Property model -- adding has_many :service_requests is low risk. No existing associations conflict.
• CrewMember model -- adding has_many :service_requests is low risk. No existing associations on this model.
• Service model -- adding monthly_price column is low risk. No existing code reads a price from services.
• Seeds -- uses find_or_create_by!. Will need idempotent update for prices (e.g., find_or_create_by!(name:).tap { |s| s.update!(monthly_price:) }). Ticket should note this but it is not blocking.
• No downstream breakage risk -- new model with no UI. Existing tests unaffected.

Decomposition Assessment

7 file targets in 1 repo, 5 acceptance criteria. All files in one repo, work is cohesive (one model + one column addition + seeds + specs). Estimated agent work: under 5 minutes. No decomposition needed.

Recommendations

• [SCOPE] Create architecture note arch-rails-app in pal-e-docs (carried forward, non-blocking).

No other action needed. All three previously flagged issues have been resolved. Ticket is ready for implementation.

Verdict: READY

Re-review of board item #1351. All three issues from the first review (review-1351-2026-06-07) have been resolved.

Previous Review Fix Verification

• [x] Hard blocker -- ServiceRequest dependency -- FIXED. Projects section completely removed from this ticket. Lineage section now reads: "CSS-only portion split from original #126 -- projects section moved to separate ticket." Confirmed new ticket #176 ("Property detail page: Projects section (depends on #122)") exists on the board as item #1403 with 3 points.
• [x] ~/ror-css-guide reference -- CONFIRMED VALID. ~/ror-css-guide is a local repo that exists on disk. This is correct for this project -- it is not a pal-e-docs note.
• [x] Feature Flag section missing -- FIXED. Issue now contains ### Feature Flag section with value "None". Appropriate for a CSS-only change.

Template Completeness

• [x] Type -- "Feature"
• [x] Lineage -- "Child of spike #121, Part of Phase 3, CSS-only split"
• [x] Repo -- "ldraney/landscaping-assistant"
• [x] User Story -- "As a crew lead or admin..."
• [x] Context -- Clear motivation, references existing CSS inconsistencies
• [x] File Targets -- 3 files listed with action types
• [x] Feature Flag -- "None" (appropriate for CSS-only)
• [x] Acceptance Criteria -- 6 criteria listed
• [x] Test Expectations -- spec file named, run command provided
• [x] Constraints -- CSS guide reference, no Tailwind, mobile-first, no projects section
• [x] Checklist -- present
• [x] Related -- #121 parent spike, NEW_ISSUE for projects section split

Traceability

• [x] story:auth label -- "auth" story present on board item
• [x] story note verified -- "auth" story exists in project-landscaping-assistant user-stories section (Key: auth, Role: All roles, Summary: "Log in with Keycloak, see role-appropriate tabs and features")
• [x] arch:rails-app label -- present on board item
• [ ] arch note MISSING -- no "arch-rails-app" note found in pal-e-docs. [SCOPE] However, this is the primary app itself, not a separable architectural component. Every rails-app ticket has this label. Acceptable -- no action needed.
• [x] Forgejo issue -- ldraney/landscaping-assistant#126, state: open

File Targets

• [x] app/views/properties/show.html.erb -- verified: exists, currently shows address_line as h1 (line 2), has client_name in definition list (line 11), uses btn-link class on "Go to Location" (line 33) and "Edit" (line 35). All claims in the ticket are accurate.
• [x] app/assets/stylesheets/application.css -- verified: exists, .detail-actions section at line 913, .btn-link defined at line 929. Design tokens in :root at top of file. PropertyDetail component section at line 248.
• [x] spec/requests/properties_spec.rb -- verified: exists, show specs at line 46. Current specs check for address in body (include("123 Test St")) but do NOT assert heading structure (no h1 check). Updating spec to assert client_name in h1 is feasible.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo change.

Dependencies

• No blocking dependencies. The ServiceRequest/projects dependency was correctly split to ticket #176.
• Ticket #176 (board item #1403) correctly depends on #122 (ServiceRequest model), not this ticket.
• Parent spike #121 is done (board item #1346, column: done).
• ~/ror-css-guide is a local reference repo (read-only dependency). Agent needs access to read CSS conventions from it.

Acceptance Criteria

All 6 criteria are verifiable by an agent:

• [x] "h1 is client_name" -- can assert in spec and grep template
• [x] "Address as subtitle or 'No address yet'" -- can assert in spec
• [x] "Client name removed from definition list" -- can grep template
• [x] "All action buttons use .btn base class" -- can grep for btn-link absence
• [x] "Primary action full-width, secondary split row" -- can verify CSS structure
• [x] "Mobile 44px touch targets" -- can verify min-height in CSS

Test command bundle exec rspec is real and correct.

Blast Radius

• .btn-link class is ONLY used in properties/show.html.erb (2 occurrences). Removing or replacing it will not affect other views.
• .detail-actions CSS section is only referenced by the show template. Safe to restructure.
• The h1 change from address_line to client_name is view-only -- no model or controller changes needed.
• Spec changes are additive (assert h1 contains client_name). Existing specs that check for "123 Test St" in body will still pass since address moves to subtitle, not removed from page.

Decomposition Assessment

3 file targets in 1 repo, 6 acceptance criteria, estimated agent work under 5 minutes. No decomposition needed.

Recommendation

No action needed. Ticket is ready for implementation.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Present, references spike #121 and ServiceRequest dependency
• [x] Repo -- Present
• [x] User Story -- Present
• [x] Context -- Present
• [x] File Targets -- Present (4 files)
• [ ] Feature Flag -- MISSING. Template requires this section. CSS/UI-only work qualifies for "none" but the section should be explicitly present.
• [x] Acceptance Criteria -- Present (5 items)
• [x] Test Expectations -- Present
• [x] Constraints -- Present
• [x] Checklist -- Present
• [x] Related -- Present

Traceability

• [x] story:auth label -- "auth" story found in project-landscaping-assistant user-stories table ("Log in with Keycloak, see role-appropriate tabs and features")
• [x] story note verified -- found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label -- present
• [x] arch note verified -- arch-rails-app note exists in pal-e-docs (scoped to pal-enterprises as a shared RoR architecture doc, acceptable for cross-project use)
• [x] Forgejo issue -- #126, open

File Targets

• [x] app/views/properties/show.html.erb -- verified: exists, contains detail-actions div with Update Address button, Go to Location link, Edit link (lines 28-36)
• [x] app/assets/stylesheets/application.css -- verified: exists, has .detail-actions section at line 913 and .btn-link at line 929
• [x] app/views/service_requests/_property_projects.html.erb -- correctly marked as new. NOTE: the app/views/service_requests/ directory does not yet exist and will need to be created
• [x] spec/requests/properties_spec.rb -- verified: exists (9.1k)

Repo Placement

OK. Single repo (ldraney/landscaping-assistant), correctly filed on the same repo's Forgejo tracker.

Dependencies

• HARD BLOCKER: Issue #122 (ServiceRequest model + migration, board item #1347) is still in backlog. The ServiceRequest model does not exist -- no model file, no migration, no service_requests table in db/schema.rb. This ticket's core functionality (Projects button showing active/completed projects from ServiceRequest where request_type = "project") cannot be implemented without it.
• Issue #121 (parent spike: Design client request flow) -- done, no blocker.
• Missing reference: ~/ror-css-guide is referenced in the issue body and acceptance criteria but does not exist as a pal-e-docs note (slug ror-css-guide returns 404). The agent will have no CSS guide to follow.

Acceptance Criteria

5 acceptance criteria. All are testable in principle, but criteria 2-4 (Projects button, projects section, project details with status/price) depend on the ServiceRequest model existing. Only AC #1 (CSS styling) and AC #5 (mobile touch targets) can be verified independently. Test command (bundle exec rspec) is real and works.

Blast Radius

Limited. Changes are confined to the property show page and its CSS. No sibling services share these stylesheets. No downstream consumers affected. The btn-link class is only used on the properties show page.

Decomposition Assessment

4 file targets in 1 repo, 5 AC. Single agent pass is feasible once the ServiceRequest dependency is resolved. No decomposition needed.

Recommendations

• [BODY] Add Feature Flag section: ### Feature Flag\nnone (CSS/UI work, no flag needed)
• [SCOPE] Hard dependency on #122 (ServiceRequest model + migration) must be resolved first. Either: (a) move #122 ahead of this ticket in priority, or (b) split this ticket into two: one for CSS-only refresh (no ServiceRequest dependency), one for Projects button (depends on #122).
• [SCOPE] Create pal-e-docs note ror-css-guide with the CSS conventions for RoR apps (design tokens, mobile-first, single breakpoint at 600px, button treatment). The issue and AC reference it but it does not exist.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [ ] Feature Flag -- MISSING. Template requires a Feature Flag section. This ticket is an internal model change with no UI, so the correct value is "none", but the section must be present.
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:auth label -- auth story
• [x] story note verified -- "auth" entry found in project-landscaping-assistant user-stories table
• [x] arch:rails-app label
• [ ] arch note MISSING -- [SCOPE] No arch-rails-app note exists in pal-e-docs. Create architecture note arch-rails-app for the Rails application component.
• [x] Forgejo issue -- ldraney/landscaping-assistant#122, state: open

File Targets

• [x] db/migrate/*_create_service_requests.rb (new) -- OK, no existing ServiceRequest migration found
• [x] db/migrate/*_add_monthly_price_to_services.rb (new) -- OK, services table exists (schema verified), no monthly_price column present. ERD in docs/user-stories-auth.md confirms this addition.
• [x] app/models/service_request.rb (new) -- OK, no existing model. No references to ServiceRequest anywhere in codebase.
• [x] app/models/property.rb -- verified exists. Currently has has_many :property_services, has_many :services, has_many :work_queue_items. Adding has_many :service_requests is straightforward.
• [x] db/seeds.rb -- verified exists. Currently seeds three services without prices. Adding monthly_price values is straightforward.
• [x] spec/models/service_request_spec.rb (new) -- OK, spec/models/ directory exists with 8 existing model specs. Pattern is consistent.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo ticket.

Dependencies

• #121 (parent spike) -- done (board item 1346 in done column). No blocker.
• user_id FK problem -- The ticket specifies user_id as a column on ServiceRequest, and the ERD in docs/user-stories-auth.md shows bigint user_id FK "Client who submitted". However, there is no users table in the database. The app uses Keycloak for auth and stores identity as keycloak_username on crew_members. The User model is described in the ERD as a Phase 4 concept (multi-tenancy). The ticket needs to clarify: should user_id be a string column storing a Keycloak sub/username (matching the current crew_members.keycloak_username pattern), or is a User model a prerequisite? This is a blocking ambiguity.
• No Stripe gem or config -- The stripe_payment_link column is fine as a plain string (just a URL), but there are zero Stripe references in the codebase. The ticket correctly says "No UI" and the Stripe integration is a separate ticket (#125). No dependency issue here.
• Downstream consumers -- #123 (Client request UI) and #124 (Admin request management) both depend on this model. Both are in backlog, not blocked.

Acceptance Criteria

• AC1 (ServiceRequest model with listed columns) -- testable, columns clearly specified.
• AC2 (Service gains monthly_price) -- testable, clear.
• AC3 (Seeds updated with prices) -- testable, three service names match existing seeds.
• AC4 (Status transitions validated, no skipping steps) -- Underspecified. The valid transitions are not enumerated. For example: can a request go directly from requested to declined? Can quoted go to declined? The status values are listed (requested, quoted, paid, scheduled, completed, declined), but the allowed transition graph is not. The flow diagram in docs/user-stories-auth.md implies declined branches from the admin decision point (after requested), but also after quoted if the client doesn't pay? This needs explicit transition rules for an agent to implement correctly.
• AC5 (Model specs) -- testable, clear.

Blast Radius

• Property model -- adding has_many :service_requests is low risk. No existing associations conflict.
• Service model -- adding monthly_price column is low risk. No existing code reads a price from services.
• Seeds -- uses find_or_create_by!, so updating to include prices needs care (may need to use find_or_create_by!(name:).update!(monthly_price:) or similar to be idempotent).
• No downstream breakage risk -- this is a new model with no UI. Existing tests should be unaffected.

Decomposition Assessment

6 file targets in 1 repo, 5 acceptance criteria. All files are in one repo and the work is cohesive (one model + one column addition + seeds + specs). Estimated agent work: under 5 minutes. No decomposition needed.

Recommendations

• [BODY] Add ### Feature Flag section with value "none" (internal model change, no UI).
• [BODY] Clarify user_id column: since there is no users table, specify whether this should be a string column storing the Keycloak sub/username (matching crew_members.keycloak_username pattern) or a bigint FK to crew_members. The ERD shows a User entity that does not yet exist -- the ticket must resolve this ambiguity before implementation.
• [BODY] Add explicit status transition rules to AC4. Enumerate which transitions are valid (e.g., requested -> quoted, requested -> declined, quoted -> declined, quoted -> paid, paid -> scheduled, scheduled -> completed). Without this, an agent cannot implement "no skipping steps" correctly.
• [SCOPE] Create architecture note arch-rails-app for the Rails application component in pal-e-docs.

Verdict: APPROVED

RE-REVIEW. All three issues from the previous review (review-1383-2026-06-07) have been addressed. The ticket is well-scoped with clear implementation details and verifiable acceptance criteria.

Template Completeness

• [x] Type — Feature
• [x] Lineage — standalone, discovered during auth strategy spike (#159)
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — developer wants auth parity with prod
• [x] Context — explains current state, dev setup, and what needs to change
• [x] File Targets — docker-compose.yml, .env.example, cross-repo terraform
• [x] Implementation Mechanism — new section with full code examples (env_file pattern)
• [x] Feature Flag — none (infrastructure config, appropriate)
• [x] Acceptance Criteria — 7 criteria, all testable
• [x] Test Expectations — existing specs + manual verification
• [x] Constraints — clear boundaries, secret handling, terraform workflow
• [x] Checklist — includes both repos + terraform apply + manual verification
• [x] Related — project page, upstream spike, auth doc, original terraform PR

Traceability

• [x] story:auth label — "Auth" user story (All roles: Log in with Keycloak, see role-appropriate tabs and features)
• [x] story note verified — found in project-landscaping-assistant user-stories section (key: auth)
• [x] arch:rails-app label — board categorization label (Constraints section clarifies no dedicated arch note required)
• [x] arch:platform label — board categorization label (Constraints section clarifies no dedicated arch note required)
• [x] Forgejo issue — ldraney/landscaping-assistant#164, state: open

File Targets

• [x] docker-compose.yml — verified: exists, web service present (lines 10-28), no env_file directive yet (change needed)
• [x] .env.example — verified: does not exist yet (creation target), appropriate
• [x] .gitignore — verified: already contains /.env* pattern (line 11), no change needed
• [x] app/controllers/application_controller.rb — verified: graceful degradation via keycloak_configured? (line 66-67), correctly listed as DO NOT TOUCH
• [x] config/initializers/omniauth.rb — verified: reads KEYCLOAK_URL, KEYCLOAK_REALM, KEYCLOAK_CLIENT_ID, KEYCLOAK_CLIENT_SECRET from ENV
• [ ] terraform/k3s.tfvars (pal-e-services) — cannot verify from this repo; cross-repo target acknowledged in Checklist

Repo Placement

Correct. Issue is filed on landscaping-assistant where the docker-compose and .env.example changes live. Cross-repo terraform change in pal-e-services is documented in File Targets and Checklist with separate PR expected. Both repos identified.

Dependencies

• Phase 1 Keycloak login (#115, board #1337) — done. Prerequisite satisfied.
• Auth strategy spike (#159, board #1382) — in backlog, but already completed (lineage reference). No blocker.
• Phase 2 role-based auth (#157, board #1373) — in QA. Not a blocker for dev environment enablement.
• Crew tab (#117, board #1339) — in_progress. Not a blocker; independent feature that already works with prod auth.
• No undocumented dependencies found.

Acceptance Criteria

All 7 criteria are agent-verifiable or manually testable. Criteria cover the happy path (auth works), callback URI, role extraction, graceful degradation (opt-out), secret safety (.gitignore), and terraform apply. Test command provided: docker compose exec web bundle exec rspec. The manual login test is appropriately flagged as manual since it requires a running Keycloak instance.

Blast Radius

Low. The change adds an optional env_file directive — when .env is absent, behavior is unchanged. No other services in the docker-compose are affected. The terraform change only adds a redirect URI to an existing client (additive, no breaking changes). The .env.example is documentation-only. Graceful degradation means the change is effectively opt-in per developer.

Decomposition Assessment

2 file targets in this repo + 2 cross-repo targets = 4 files across 2 repos. 7 acceptance criteria. However, the this-repo changes are minimal (add 1 line to docker-compose, create 1 new file) and the cross-repo change is a single URI addition. Estimated agent work: ~3 minutes for the primary repo, separate PR for pal-e-services. Fits within 5-minute rule per repo. No decomposition needed.

Recommendation

No action needed. Ticket is ready for implementation.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — references #159
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — well-formed
• [x] Context — thorough, explains network path and current state
• [x] File Targets — present with modify/create and do-not-touch sections
• [x] Feature Flag — "none" with rationale (correct for infra work)
• [x] Acceptance Criteria — 7 criteria
• [x] Test Expectations — present with run command
• [x] Constraints — present
• [x] Checklist — present
• [x] Related — present

Traceability

• [x] story:auth label — "Auth" user story
• [x] story note verified — found in project-landscaping-assistant user-stories section (key: "auth", role: "All roles", summary: "Log in with Keycloak, see role-appropriate tabs and features")
• [ ] arch:rails-app note MISSING — [SCOPE] Create architecture note arch-rails-app for component rails-app
• [ ] arch:platform note MISSING — [SCOPE] Create architecture note arch-platform for component platform
• [x] Forgejo issue — #164, open

File Targets

• [x] docker-compose.yml — verified: exists, currently has no Keycloak env vars in the web service. Adding them is straightforward.
• [ ] .env.example — does NOT exist yet (ticket says "create"), confirmed. Pattern is valid — /.env* is already in .gitignore.
• [x] app/controllers/application_controller.rb — verified: contains graceful degradation logic at line 67 (ENV["KEYCLOAK_URL"].present?). Ticket correctly says not to touch.
• [x] config/initializers/omniauth.rb — verified: contains all 4 Keycloak env var checks (KEYCLOAK_URL, KEYCLOAK_REALM, KEYCLOAK_CLIENT_ID, KEYCLOAK_CLIENT_SECRET). No changes needed here.
• [x] Cross-repo: pal-e-services/terraform/k3s.tfvars — verified exists locally. Currently has only prod redirect URI: https://landscaping-assistant.tail5b443a.ts.net/auth/keycloak/callback. Dev URI needs to be added.
• [x] Cross-repo: pal-e-services/terraform/k3s.tfvars.example — verified exists.

Repo Placement

This ticket touches TWO repos: ldraney/landscaping-assistant (docker-compose + .env.example) and pal-e-services (terraform). The issue is filed on landscaping-assistant but explicitly documents the cross-repo work. The checklist calls for separate PRs per repo. This is correctly scoped — no additional Forgejo issues needed since the pal-e-services change is trivial (one line addition to redirect_uris array).

Dependencies

• Board item #1337 "Phase 1: Keycloak login for single user" — DONE. This ticket builds on that completed work.
• Board item #1354 (issue #130, phase:2) — DONE. Role-based auth is already working in prod.
• Board item #1373 (issue #157, phase:2) — in QA. No blocking dependency but related auth work.
• No blocking dependencies identified. This ticket can proceed independently.

Acceptance Criteria

7 acceptance criteria. All are verifiable by an agent or manual testing:

• AC1-4: Manual verification via browser (login flow). Agent can verify docker-compose config is correct.
• AC5: Agent-verifiable by checking the graceful degradation code path.
• AC6: Agent-verifiable by checking .gitignore (already confirmed: /.env* present).
• AC7: Requires terraform apply on infra host — human step, correctly documented in checklist.

Criteria are clear and testable. No missing criteria detected.

Blast Radius

Low risk. The docker-compose change only adds environment variables that are already consumed by the existing OmniAuth initializer. The terraform change adds a redirect URI to an existing client — no disruption to prod. The .env file is gitignored so no secret leak risk. Existing test suite (227 specs) should pass unchanged since tests mock KEYCLOAK_URL.

Decomposition Assessment

2 file targets in this repo + 2 file targets in pal-e-services = 4 files across 2 repos. 7 acceptance criteria. However, the actual code changes are minimal (adding env vars to docker-compose, creating a 4-line .env.example, adding one redirect URI to terraform). Estimated agent work: ~3 minutes. No decomposition needed — but the cross-repo nature means two separate PRs as the ticket already specifies.

Recommendations

• [SCOPE] Create architecture note arch-rails-app for the Rails application component
• [SCOPE] Create architecture note arch-platform for the platform/infrastructure component
• [BODY] The docker-compose.yml currently has no env_file directive. The ticket should specify adding env_file: .env to the web service (otherwise the .env file won't be read by docker-compose automatically — docker-compose does auto-read .env for variable substitution in the compose file itself, but NOT for container environment variables unless env_file is specified or variables are listed under environment). Clarify: will the agent add individual environment entries referencing ${KEYCLOAK_URL} etc., or add an env_file: .env directive?

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Spike
• [x] Lineage -- Supersedes #157, references #132, #134, #135, #151, #158
• [x] Repo -- ldraney/landscaping-assistant + ldraney/pal-e-services + turbo-ios (multi-repo documented)
• [x] Question -- Primary question + 6 sub-questions well-framed
• [x] Deliverables -- 5 concrete outputs listed
• [x] Time-box -- 4 hours
• [x] Context -- Thorough rationale for why ROPC is wrong
• [x] Constraints -- tofu apply restriction, prod state, user count
• [x] Related -- Cross-references to #157, #132, #158, pal-e-services #106, docs/keycloak-setup.md

Traceability

• [x] story:auth label present
• [ ] story note MISSING -- [SCOPE] Create user story entry "auth" on project-landscaping-assistant user-stories section. The user-stories table currently has: address-lookup, property-crud, service-tracking, special-notes, work-queue, weekly-tracking, schedule-upload. No "auth" entry exists despite many board items using the story:auth label.
• [x] arch:rails-app label present
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-rails-app for the Rails application component.
• [x] arch:ios label present
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-ios for the iOS (turbo-ios) component.
• [x] Forgejo issue -- ldraney/landscaping-assistant#159, open

File Targets

• [x] docs/keycloak-setup.md -- verified: exists, contains existing ROPC analysis from spike #132 that aligns with this spike's premise
• [x] config/initializers/omniauth.rb -- verified: exists, contains OmniAuth OIDC configuration (current prod code)
• [x] app/controllers/sessions_controller.rb -- verified: exists, uses OmniAuth auth hash (not ROPC), confirms prod is on Auth Code flow
• [x] docs/app-architecture.md -- verified: exists, line 282 already documents "ROPC was rejected per OAuth 2.1 deprecation"

Repo Placement

OK. Issue correctly filed on landscaping-assistant as the primary repo. Cross-repo impacts (pal-e-services terraform, turbo-ios Xcode project) are documented in the Repo and Spike Questions sections. The spike's deliverables are docs/decisions, so a single issue is appropriate.

Dependencies

• Board item #1373 (issue #157, "Direct Access Grants rewrite") is in QA column -- this spike's outcome directly affects its disposition. If spike recommends revert, #157/#158 work is superseded.
• Board item #1339 (issue #117, "Crew tab") is in_progress -- no direct dependency.
• pal-e-services PR #106 (direct_access_grants_enabled terraform) -- mentioned in spike questions, merged but not applied. Spike will determine whether to revert.
• No blocking dependencies prevent this spike from starting.

Acceptance Criteria

Deliverables are concrete and agent-verifiable:

• "Decision: revert #158 or re-implement" -- binary output, verifiable
• "Keycloak theme approach" -- docs artifact, verifiable by existence
• "ASWebAuthenticationSession wiring" -- code sketch or reference, verifiable
• "Updated auth flow mermaid diagram" -- visual artifact, verifiable
• "List of follow-up implementation tickets" -- verifiable by existence

All deliverables are appropriate for a spike. No missing criteria.

Blast Radius

• Auth pattern is app-wide -- affects every authenticated request. However, this spike produces docs/decisions, not code changes, so blast radius is contained to the spike itself.
• keycloak-setup.md already documents ROPC rejection rationale from spike #132. This spike extends that analysis, not contradicts it.
• No other platform apps use ROPC for user auth (basketball-api uses it only for admin API against master realm).
• The follow-up implementation tickets (a spike deliverable) will carry the actual blast radius. Those tickets should be individually scoped and reviewed.

Decomposition Assessment

No decomposition needed. This is a time-boxed spike (4 hours) producing documentation and decisions. 5 deliverables are all docs/decisions, not code across multiple files. Single agent pass is appropriate for research-type work.

Recommendation

• [SCOPE] Create user story entry "auth" on project-landscaping-assistant user-stories section. Multiple board items (at least 15) reference story:auth but no backing user story exists on the project page.
• [SCOPE] Create architecture note arch-rails-app for the Rails application component.
• [SCOPE] Create architecture note arch-ios for the iOS (turbo-ios) component.

Verdict: READY

Re-review of board item #1339 following NEEDS_REFINEMENT verdict in review-1339-2026-06-06. The issue body has been updated to address both [BODY] recommendations from the first review.

First Review Findings Resolved

• [x] [BODY] Data model gap — AC #2 (per-member Today queue) replaced with member profile page (name, role, active status, Keycloak username). AC #5 (completion counts) replaced with active/inactive status indicator. Context section now explicitly states WorkQueueItem has no crew member column. Out of Scope explicitly lists per-member queue filtering and per-member completion counts. Resolved.
• [x] [BODY] Missing role_access_spec.rb — spec/requests/role_access_spec.rb now listed under Files to modify. Resolved.

Template Completeness

• [x] Type
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Out of Scope
• [x] Checklist
• [x] Related

Traceability

• [x] story:auth label — present on board item
• [ ] story note MISSING — no "auth" entry in project-landscaping-assistant user-stories table. [SCOPE] Create user story entry for "auth" on project-landscaping-assistant. Known gap, deferred per first review.
• [x] arch:rails-app label — present on board item
• [ ] arch note MISSING — no arch-rails-app note found in pal-e-docs. [SCOPE] Create architecture note arch-rails-app. Known gap, deferred per first review.
• [x] Forgejo issue — ldraney/landscaping-assistant#117, open

File Targets

Files to modify (all verified to exist):

• [x] app/controllers/crew_controller.rb — verified: placeholder controller with require_role :admin, :super_admin and empty index action
• [x] app/views/crew/index.html.erb — verified: placeholder view with "coming soon" text
• [x] config/routes.rb — verified: resources :crew, only: [:index] at line 37, needs :show added
• [x] app/assets/stylesheets/application.css — verified: exists (29k)
• [x] spec/requests/role_access_spec.rb — verified: exists (207 lines), has crew index tests for all roles, needs crew show route tests added. NEW in this revision — addresses first review finding.

Files to create (all verified to not yet exist):

• [x] db/migrate/YYYYMMDD_create_crew_members.rb — does not exist yet, correct
• [x] app/models/crew_member.rb — does not exist yet, correct
• [x] app/views/crew/show.html.erb — does not exist yet, correct
• [x] spec/requests/crew_spec.rb — exists (60 lines from PR #136), ticket says "expand existing specs", correct
• [x] spec/models/crew_member_spec.rb — does not exist yet, correct
• [x] lib/tasks/crew.rake — does not exist yet, correct. Pattern matches existing feature_flags.rake with find_or_create_by! idiom.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo change.

Dependencies

• PR #136 / board item #1354 (done) — created the Crew tab skeleton. Dependency satisfied.
• Board item #1317 / #107 (done) — parent issue for role-based tab visibility. Dependency satisfied.
• Board item #1337 / #115 (done) — Phase 1 Keycloak login. Dependency satisfied.
• Board item #1363 / #137 (in_progress) — Person icon views. Sibling phase:2 work, no blocking dependency.
• No undocumented blocking dependencies found.

Acceptance Criteria

All 5 ACs are now self-contained and achievable without changes to WorkQueueItem:

• [x] "Crew index shows list of all active crew members with their name and role badge" — testable, depends on CrewMember model (will be created)
• [x] "Clicking a crew member navigates to their profile page (name, role, active status, Keycloak username)" — testable, no dependency on WorkQueueItem. Revised from first review — was "Today queue", now "profile page".
• [x] "Admin and super_admin can access Crew tab; all other roles get 404" — testable, role gating already in place
• [x] "CrewMember model with validations and crew:sync rake task" — testable
• [x] "Crew member list shows active/inactive status indicator" — testable, depends only on CrewMember.active boolean. Revised from first review — was "completion count", now "active/inactive indicator".

Blast Radius

• Adding CrewMember model is isolated — no existing code references crew_members table.
• Adding :show to crew routes requires updating role_access_spec.rb (now in Files to modify).
• Nav layout in app/views/layouts/application.html.erb (lines 85-86) already handles crew tab visibility, no changes needed.
• No WorkQueueItem changes — blast radius is minimal compared to first review version.

Decomposition Assessment

6 files to create + 5 to modify = 11 file targets. 5 acceptance criteria. Single repo. Estimated agent work: ~7-8 minutes. The show page is now simpler (profile display vs. per-member queue), reducing complexity from the first review estimate. Borderline but cohesive — no decomposition needed.

Recommendations

• [SCOPE] (deferred) Create user story entry for "auth" on project-landscaping-assistant user-stories section.
• [SCOPE] (deferred) Create architecture note arch-rails-app.

No new [BODY] or [LABEL] recommendations. All actionable issues from the first review have been resolved.

Verdict: READY

Board item #1363 on board-landscaping-assistant (backlog, 3 points)
Forgejo issue: ldraney/landscaping-assistant#137
Labels: type:feature, arch:rails-app, story:auth, phase:2

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Discovered during PR #136 review
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story
• [x] Context
• [x] File Targets (create + modify + NOT touch)
• [x] Acceptance Criteria
• [x] Out of Scope
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

All required sections for Feature type are present and filled.

Traceability

• [x] story:auth label present
• [ ] story note MISSING -- no "auth" entry in project-landscaping-assistant user-stories section. Known systemic gap, deferred -- not blocking.
• [x] arch:rails-app label present
• [ ] arch note MISSING -- no arch-rails-app note in pal-e-docs. Known systemic gap, deferred -- not blocking.
• [x] Forgejo issue -- ldraney/landscaping-assistant#137, open

File Targets

Files to create (confirmed do NOT exist yet):

• [x] app/controllers/person_controller.rb -- does not exist, ready to create
• [x] app/views/person/index.html.erb -- does not exist, ready to create
• [x] spec/requests/person_spec.rb -- does not exist, ready to create

Files to modify (confirmed exist with expected content):

• [x] app/views/layouts/application.html.erb -- line 64 confirmed: link_to root_path for Person icon. Platform sub-nav at lines 69-74 confirmed for super_admin.
• [x] config/routes.rb -- no person route exists yet. resources :person, only: [:index] verified to generate person_index GET /person person#index with helper person_index_path.
• [x] app/assets/stylesheets/application.css -- exists, ready for Person view styles

Files NOT to touch (confirmed exist and working):

• [x] app/controllers/platform/feature_flags_controller.rb -- exists
• [x] app/views/platform/feature_flags/index.html.erb -- exists
• [x] app/controllers/sessions_controller.rb -- exists
• [x] app/controllers/application_controller.rb -- exists, role helpers confirmed: current_user_has_role?, visible_tabs, current_user returning session hash with :username, :email, :roles keys

Repo Placement

OK -- issue filed on ldraney/landscaping-assistant, all file targets are in this repo. Single-repo change.

Dependencies

• #107 / PR #136 (5-slot nav with Person placeholder) -- done, merged
• #130 / PR #144 (Platform feature flags UI under Person) -- done, merged
• #123 (Client request UI / My Property detail) -- correctly listed as out of scope / future
• #117 (Crew tab) -- sibling phase:2 work, no dependency

No blockers. All prerequisites are complete.

Acceptance Criteria

7 acceptance criteria, all testable by an agent:

• Person icon navigation -- verifiable via request spec checking redirect/response
• Profile section content -- verifiable via response body assertions
• Crew join form placeholder -- verifiable via response body assertions
• My Property client-only visibility -- verifiable via role-based request specs
• Platform link super_admin-only -- verifiable via role-based request specs
• All-role access -- verifiable with 5-role parameterized specs
• Dev mode graceful degradation -- verifiable by running specs without KEYCLOAK_URL

6 test expectations with specific run command: bundle exec rspec spec/requests/person_spec.rb. Existing request spec patterns in spec/requests/ (12 files) provide clear templates to follow.

Blast Radius

Minimal. Only change to existing views is updating one link_to target on line 64 of the layout (root_path -> person_index_path). The Platform sub-nav (lines 69-74) remains untouched. No other files reference "person" in a way that would conflict. The is-active logic on the Person tab will need updating to check controller_name == 'person' instead of the current work_queue_items fallback -- this is implicit in the ticket but not explicitly called out as an AC. The implementing agent should handle this naturally.

Decomposition Assessment

3 files to create + 3 files to modify = 6 file targets, all in one repo. 7 AC (at the threshold). The work is cohesive: one controller, one view, one route entry, one CSS section, one link update, and one spec file. Estimated agent work: ~4 minutes. No decomposition needed.

Recommendation

No action needed. Ticket is well-scoped and ready for implementation.

Note: The two systemic gaps (missing story:auth user story on project page, missing arch-rails-app note) are known and deferred per reviewer instructions. These should be addressed as a separate housekeeping pass across all story:auth / arch:rails-app tickets.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Out of Scope
• [x] Checklist
• [x] Related

Traceability

• [x] story:auth label -- present on board item
• [ ] story note MISSING -- no "auth" entry in project-landscaping-assistant user-stories section. [SCOPE] Create user story entry for "auth" on project-landscaping-assistant. Known gap, deferred per caller context.
• [x] arch:rails-app label -- present on board item
• [ ] arch note MISSING -- no arch-rails-app note found in pal-e-docs. [SCOPE] Create architecture note arch-rails-app. Known gap, deferred per caller context.
• [x] Forgejo issue -- ldraney/landscaping-assistant#117, open

File Targets

Files to modify (all verified to exist):

• [x] app/controllers/crew_controller.rb -- verified: placeholder controller with require_role :admin, :super_admin and empty index action
• [x] app/views/crew/index.html.erb -- verified: placeholder view with "coming soon" text
• [x] config/routes.rb -- verified: resources :crew, only: [:index] at line 37, needs :show added
• [x] app/assets/stylesheets/application.css -- verified: exists

Files to create (all verified to not yet exist):

• [x] db/migrate/YYYYMMDD_create_crew_members.rb -- does not exist yet, correct
• [x] app/models/crew_member.rb -- does not exist yet, correct
• [x] app/views/crew/show.html.erb -- does not exist yet, correct
• [x] spec/requests/crew_spec.rb -- exists (60 lines from PR #136), ticket says "expand existing specs", correct
• [x] spec/models/crew_member_spec.rb -- does not exist yet, correct
• [x] lib/tasks/crew.rake -- does not exist yet, correct. Pattern matches existing feature_flags.rake with find_or_create_by! idiom.

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo change.

Dependencies

• PR #136 (done) -- created the Crew tab skeleton. Board item #1354 is in done column. Dependency satisfied.
• Board item #1317 (#107, done) -- parent issue for role-based tab visibility. Dependency satisfied.
• Board item #1337 (#115, done) -- Phase 1 Keycloak login. Dependency satisfied.
• #137 (backlog) -- Person icon views. Sibling phase:2 work, no blocking dependency.
• Solid Cable #2 (backlog) -- correctly listed as out of scope.
• No undocumented blocking dependencies found.

Acceptance Criteria

Critical data model gap found.

• [x] "Crew index shows list of all active crew members with their role" -- testable, depends on CrewMember model (will be created)
• [ ] "Clicking a crew member shows their Today queue (work_queue_items for that user's date)" -- PROBLEM: WorkQueueItem currently has no user/username/crew_member_id column. The model only has property_id, work_date, position, completed. There is no way to filter work_queue_items by crew member without adding a migration to add a foreign key. The ticket does not mention this prerequisite migration.
• [x] "Admin and super_admin can access Crew tab; all other roles get 404" -- testable, role gating already in place
• [x] "CrewMember model with validations and crew:sync rake task" -- testable
• [ ] "Crew member list shows completion count (X/Y properties done today)" -- same problem as AC #2: without a user column on work_queue_items, there is no way to attribute completed properties to a specific crew member

Blast Radius

• WorkQueueItem is used by WorkQueueItemsController (member+ access), Today tab views, and Week tab views. Adding a username/crew_member column would affect queries in those controllers. The ticket's Out of Scope correctly excludes real-time updates and Week tab per-member breakdown, limiting blast radius.
• Existing spec/requests/role_access_spec.rb has crew access tests that will need updating if the show action is added.
• Nav layout in app/views/layouts/application.html.erb already handles crew tab visibility (line 85-86), no changes needed there.

Decomposition Assessment

6 files to create + 4 to modify = 10 file targets. 5 acceptance criteria. Single repo. Estimated agent work: ~8-10 minutes due to new model, migration, two views, rake task, and expanded specs. This is borderline but manageable as a single pass if the data model gap is resolved in the ticket scope. No decomposition needed -- the work is cohesive and tightly coupled.

Recommendations

• [BODY] Add a migration to the File Targets section: db/migrate/YYYYMMDD_add_username_to_work_queue_items.rb adding a username (string, nullable, indexed) column to work_queue_items. Without this, AC #2 and AC #5 (per-member Today queue and completion counts) are impossible. Alternatively, clarify in Context that the show view queries all work_queue_items for the date (not per-member), and adjust AC #2 and #5 accordingly.
• [BODY] Add spec/requests/role_access_spec.rb to "Files to modify" -- the new /crew/:id show route will need role access test coverage in the existing role matrix spec.
• [SCOPE] (deferred) Create user story entry for "auth" on project-landscaping-assistant user-stories section.
• [SCOPE] (deferred) Create architecture note arch-rails-app.

Verdict: READY

Template Completeness

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

All required sections for Feature type are present and filled.

Traceability

• [x] story:auth label present
• [ ] story note MISSING — no "auth" entry in project-landscaping-assistant user-stories table. Current stories: address-lookup, property-crud, service-tracking, special-notes, work-queue, weekly-tracking, schedule-upload. [SCOPE] Create "auth" user story entry on project-landscaping-assistant user-stories section.
• [x] arch:k8s-deploy label present
• [ ] arch note MISSING — search for "arch-k8s-deploy" returned no results in pal-e-docs. [SCOPE] Create architecture note arch-k8s-deploy for the Kubernetes deployment component.
• [x] Forgejo issue — ldraney/landscaping-assistant#140, open

File Targets

• [x] overlays/landscaping-assistant/prod/deployment-patch.yaml — verified exists in pal-e-deployments. InitContainer currently runs command: ["bin/rails", "db:prepare"], confirming the change target is accurate.

Repo Placement

Issue filed on landscaping-assistant but fix is in pal-e-deployments. The issue explicitly documents this in the ### Repo section (ldraney/pal-e-deployments) and in ### File Targets ("Files NOT to touch: Anything in landscaping-assistant repo"). Cross-repo tracking is acceptable.

Dependencies

• [x] Blocker #130 (FeatureFlag model + rake task) — CLOSED. Board item #1354 is in done column.
• [x] Rake task feature_flags:sync exists at lib/tasks/feature_flags.rake and is idempotent (uses find_or_create_by!).
• [x] FeatureFlag model exists at app/models/feature_flag.rb.

All dependencies are resolved. No remaining blockers.

Acceptance Criteria

3 criteria, all verifiable by an agent:

• [x] InitContainer command change — verifiable via file diff
• [x] ArgoCD sync — verifiable post-deploy (requires prod access)
• [x] Flags appear in DB — verifiable via the provided kubectl exec command, which is real and correct

Criteria are well-scoped and testable.

Blast Radius

Minimal. Single-line change in one kustomize overlay. No other overlays or services affected. The rake task is idempotent — safe to run on every deploy. No downstream consumers impacted.

Decomposition Assessment

1 file target, 1 repo, 3 AC, estimated <1 minute agent work. No decomposition needed.

Recommendations

• [SCOPE] Create user story entry "auth" on project-landscaping-assistant user-stories section. This story is referenced by 10+ board items but has no backing entry.
• [SCOPE] Create architecture note arch-k8s-deploy for the Kubernetes deployment component. Referenced by multiple board items (e.g., #1291 ServiceMonitor, #1368 this ticket).

Note: Both missing notes are systemic gaps affecting many tickets, not specific to this ticket. The ticket scope itself is solid.

Verdict: READY

Re-review after refinements. Previous review (same slug, rev 1) returned NEEDS_REFINEMENT with 4 items. Items 1-2 were deferred as systemic; items 3-4 are now fixed. No new issues found.

Previous Findings Disposition

• [DEFERRED] story:auth user story missing from project-landscaping-assistant -- Systemic gap affecting many tickets, not #130-specific. Will be tracked separately.
• [DEFERRED] arch-rails-app note missing from pal-e-docs -- Systemic gap affecting many tickets, not #130-specific. Will be tracked separately.
• [x] SolidCache claim fixed -- Technical Notes now correctly state: "Rails.cache defaults to :file_store in production (SolidCache gem is in Gemfile but not configured -- cache_store is commented out, no solid_cache.yml)." Verified: production.rb has config.cache_store = :mem_cache_store commented out, no config/solid_cache.yml exists, gem is in Gemfile but unconfigured.
• [x] Issue reopened -- Forgejo issue #130 state is now open (updated_at: 2026-06-07T02:15:18Z).

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- References spike #129 and architecture doc
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- Present and well-formed
• [x] Context -- Thorough, includes current auth state with session hash detail
• [x] File Targets -- Detailed, split into create/modify
• [x] Acceptance Criteria -- 18 criteria across 5 groups (Model+Migration, Helpers, Rake Task, Super Admin UI, Tests)
• [x] Technical Notes -- Present with corrected cache store info and important caveats
• [x] Out of Scope -- Clearly enumerated (5 items)
• [x] Constraints -- CSS guide and no-Tailwind constraints stated
• [x] Enforcement -- Post-merge workflow for adding new flags documented
• [x] Checklist -- Present
• [x] Related -- Comprehensive cross-references (#129, #140, #125, #123, #107, #2)

Traceability

• [x] story:auth label -- Present on board item #1354
• [DEFERRED] story note -- No "auth" entry in project-landscaping-assistant user-stories section. Systemic gap, not blocking this ticket.
• [x] arch:rails-app label -- Present on board item #1354
• [DEFERRED] arch note -- No arch-rails-app note in pal-e-docs. Systemic gap, not blocking this ticket.
• [x] Forgejo issue -- ldraney/landscaping-assistant#130, state: open

File Targets

Files to create (all correctly do not exist yet):

• [x] db/migrate/YYYYMMDD_create_feature_flags.rb -- no feature_flags migration exists
• [x] app/models/feature_flag.rb -- does not exist, no FeatureFlag references in codebase
• [x] app/controllers/platform/feature_flags_controller.rb -- platform/ directory does not exist yet
• [x] app/views/platform/feature_flags/index.html.erb -- platform/ view directory does not exist yet
• [x] lib/tasks/feature_flags.rake -- lib/tasks/ exists but empty
• [x] spec/support/feature_flags.rb -- spec/support/ exists with omniauth.rb only
• [x] spec/models/feature_flag_spec.rb -- spec/models/ exists, no feature_flag_spec
• [x] spec/requests/platform/feature_flags_spec.rb -- spec/requests/ exists, no platform/ subdirectory
• [x] spec/requests/feature_flag_gating_spec.rb -- does not exist

Files to modify (all verified):

• [x] app/controllers/application_controller.rb -- exists, has helper_method (line 8), current_user_has_role? (line 56), TAB_ROLES with super_admin (lines 73-78)
• [x] config/routes.rb -- exists, no platform namespace yet
• [x] app/views/layouts/application.html.erb -- exists, Person icon at nav slot 3
• [x] app/assets/stylesheets/application.css -- exists

Repo Placement

Correct. All file targets are within ldraney/landscaping-assistant. Deploy initContainer change correctly tracked separately in #140 (pal-e-deployments).

Dependencies

• Upstream: Spike #129 (done), Auth/roles #107 (done). All prerequisites met.
• Downstream: #140 (deploy initContainer), #125 (Stripe), #123 (Client requests) -- all correctly documented in Related/Out of Scope.

Acceptance Criteria

18 criteria across 5 groups, all verifiable. Architecture doc at docs/feature-flags.md provides complete code snippets for every component. Two implementation notes from previous review remain relevant for the implementer:

• Person icon Platform link: follow docs/feature-flags.md pattern (third view option under Person icon)
• Test cache: test.rb uses :null_store, so cache model spec needs :memory_store swap or key-generation testing

Blast Radius

Greenfield feature. No existing code references FeatureFlag. Platform namespace is new and isolated. feature_enabled? helper on ApplicationController is intentionally global. require_super_admin returning 404 (vs require_role's redirect) is an intentional design choice documented in the ticket.

Decomposition Assessment

13 file touches, 18 AC, single repo. Architecture doc provides complete implementation guide with code snippets. No decomposition needed -- the doc reduces effective complexity to a guided implementation pass.

Recommendations

No action needed. All fixable items from previous review have been resolved. Deferred items (story note, arch note) are systemic and tracked separately.

Verdict: READY

Template Completeness

• [x] Type — Bug
• [x] Lineage — Standalone, discovered during PR #102
• [x] Repo — ldraney/landscaping-assistant
• [x] What Broke — clear description with error message
• [x] Repro Steps — 3 concrete steps
• [x] Expected Behavior — clear and specific
• [x] Environment — local Docker dev, Rails 8.1.3, Ruby 3.4.0
• [x] Acceptance Criteria — 3 criteria, all verifiable
• [x] Related — PR #102, file target with line number

Traceability

• [x] story:testing label — testing infrastructure story
• [ ] story note MISSING — [SCOPE] "testing" is not listed in project-landscaping-assistant user-stories section. Create user story entry for "testing" on the project page. Note: two completed items (#1288, #1289) also use story:testing, so this is an established label — the project page just needs updating.
• [x] arch:rails-app label — Rails application component
• [ ] arch note MISSING — [SCOPE] No arch-rails-app note found in pal-e-docs. Create architecture note arch-rails-app for the Rails application component. Note: this label is used by 20+ board items across the project, so the note is well overdue.
• [x] Forgejo issue — ldraney/landscaping-assistant#103, open

File Targets

• [x] config/environments/test.rb:32 — verified: line 32 contains config.hosts.clear with comment "Allow any host in test (RSpec default is www.example.com)." This is exactly what the ticket describes.

Repo Placement

Correct. Issue is filed on ldraney/landscaping-assistant and the fix is in the same repo. Single-repo fix — no cross-repo concerns.

Dependencies

No blocking dependencies. Related board items:

• #1288 (done) — "Request specs for properties CRUD + resolve" — same story:testing label, this ticket created the request specs that are now broken
• #1289 (done) — "System test infra + critical path browser specs" — same story:testing label, sister testing infrastructure work
• PR #102 mentioned in Lineage — where the bug was discovered

No items in in_progress or next_up that block or are blocked by this ticket.

Acceptance Criteria

All 3 criteria are agent-verifiable:

• "Bug no longer reproduces — bundle exec rspec passes request specs" — verifiable by running docker compose exec web bundle exec rspec spec/requests/
• "No regression in development or production host config" — verifiable by inspecting that development.rb and production.rb host configs are unchanged
• "Fix is minimal (1-2 lines in test.rb)" — verifiable by checking diff size

Blast Radius

Low. The fix is isolated to config/environments/test.rb — a test-only configuration file. Development host config (config.hosts << "landscaping-dev.tail5b443a.ts.net") and production config (hosts commented out) are not affected. The fix will unblock all 7 request spec files (664 lines total) covering properties, work queue, weeks, uploads, health, metrics, and client errors.

No sibling services to check — this is a single-app project. The pattern (config.hosts.clear not working in Rails 8.1) could affect other rails-base-derived apps if they upgrade to Rails 8.1, but that is out of scope for this ticket.

Decomposition Assessment

No decomposition needed. Single file target, 3 acceptance criteria, estimated agent work well under 5 minutes. This is a 1-point bug fix — change 1-2 lines in test.rb.

Recommendations

• [SCOPE] Create user story entry "testing" on project-landscaping-assistant user-stories section (pre-existing gap — 3 completed items already use this label)
• [SCOPE] Create architecture note arch-rails-app for the Rails application component (pre-existing gap — 20+ board items use this label)

Neither of these blocks the ticket — they are documentation debt items that predate this issue. The ticket itself is well-scoped and ready for implementation.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage
• [x] Repo -- ldraney/pal-e-deployments
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

All template sections present. Issue is well-structured.

Traceability

• [x] story:observability label -- present on board item
• [ ] story note MISSING -- [SCOPE] The observability story does not exist in the project-landscaping-assistant user-stories table. Current stories are: address-lookup, property-crud, service-tracking, special-notes, work-queue, weekly-tracking, schedule-upload. Create user story entry on project-landscaping-assistant.
• [x] arch:k8s-deploy label -- present on board item
• [ ] arch note MISSING -- [SCOPE] No arch-k8s-deploy note found in pal-e-docs. Create architecture note arch-k8s-deploy for the K8s deployment component.
• [x] Forgejo issue -- ldraney/landscaping-assistant#17, state: open
• [x] parent:43 label -- parent is board item #1283 "Observability & DORA metrics stack" (backlog)

File Targets

• [ ] overlays/landscaping-assistant/prod/prometheusrule.yaml -- ISSUE: File does not exist yet (expected, this is a new file). However, this file lives in ldraney/pal-e-deployments, NOT in ldraney/landscaping-assistant. See Repo Placement below.
• [x] overlays/landscaping-assistant/prod/kustomization.yaml -- verified: exists in pal-e-deployments. Currently lists ../../../bases/standard as a resource with JSON patches for Deployment and Service renaming. Does not yet reference prometheusrule.yaml.

Repo Placement

MISMATCH CONFIRMED. The issue body correctly states ### Repo: ldraney/pal-e-deployments and the file targets are paths within that repo. However, the Forgejo issue is filed on ldraney/landscaping-assistant (issue #17). The board item links to landscaping-assistant/issues/17. An implementing agent working in the landscaping-assistant checkout will not find the overlays/ directory -- it does not exist in that repo.

[BODY] The Forgejo issue must be moved to ldraney/pal-e-deployments, or a new issue created there and the board item's forgejo_issue_url updated. Forgejo does not support cross-repo issue moves, so the practical fix is: create a new issue on pal-e-deployments, close this one with a reference, and update the board item.

Dependencies

• #19 (Add /metrics endpoint) -- state: closed. Board item #1290 is in done. This dependency is resolved. PR #47 merged.
• #15 (Fix ServiceMonitor label mismatch) -- state: open. Board item #1291 is in todo. This dependency is NOT resolved. The PrometheusRule alerts are useless without a working ServiceMonitor because Prometheus cannot scrape metrics. This is a hard blocker.
• The title "blocked on #19 + #15" is partially stale -- #19 is done. Title should be updated to reflect only the remaining blocker (#15).

Acceptance Criteria

• [x] "PrometheusRule resource created with alerts for high 5xx error rate, p95 latency spike, zero available pods" -- verifiable via kustomize build output
• [x] "Alerts scoped to landscaping-assistant namespace via label matchers" -- verifiable
• [x] "Alert severity labels use platform convention" -- verifiable but vague: the convention (warning vs critical) is stated in the AC itself, which is good
• [x] "kustomize build renders the PrometheusRule cleanly" -- verifiable with run command

Issue with metric names: The AC says "high 5xx error rate (>5% over 5m)" and "p95 latency spike (>2s over 5m)". The actual yabeda-rails metrics exposed are rails_requests_total (counter with status tag) and rails_request_duration_seconds (histogram). The issue does not specify the PromQL expressions or reference the actual metric names. An agent will need to know:

• Error rate: sum(rate(rails_requests_total{status=~"5.."}[5m])) / sum(rate(rails_requests_total[5m]))
• Latency: histogram_quantile(0.95, sum(rate(rails_request_duration_seconds_bucket[5m])) by (le))
• Pod availability: kube_deployment_status_replicas_available{deployment="landscaping-assistant"} (from kube-state-metrics, not yabeda)

[BODY] Add the actual PromQL expressions and metric names to the issue body so the implementing agent does not have to guess.

Blast Radius

Low blast radius. This creates a new standalone YAML file and adds one line to kustomization.yaml. No existing resources are modified. The only risk is alert noise from poorly tuned thresholds, which the Constraints section already acknowledges.

Decomposition Assessment

2 file targets in 1 repo, 4 acceptance criteria. Well within the 5-minute rule. No decomposition needed.

Recommendations

1. [BODY] Move or re-create the issue on ldraney/pal-e-deployments. The file targets live there, not in landscaping-assistant. Update board item #1293 forgejo_issue_url accordingly.
2. [BODY] Add PromQL expressions with actual yabeda-rails metric names (rails_requests_total, rails_request_duration_seconds_bucket, kube_deployment_status_replicas_available) to the issue body so the implementing agent has exact expressions to use.
3. [BODY] Update the title and context to remove the resolved #19 dependency. Only #15 (ServiceMonitor fix) remains as a blocker.
4. [SCOPE] Create user story entry "observability" on project-landscaping-assistant user-stories section. Multiple board items (8 items) reference story:observability but the story is not defined.
5. [SCOPE] Create architecture note arch-k8s-deploy for the Kubernetes deployment component in pal-e-docs.

Verdict: APPROVED

Re-review of board item #1292. Prior review (NEEDS_REFINEMENT) flagged two [BODY] issues and two [SCOPE] issues. Both [BODY] items are now fixed in the Forgejo issue. [SCOPE] items remain open but do not block issue readiness.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- standalone, discovered during observability gap audit
• [x] Repo -- ldraney/pal-e-platform
• [x] User Story -- clear operator story
• [x] Context -- references existing dashboards in terraform/dashboards/
• [x] File Targets -- FIXED. Now lists both terraform/dashboards/landscaping-assistant-golden-signals.json (new) and terraform/modules/monitoring/main.tf (add ConfigMap resource block). Matches actual codebase pattern (lines 683-697 for pal-e-app).
• [x] Acceptance Criteria -- 6 criteria, all testable
• [x] Test Expectations -- JSON validation + terraform plan + manual Grafana import
• [x] Constraints -- FIXED. Now references pal-e-app-golden-signals.json (standard golden signals pattern, not webhook-focused basketball-api).
• [x] Checklist -- present
• [x] Related -- project-landscaping-assistant, parent #43, blocked-on #15

Traceability

• [x] story:observability label -- present on board item
• [ ] story note MISSING -- project-landscaping-assistant user-stories section has no "observability" entry. [SCOPE] Create "observability" user story entry on project-landscaping-assistant user-stories section. (Carried forward from prior review -- does not block issue body readiness.)
• [x] arch:platform label -- present on board item
• [ ] arch note MISSING -- no arch-platform note exists in pal-e-docs. [SCOPE] Create architecture note arch-platform. (Carried forward from prior review -- does not block issue body readiness.)
• [x] Forgejo issue #16 -- open
• [x] parent:43 label -- parent "Observability & DORA metrics stack" exists on board (backlog, 8pts)

File Targets

• [x] terraform/dashboards/landscaping-assistant-golden-signals.json -- target does not exist yet (correct, this is the file to create). Directory verified at /home/ldraney/pal-e-platform/terraform/dashboards/ with 7 existing dashboards. No existing landscaping-assistant references in the repo.
• [x] terraform/modules/monitoring/main.tf -- NOW IN ISSUE. File exists. Verified existing ConfigMap pattern at lines 683-697 (pal-e-app). Issue body correctly describes "add kubernetes_config_map_v1 resource block" and notes "all 6 existing dashboards have explicit resource blocks here."

Repo Placement

Correct. Issue filed on ldraney/landscaping-assistant but Repo field correctly states ldraney/pal-e-platform, which owns all Grafana dashboards and Terraform infrastructure. The PR should target pal-e-platform.

Dependencies

• [x] #19 /metrics endpoint (yabeda-prometheus) -- RESOLVED. Board item #1290 in done column.
• [ ] #15 Fix ServiceMonitor label mismatch -- STILL OPEN. Board item #1291 in todo column. Soft dependency: dashboard deploys but panels show no data until scraping works. Issue body correctly documents this as "Blocked on: #15 ... soft dependency; dashboard deploys but shows empty panels."

Acceptance Criteria

6 criteria, all verifiable. The addition of "Namespace filter defaults to landscaping-assistant" (AC #6) is verified feasible -- the reference pal-e-app dashboard has 11 namespace references. All AC are testable by an agent or operator.

Blast Radius

Low. Adds one new ConfigMap and one new JSON file. No modifications to existing dashboards or resources. terraform plan should show exactly one new resource. Issue's "Files the agent should NOT touch" section correctly scopes this.

Decomposition Assessment

2 files, 1 repo (pal-e-platform), 6 AC. Well within single-agent pass. No decomposition needed.

Prior Findings Resolution

Recommendation

Issue body is complete and ready for implementation. Two [SCOPE] items remain as platform-level documentation tasks that do not affect agent execution:

1. [SCOPE] Create "observability" user story entry on project-landscaping-assistant user-stories section.
2. [SCOPE] Create architecture note arch-platform for the platform infrastructure component.

Verdict: READY

Template Completeness

• [x] Type — Feature
• [x] Lineage — standalone, observability audit
• [x] Repo — ldraney/pal-e-platform
• [x] User Story — clear
• [x] Context — references existing dashboards
• [ ] File Targets — mentions JSON but omits TF resource block (minor gap)
• [x] Acceptance Criteria — dashboard visible in Grafana
• [x] Test Expectations — visual verification
• [x] Constraints — useful after metrics flowing
• [x] Checklist — present
• [x] Related — parent #43

Traceability

• [x] story:observability — on board item
• [x] arch:platform — on board item
• [x] Forgejo issue #16 — open

File Targets

• [x] terraform/dashboards/ — verified, existing app dashboards present as templates
• [ ] terraform/modules/monitoring/main.tf — NOT in issue but required for kubernetes_config_map_v1 resource

Repo Placement

Correct. pal-e-platform owns Grafana dashboards.

Dependencies

• [ ] #19 /metrics endpoint — PENDING
• [ ] #15 ServiceMonitor — PENDING

Acceptance Criteria

Testable: dashboard appears in Grafana with request rate, error rate, latency, saturation panels.

Blast Radius

Low. New ConfigMap + dashboard only.

Decomposition Assessment

Two files (JSON + TF), one repo. Under 5 minutes.

Recommendation

1. Note in issue that main.tf resource block also needed.
2. Lower points from 3 to 2.

Verdict: READY

Template Completeness

• [x] Type — Feature
• [x] Lineage — standalone, observability audit
• [x] Repo — ldraney/pal-e-deployments
• [x] User Story — clear
• [x] Context — explains label mismatch
• [x] File Targets — bases/standard/kustomization.yaml, overlays/landscaping-assistant/prod/kustomization.yaml
• [x] Acceptance Criteria — kustomize build shows correct labels
• [x] Test Expectations — kustomize build + kubectl
• [x] Constraints — depends on #19
• [x] Checklist — present
• [x] Related — parent #43

Traceability

• [x] story:observability — on board item
• [x] arch:k8s-deploy — on board item
• [x] Forgejo issue #15 — open

File Targets

• [x] bases/standard/kustomization.yaml — servicemonitor.yaml missing from resources
• [x] overlays/landscaping-assistant/prod/kustomization.yaml — needs label patch

Repo Placement

Correct. pal-e-deployments owns kustomize overlays.

Dependencies

• [ ] #19 /metrics endpoint — PENDING (PR #47 open)

Acceptance Criteria

Testable: kustomize build shows ServiceMonitor with correct labels. Prometheus targets page shows landscaping-assistant.

Blast Radius

Low. Only affects landscaping-assistant ServiceMonitor.

Decomposition Assessment

Two small changes in one repo. Under 5 minutes.

Recommendation

1. Execute after #19 merges.
2. Lower points from 2 to 1.

Verdict: READY

Template Completeness

• [x] Type — Feature
• [x] Lineage — standalone, DORA gap analysis
• [x] Repo — ldraney/pal-e-platform
• [x] User Story — clear operator story
• [x] Context — references blackbox-exporter targets
• [x] File Targets — terraform/modules/monitoring/main.tf
• [x] Acceptance Criteria — probe_success=1 in Prometheus
• [x] Test Expectations — curl Prometheus API
• [x] Constraints — app must be deployed (satisfied)
• [x] Checklist — present
• [x] Related — parent #43

Traceability

• [x] story:observability — on board item
• [x] arch:platform — on board item
• [x] Forgejo issue #21 — open

File Targets

• [x] terraform/modules/monitoring/main.tf — verified, blackbox targets at lines 385-454, landscaping-assistant absent

Repo Placement

Correct. pal-e-platform owns monitoring Terraform.

Dependencies

• [x] App deployed — satisfied
• [x] Blackbox exporter running — satisfied

Acceptance Criteria

Testable: query Prometheus for probe_success{instance=~".*landscaping.*"}.

Blast Radius

Minimal. One target added to existing list.

Decomposition Assessment

Single file, single change. Under 5 minutes.

Recommendation

1. Execute as-is. URL: http://landscaping-assistant.landscaping-assistant.svc.cluster.local:3000, tier=app label.

Verdict: READY

Template Completeness

• [x] Type — Feature
• [x] Lineage — standalone, DORA gap analysis
• [x] Repo — ldraney/landscaping-assistant (verification only)
• [x] User Story — clear
• [x] Context — references DORA exporter auto-discovery
• [x] File Targets — N/A, verification only
• [x] Acceptance Criteria — check Grafana for 4 DORA metrics
• [x] Test Expectations — manual Grafana verification
• [x] Constraints — none
• [x] Checklist — present
• [x] Related — parent #43

Traceability

• [x] story:observability,story:dora — on board item
• [x] arch:rails-app — on board item
• [x] Forgejo issue #20 — open

File Targets

No file targets — verification only.

Repo Placement

Correct. No code changes expected.

Dependencies

• [x] DORA exporter deployed — satisfied
• [x] Woodpecker CI active — satisfied
• [x] Grafana DORA dashboard — satisfied

Acceptance Criteria

Testable: confirm landscaping-assistant appears in DORA dashboard with deployment frequency, lead time, CFR, MTTR.

Blast Radius

Zero. Read-only verification.

Decomposition Assessment

Single task, under 5 minutes.

Recommendation

1. Execute as-is.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — standalone, discovered during observability gap audit
• [ ] Repo — WRONG. Says pal-e-deployments but should be pal-e-platform (see Repo Placement)
• [x] User Story — clear operator story
• [x] Context — references cluster-wide alerts as baseline
• [ ] File Targets — targets kustomize overlay but should target Terraform (see Repo Placement)
• [ ] Acceptance Criteria — alert expressions use wrong metric names (see below)
• [x] Test Expectations — amtool check-rules
• [x] Constraints — depends on #19 and #15
• [x] Checklist — present
• [x] Related — links to parent #43

Traceability

• [x] story:observability — present on board item
• [x] arch:k8s-deploy — present but should be arch:platform after repo correction
• [x] Forgejo issue #17 — open

File Targets

Issue targets overlays/landscaping-assistant/prod/ in pal-e-deployments. This is wrong — all existing PrometheusRules are in pal-e-platform/terraform/modules/monitoring/main.tf as kubernetes_manifest resources (blackbox_alerts, embedding_alerts, payment_pipeline_alerts, gmail_oauth_expiry_alert).

Repo Placement

WRONG. Should target pal-e-platform Terraform, not pal-e-deployments kustomize. Every other PrometheusRule follows the Terraform pattern. Using kustomize diverges from the established convention.

Dependencies

• [ ] #19 /metrics endpoint — PENDING
• [ ] #15 ServiceMonitor fix — PENDING

Acceptance Criteria

PROBLEM: Alert expressions reference http_requests_total and http_request_duration_seconds_bucket, but yabeda-rails (PR #47) emits rails_requests_total and rails_request_duration. All PromQL expressions need rewriting with correct metric names.

Blast Radius

Low once corrected. New PrometheusRule only. No impact on existing alerts.

Decomposition Assessment

Single resource in one repo once corrected. No decomposition needed.

Recommendation

1. Change target repo from pal-e-deployments to pal-e-platform
2. Update file targets to terraform/modules/monitoring/main.tf
3. Fix metric names: http_requests_total → rails_requests_total, http_request_duration_seconds_bucket → rails_request_duration
4. Update board item label from arch:k8s-deploy to arch:platform
5. Re-review after corrections

Verdict: READY

Template Completeness

• [x] Type — Feature
• [x] Lineage — standalone, discovered during observability gap audit
• [x] Repo — ldraney/pal-e-platform
• [x] User Story — clear operator story
• [x] Context — references existing dashboards as templates
• [ ] File Targets — mentions JSON file but omits the TF resource block in main.tf (minor gap)
• [x] Acceptance Criteria — dashboard visible in Grafana with panels
• [x] Test Expectations — visual verification in Grafana
• [x] Constraints — useful only after metrics flowing
• [x] Checklist — present
• [x] Related — links to parent #43

Traceability

• [x] story:observability — present on board item
• [x] arch:platform — present on board item
• [x] Forgejo issue #16 — open

File Targets

• [x] terraform/dashboards/ — verified exists in pal-e-platform. basketball-api, pal-e-app, playme2k, believers-elite JSON files present as templates.
• [ ] terraform/modules/monitoring/main.tf — NOT mentioned in issue but required. Each dashboard needs a kubernetes_config_map_v1 resource block here. Developer will see the pattern.

Repo Placement

Correct. pal-e-platform owns all Grafana dashboard Terraform.

Dependencies

• [ ] #19 /metrics endpoint — PENDING. Dashboard will show empty panels without metrics.
• [ ] #15 ServiceMonitor fix — PENDING. Prometheus can't scrape without it.

Can be built in parallel with #15/#19 and deployed after they land.

Acceptance Criteria

Testable: after TF apply, dashboard appears in Grafana with request rate, error rate, latency, saturation panels. Clear pass/fail once metrics are flowing.

Blast Radius

Low. New ConfigMap + dashboard only. No impact on existing dashboards. Rollback: terraform destroy the resource.

Decomposition Assessment

Two files (JSON + TF resource), one repo. Under 5 minutes for an agent following the existing pattern. No decomposition needed.

Recommendation

1. Note in the issue that main.tf also needs a kubernetes_config_map_v1 resource block.
2. Recommend lowering points from 3 to 2.

Verdict: READY

Re-review after refinement. Previous verdict was NEEDS_REFINEMENT. Issues resolved: uniqueness AC added, #30 independence clarified, test command fixed.

Template Completeness

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

Traceability

• [x] story:weekly-tracking label — "Track weekly completion across all active properties"
• [x] story note verified — found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label — Rails application component
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-rails-app (platform-wide gap, not blocking for this ticket)
• [x] Forgejo issue — https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant/issues/32, open

File Targets

• [x] app/views/weeks/index.html.erb — verified: exists, contains week grid with queued/completed cells (lines 34-44)
• [x] app/controllers/weeks_controller.rb — verified: exists, has index action with work_date logic
• [x] config/routes.rb — verified: exists, currently has resources :weeks, only: [:index] — needs move route added
• [x] app/javascript/controllers/ — verified: directory exists with existing Stimulus controllers (sortable, filter, location, add_location)
• [x] app/assets/stylesheets/application.css — verified: exists

Repo Placement

OK — issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo change.

Dependencies

• Parent: #28 "Week tab: move, add, and show unassigned properties" (board item #1263, backlog) — this is a child decomposition
• Sibling: #30 "Week tab: show unassigned properties section" (board item #1264, backlog) — explicitly stated as independent, confirmed: this ticket operates on existing grid cells only
• Sibling: #31 "Week tab: add property to a specific day" (board item #1265, backlog) — independent, different functionality
• No blockers in in_progress column. Dependencies correctly documented in issue Lineage section.

Acceptance Criteria

6 AC total — all testable by an agent:

• Day-picker UI on tap — verifiable via integration test
• work_date update — verifiable via DB assertion
• Grid update (old cell cleared) — verifiable via Turbo Stream response
• Uniqueness error — verifiable: model already has validates :property_id, uniqueness: { scope: :work_date }
• Turbo Stream or Stimulus (no full reload) — verifiable by response format
• Mobile-friendly tap targets — verifiable by CSS assertion (44px minimum)

Test command corrected to bundle exec rspec — matches Rails project conventions.

Blast Radius

• WorkQueueItem model NOT modified (per ticket constraints) — good, uniqueness validation already in place
• Existing Turbo Stream patterns established in work_queue_items (create/update/destroy.turbo_stream.erb) — new move action should follow same pattern
• Existing Stimulus controllers in app/javascript/controllers/ — new controller follows established convention
• No downstream consumers affected — self-contained UI feature

Decomposition Assessment

5 file targets in 1 repo, 6 AC — borderline but acceptable for a single agent pass. The work is cohesive (single action: move), all in one controller/view pair with a Stimulus controller and route. Estimated agent time: 3-4 minutes. No decomposition needed.

Recommendation

No action needed. Ticket is well-scoped and ready for implementation.

Note: The missing arch-rails-app note is a platform-wide gap affecting all rails-app tickets. Non-blocking for this review.

Verdict: READY

Template Completeness

• [x] Type — Feature
• [x] Lineage — Child of #28
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — present and well-formed
• [x] Context — explains motivation and references PR #29 convention
• [x] File Targets — 3 modify targets, 2 do-not-touch entries
• [x] Acceptance Criteria — 4 items
• [x] Test Expectations — 2 integration tests + run command
• [x] Constraints — No Tailwind, existing patterns, mobile-friendly
• [x] Checklist — standard 3 items
• [x] Related — project + parent ticket

Traceability

• [x] story:weekly-tracking label — "Track weekly completion across all active properties"
• [x] story note verified — found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label — Rails application component
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-rails-app for component rails-app
• [x] Forgejo issue — ldraney/landscaping-assistant#30, open

File Targets

• [x] app/controllers/weeks_controller.rb — verified: exists, currently queries Property.active and WorkQueueItem completions but has no unassigned logic yet
• [x] app/views/weeks/index.html.erb — verified: exists, currently shows week grid with address_line as primary (line 31), client_name as secondary (line 32) — matches ticket's claim that swap is needed
• [x] app/assets/stylesheets/application.css — verified: exists, will need unassigned section styles
• [x] Do-not-touch: app/views/work_queue_items/ — confirmed separate concern
• [x] Do-not-touch: config/routes.rb — no new routes needed for display-only feature

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets are in the same repo. Single-repo change.

Dependencies

• Parent issue #28 ("Week tab: show unassigned properties, add to day, move between days") is open — this is a child decomposition of that parent. No blocker.
• Board item #1265 ("Week tab: add property to a specific day") and #1266 ("Week tab: move property between days") are sibling tickets from the same parent — no ordering dependency, they are independent features.
• PR #29 (client_name as primary convention) is already merged — prerequisite satisfied.
• Property.active scope exists (line 6 of property.rb) — no model changes needed.
• WorkQueueItem model already has work_date and property_id — query for unassigned is straightforward.

Acceptance Criteria

All 4 criteria are verifiable by an agent:

• "Unassigned section shows below the week grid" — check DOM structure
• "Lists active properties with no work_queue_item in the displayed week" — integration test with fixtures
• "Week grid shows client_name as primary, address as secondary meta" — check HTML output order
• "Empty state when all properties are scheduled" — test with all properties queued

Test command bin/rails test in the issue should be bundle exec rspec (project uses RSpec, not Minitest). However, existing spec file at spec/requests/weeks_spec.rb already provides patterns the agent can follow. Minor issue — agent can infer correct command from project setup.

Blast Radius

Low risk. The client_name swap only affects weeks/index.html.erb. Other views (work_queue_items, properties/manage) already use client_name as primary — this change brings Week tab into consistency. No downstream consumers affected.

Decomposition Assessment

3 file targets in 1 repo. 4 acceptance criteria. Estimated agent work: ~3 minutes. No decomposition needed.

Recommendation

• [BODY] Fix test run command: bin/rails test → bundle exec rspec (project uses RSpec)
• [SCOPE] Create architecture note arch-rails-app for component rails-app (missing from pal-e-docs, shared across many board items)

Neither issue blocks implementation. The arch note is a platform-wide gap (affects all arch:rails-app items), not specific to this ticket. The test command is a minor documentation inaccuracy the agent will self-correct from project structure.

Verdict: NEEDS_REFINEMENT

Template Completeness

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

Traceability

• [x] story:weekly-tracking label — "Track weekly completion across all active properties"
• [x] story note verified — found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label — Rails application component
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-rails-app for component rails-app
• [x] Forgejo issue — https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant/issues/31, open

File Targets

• [x] app/views/weeks/index.html.erb — verified: exists, currently shows week grid with properties and day columns but no unassigned section or add buttons
• [x] app/controllers/weeks_controller.rb — verified: exists, has index action querying Property.active and WorkQueueItem date ranges
• [x] config/routes.rb — verified: exists, currently has resources :weeks, only: [:index] (will need additional action)
• [x] app/assets/stylesheets/application.css — verified: exists
• [x] app/controllers/work_queue_items_controller.rb (do NOT touch) — verified: exists, has create action with Turbo Stream response

Repo Placement

OK — issue filed on ldraney/landscaping-assistant, all file targets are in this repo. Single-repo change.

Dependencies

• HARD BLOCKER: Issue #30 (board item #1264, "Week tab: show unassigned properties section") is in backlog column and open in Forgejo. This ticket explicitly depends on #30 to provide the unassigned section that this ticket adds buttons to.
• Parent issue #28 ("Week tab: move, add, and show unassigned properties") is board item #1263, also in backlog.
• Related sibling: #32 ("Week tab: move property between days") is board item #1266, also in backlog — no direct dependency but shares the same view file.

Acceptance Criteria

• [x] "Each unassigned property has day-selection buttons (M T W T F S S)" — testable via integration test checking button presence
• [x] "Tapping a day button queues the property for that day" — testable, reuses WorkQueueItem.create pattern (property_id + work_date uniqueness constraint exists in model)
• [x] "Property moves from unassigned list to the grid after adding" — testable via Turbo Stream assertions
• [x] "Works via Turbo Stream (no full page reload)" — testable, existing turbo_stream.erb patterns exist in work_queue_items views

All criteria are agent-verifiable. Test commands are real (bin/rails test).

Blast Radius

• The WorkQueueItem model has a uniqueness constraint on property_id scoped to work_date — adding from the week view must handle duplicates gracefully (same as Today tab does).
• The existing work_queue_items#create controller is marked "do not touch" — the ticket correctly identifies reuse but the agent will need a separate action (likely on weeks_controller) or a new route that still calls WorkQueueItem.create internally.
• No sibling services affected — single Rails app.

Decomposition Assessment

4 file targets in 1 repo, 4 acceptance criteria, estimated agent time ~3-4 minutes. No decomposition needed.

Recommendations

• [SCOPE] Create architecture note arch-rails-app for the Rails application component in pal-e-docs. This is a shared gap across many board items with the same label.
• [SCOPE] Issue #30 (prerequisite) must be completed before this ticket can move to next_up. Dependency is correctly documented in the issue but the board does not enforce ordering — human/agent must respect the sequence.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, discovered during daily workflow usage
• [x] Repo — ldraney/landscaping-assistant
• [x] User Story — present, well-formed
• [x] Context — adequate background
• [x] File Targets — 4 modify/create targets, 2 do-not-touch
• [x] Acceptance Criteria — 4 items
• [x] Test Expectations — 2 integration tests + run command
• [x] Constraints — No Tailwind, Turbo/Stimulus patterns, mobile-friendly
• [x] Checklist — present
• [x] Related — references project and related issues

Traceability

• [x] story:weekly-tracking label — "Track weekly completion across all active properties"
• [x] story note verified — found in project-landscaping-assistant user-stories section
• [x] arch:rails-app label — Rails application component
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-rails-app for component rails-app
• [x] Forgejo issue — https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant/issues/28, open

File Targets

• [x] app/views/weeks/index.html.erb — verified: exists, currently shows read-only week grid with completions/queued indicators. Will need significant additions for move/add UI and unassigned section.
• [x] app/controllers/weeks_controller.rb — verified: exists with index action only. Currently has only resources :weeks, only: [:index] in routes. Will need new routes + actions for move/add.
• [x] app/javascript/controllers/ — verified: directory exists with sortable_controller.js, filter_controller.js, etc. New Stimulus controller needed for week interactions.
• [x] app/assets/stylesheets/application.css — verified: exists.

Repo Placement

OK — issue filed on ldraney/landscaping-assistant, all changes are in that repo.

Dependencies

• Issue #8 "Weekly tracking + property active/inactive" (board item 1250, done) — established the week view foundation this builds on.
• Issue #10 "Week view + properties tab + four-tab nav" (board item 1252, done) — created the current week grid layout.
• No blocking items in in_progress column.
• The existing WorkQueueItem model and controller patterns (create, destroy, reorder) provide the interaction model to follow.

Acceptance Criteria

Criteria are testable but somewhat vague on the "move" mechanism:

• "Can move a property from one day to another" — does not specify whether this is drag-and-drop or button-based. The existing sortable_controller uses Sortable.js for drag within a single day; cross-day drag is significantly more complex.
• "Can add a property to a specific day" — clear, follows existing pattern from Today tab.
• "Unassigned properties visible" — clear, straightforward query.
• "Can add an unassigned property to a day" — clear, subset of add functionality.

Blast Radius

• Routes change needed: currently resources :weeks, only: [:index] — needs additional member/collection routes for move and add actions.
• WorkQueueItem create/destroy patterns in work_queue_items_controller.rb are the canonical pattern for queue manipulation. The Week tab will either reuse those endpoints or add parallel ones — the ticket should clarify which approach.
• Turbo Stream patterns are well-established (create.turbo_stream.erb, update.turbo_stream.erb, destroy.turbo_stream.erb in work_queue_items views). Week tab should follow same convention.
• No impact on other services or repos.

Decomposition Assessment

NEEDS DECOMPOSITION — route to skill-decompose-ticket.

• File targets: 4 files, 1 repo — within threshold
• Acceptance criteria: 4 AC + 2 test expectations = 6 verifiable items — exceeds the >5 threshold
• Estimated agent time: >5 minutes. Scope includes: new routes, 2+ new controller actions, new Stimulus controller, significant view template changes (unassigned section + move/add UI), CSS additions, and 2 integration tests. Each AC represents distinct functionality (move vs. add vs. unassigned display).
• Recommended decomposition: Split into 2-3 sub-tickets: (1) Unassigned properties section (query + display), (2) Add property to day from Week tab, (3) Move property between days.

Recommendation

• [SCOPE] Create architecture note arch-rails-app for component rails-app (shared across multiple board items using this label).
• [BODY] Clarify AC #1: specify whether "move" is drag-and-drop or button-based (button-based is simpler and more mobile-friendly given the constraint).
• [BODY] Clarify whether Week tab actions reuse WorkQueueItemsController endpoints or add new actions to WeeksController.
• [DECOMPOSE] 6 verifiable items, estimated >5 min agent time across 3 distinct functional areas. Route to skill-decompose-ticket. Suggested split: (1) Unassigned section, (2) Add to day, (3) Move between days.

Verdict: APPROVED

Re-review after previous NEEDS_REFINEMENT. All prior issues resolved.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Child of #8, depends on #9
• [x] Repo -- ldraney/landscaping-assistant
• [x] User Story -- present
• [x] Context -- present, explains dependency chain
• [x] File Targets -- 7 files listed (4 new, 3 modify), plus exclusions
• [x] Acceptance Criteria -- 7 criteria
• [x] Test Expectations -- request specs + run command
• [x] Constraints -- 4 constraints listed
• [x] Checklist -- standard 3-item
• [x] Related -- project page + parent + dependency

Traceability

• [x] story:weekly-tracking label -- "Track weekly completion across all active properties"
• [x] story note verified -- found in project-landscaping-assistant user-stories section (key: weekly-tracking, role: Landscaper)
• [x] arch:rails-app label -- shared Rails app architecture
• [x] arch note verified -- arch-rails-app note exists in pal-e-docs (project: pal-enterprises, note_type: doc, tags: architecture,active)
• [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/landscaping-assistant/issues/10, state: open

File Targets

• [x] app/controllers/weeks_controller.rb -- NEW file, does not exist yet (correct for feature)
• [x] app/views/weeks/index.html.erb -- NEW file, directory does not exist yet (correct for feature)
• [x] app/controllers/properties_controller.rb -- EXISTS, needs toggle_active action added
• [x] app/views/properties/manage.html.erb -- NEW file, properties view directory exists
• [x] app/views/layouts/application.html.erb -- EXISTS, currently has 2-tab nav (New, Today), needs expansion to 4 tabs
• [x] config/routes.rb -- EXISTS, currently has properties and work_queue_items resources
• [x] app/assets/stylesheets/application.css -- EXISTS, has .bottom-nav and .nav-tab styles ready for extension
• [x] EXCLUSION: app/javascript/controllers/location_controller.js -- confirmed GPS flow unrelated
• [x] EXCLUSION: db/migrate/ -- confirmed no schema changes needed; active column already added by #9/PR#12

Repo Placement

OK. Issue filed on ldraney/landscaping-assistant, all file targets in same repo. Single-repo feature.