pal-e-docs

Review: Spike: audit westside-app vs westside-ror feature parity

review-1371-2026-06-06 Review

review ready
Project

Verdict: READY

Spike scope is solid. The question is clear, the time-box is appropriate, both codebases exist locally for comparison, and the deliverable (audit checklist, no code) fits a single agent pass. The traceability gaps below are pre-existing project-level issues already flagged in prior reviews — they do not block this spike.

Template Completeness

  • [x] Type — "Spike"
  • [x] Lineage — "Standalone — discovered during session when the registration form was found missing"
  • [x] Repo — ldraney/westside-ror
  • [x] Question — Clear top-level question with 6 sub-areas (routes, forms, content, styles, JS behavior, API integrations)
  • [x] Deliverables — Present, describes checklist output. Minor format deviation: uses paragraph instead of template's checkbox format with explicit docs/{topic}.md artifact, but intent is equivalent for a spike that produces findings rather than an architecture doc.
  • [x] Time-box — "2 hours"
  • [x] Related — References #38 (registration form port) and project-westside-ror
  • [x] Checklist — Extra section not in template, but harmless (duplicates Deliverables intent)

Traceability

  • [x] story:consolidation label — present on board item
  • [ ] story note MISSING — project-westside-ror project page does not exist in pal-e-docs, so user story cannot be verified. This is a known gap flagged in review-1367-2026-06-06 and review-1367-2026-06-06-r2. [SCOPE] Create project-westside-ror project page with user-stories section.
  • [x] arch:rails label — present on board item
  • [ ] arch note MISSING — no arch-rails note exists in pal-e-docs. However, "rails" is the framework itself, not a custom architecture component. For a spike that audits feature parity, this is acceptable — no custom architecture decision document is expected. [SCOPE] Consider whether arch-rails warrants a dedicated note or should be renamed to a more specific component label.
  • [x] Forgejo issue — #39, open, body well-formed

File Targets

N/A — spike type. No file targets expected. The issue correctly does not list file targets.
However, verified that both codebases are available locally for the audit agent:
  • [x] /home/ldraney/westside-ror/ — Rails app with 7 public routes, admin namespace, webhooks, emails
  • [x] /home/ldraney/westside-app/ — SvelteKit app (archived) with ~35 route files across (app) and (public) groups
  • [x] /home/ldraney/westside-ror/docs/consolidation.md — existing consolidation doc documents what was killed, what survives, and open items

Repo Placement

OK. Issue filed on ldraney/westside-ror which is the surviving app. The spike needs to read both westside-app (archived SvelteKit) and westside-ror (Rails), but both are available locally. No cross-repo issue needed — the audit output belongs in westside-ror.

Dependencies

  • #38 (Port multi-step registration form) — board item 1370, backlog, 8 points. This is a known gap that prompted the spike. The spike should discover this and potentially other gaps. No blocking dependency — the spike informs #38, not the other way around.
  • #33 (Consolidation spike) — closed, done. Prior spike that drove the consolidation. This spike is a follow-up audit after consolidation is complete.
  • No blockers — no items in in_progress or next_up block this spike. The two in_progress items (#2 tournament payments, #13 Queens Phoenix trip) are unrelated.

Acceptance Criteria

The issue uses a "Checklist" section with 2 items: (1) Audit complete, (2) Findings documented. These are appropriate for a spike — the deliverable is knowledge, not code. An agent can verify completion by checking whether the audit findings exist in issue comments or a linked note.
The "Deliverables" section adds specificity: "A checklist of inconsistencies with severity (missing feature vs. cosmetic difference vs. content drift), grouped by page/route." This is testable — the output must be a structured checklist with severity classification.

Blast Radius

Low. This is a read-only audit — no code changes. The findings will generate follow-up tickets. No downstream consumers are affected by the spike itself.
Note: the westside-app repo is archived on Forgejo, so the local copy at /home/ldraney/westside-app/ is the source of truth for the audit. The agent should not attempt to clone or pull from the archived remote.

Decomposition Assessment

No decomposition needed. Single repo, 2-hour time-box, read-only audit. The deliverable is a checklist document, not code changes. Well within a single agent pass. 0 file targets to modify, 2 acceptance criteria, estimated agent work under 5 minutes for the review (the spike execution itself is time-boxed at 2 hours but that is execution, not scope review).

Recommendation

  • [SCOPE] Create project-westside-ror project page with user-stories section — pre-existing gap, not blocking this spike.
  • [SCOPE] Evaluate whether arch-rails needs a dedicated architecture note or if the label should reference something more specific (e.g., arch-westside-ror) — pre-existing gap, not blocking this spike.
No action needed to unblock this spike. READY to move to next_up.