Review: Close stale pal-e-app / pal-e-docs-app rename tickets

review-973-2026-04-11 Review

review needs-refinement

Verdict: NEEDS_REFINEMENT

Housekeeping ticket to close 5 obsolete rename-trail issues and remove 2 board items. Scope is sound in direction and reasoning, but one of the five listed tickets is already closed, and there are two small accuracy issues to fix before the ticket can move to todo. Once corrected this is a clean single-agent close-out job (well under 5 minutes).

Template Completeness

  • [x] Type (Bug)
  • [x] Lineage
  • [x] Repo
  • [x] What Broke (with per-ticket table)
  • [x] Repro Steps
  • [x] Expected Behavior
  • [x] Environment
  • [x] Investigation / Decision Per Ticket (wontfix rationale each)
  • [x] Acceptance Criteria
  • [x] Related
  • [ ] User Story + Architecture sections missing from body — the bug template allows implicit story/arch via board labels, and story:superuser-maintain + arch:k8s-deploy are present on the board item (scope:discovered), so this is acceptable and not blocking.

Traceability

  • [x] story:superuser-maintain label on board item — verified in project-pal-e-docs user-stories table (Superuser CRUD via MCP, not direct SQL). Housekeeping closures are exactly that kind of maintenance.
  • [x] arch:k8s-deploy label on board item — conceptually valid (touches deployment topology). Note: no dedicated arch-k8s-deploy note exists in pal-e-docs; the closest backing note is arch-domain-pal-e-docs. Creating a dedicated arch-k8s-deploy note is beyond this ticket's scope (housekeeping, not architecture). [SCOPE] — file a separate backlog ticket later if the arch:k8s-deploy label is going to keep being used across multiple issues.
  • [x] scope:discovered label — correct, this came out of the 2026-04-11 routing review with Lucas.
  • [x] Forgejo issue — forgejo_admin/pal-e-platform#279, open, URL valid.
  • [x] Forgejo labels on issue itself — empty. Not a blocker (board item carries the triangle) but worth a [LABEL] mirror for consistency if convention requires.

File Targets

N/A — no file targets. This ticket acts on Forgejo issues and board items via MCP tools (mcp__forgejo__update_issue, mcp__forgejo__comment_on_issue, mcp__pal-e-docs__remove_board_item). One exception: the last AC asks for a note added to feedback_naming_convention — see Accuracy Issues below.

Repo Placement

OK. pal-e-platform is the correct home — the work spans tickets in multiple repos (pal-e-platform, pal-e-apppal-e-production) but the umbrella action is cross-cutting housekeeping owned by the platform repo. Closures are API-level, no repo code touched.

Dependencies

Depends on forgejo_admin/pal-e-platform#278 (hostname swap). The ticket body references "the canonical hostname swap ticket" in Related but does not cite the number. This is the only dependency; it is live on the board as item #972, backlog, not in progress. The "after the dust settles" framing from the spawn prompt is sound: if #278 discovers that one of the five obsolete tickets still has salvageable intent at the new topology, that intent survives as a new ticket rather than a revival. No circular dependency. No other ticket blocks this one.

Acceptance Criteria

Each AC is machine-verifiable:
  • [x] Closing comments — verifiable via curl GET /issues/{n}/comments
  • [x] State = closed + wontfix label — verifiable via issue API
  • [x] Board items removed — verifiable via list_board_items(board-pal-e-docs)
  • [x] "No new tickets filed by this pass" — verifiable by absence
  • [x] feedback_naming_convention note updated — but see Accuracy Issues, the referenced note may not exist under that exact slug; needs slug confirmation

Blast Radius

Low. Closing wontfix issues and removing board items is reversible in Forgejo and pal-e-docs MCP. No CI triggered, no code changed, no downstream consumers affected. The only risk is mistaking a still-actionable ticket for an obsolete one — addressed by the per-ticket decision table in the body and double-checked below.

Per-Ticket Verification

Fetched each target via Forgejo API as of 2026-04-11:
  • pal-e-platform#234 (ImagePullBackOff) — state=open. Body references pal-e-docs-app namespace and Harbor image paths that no longer exist. Closing rationale is sound: pod is gone, namespace is gone, image path is obsolete. Close as wontfix. No salvageable intent at current topology (the "fix ImagePullBackOff" intent died with the namespace).
  • pal-e-platform#255 (Keycloak client rename pal-e-docs-apppal-e-app) — state=open. Direction is obsolete on both sides. Closing rationale is sound. Flag: the underlying intent — "the Keycloak client ID should match the canonical deployment name" — is still relevant. If the Keycloak client is currently named pal-e-app or pal-e-docs-app but the deployment is pal-e-production, this is live drift that Lucas may want fixed as part of #278 (hostname swap) or as a new standalone ticket. The body of #279 already covers this in its own decision note ("separate ticket if anyone cares to file it") — which conflicts with AC #4 ("no new tickets filed by this pass"). Not a blocker but worth calling out: intent-survives-rename means someone should decide whether to spin up a new Keycloak-rename ticket against the current deployment name, or explicitly defer.
  • pal-e-platform#257 (Namespace rename pal-e-docs-apppal-e-app) — state=open. Same analysis as #255: direction obsolete on both sides, underlying intent ("namespace should match deployment identity") is subsumed by the hostname-swap ticket #278 which already owns the k8s topology reshape. Close as wontfix. Intent covered by #278.
  • pal-e-app#87 (Rename pal-e-app → pal-e-docs-app) — state=CLOSED. Already closed on 2026-03-28T17:01:43Z. The ticket body of #279 lists this as one of the 5 to close, but it is already in the desired state. Any closing comment added now must acknowledge the ticket is already closed and only needs a pointer comment, not a state change. Board item #510 still needs removal regardless.
  • pal-e-app#88 (Validate session 2026-03-28 merges — 4 PRs) — state=open. Body is about validating pipelines #98-#101 and PRs #83-#86 from a session on the old pal-e-app repo. The repo is gone (redirects to pal-e-production). Validation target is moot. Close as wontfix. Board item #513 needs removal.

Board Item Verification

  • [x] Board item #510 — present on board-pal-e-docs, backlog, title "Rename pal-e-app → pal-e-docs-app", links to pal-e-app/issues/87. Ready to remove.
  • [x] Board item #513 — present on board-pal-e-docs, backlog, title "Validate: pal-e-app (4 PRs, clone failure)", links to pal-e-app/issues/88. Ready to remove.

Accuracy Issues (must fix before todo)

  • [BODY] pal-e-app#87 is already closed (2026-03-28). The per-ticket decision table and Investigation section both imply #87 is currently open. Update the body to acknowledge the existing closed state: "Already closed on 2026-03-28 — add a pointer comment only, no state change needed. Board item #510 still requires removal."
  • [BODY] Related section cites "the canonical hostname swap ticket" without a number. Add the explicit reference: forgejo_admin/pal-e-platform#278. The dev agent closing the tickets will paste this link into each closing comment; the link must be unambiguous in the source ticket.
  • [BODY] AC #5 references feedback_naming_convention but this slug is not confirmed to exist. The memory index mentions feedback_naming_convention.md (a local memory file, not a pal-e-docs note). The last AC should clarify whether the lesson goes into (a) the user's memory file, (b) a new pal-e-docs note, or (c) is dropped entirely as out-of-scope for a housekeeping pass. Recommendation: drop this AC. Lessons about rename trails belong in a separate docs ticket, not bolted onto a closure pass — otherwise the housekeeping ticket quietly grows into a two-agent job.
  • [SCOPE] Intent-survives-rename tension in AC #4. The decision notes for #255 and #257 say "separate ticket if anyone cares to file it" while AC #4 says "no new tickets filed by this pass". Resolve: explicitly defer any Keycloak/namespace rename-to-current-topology work to a follow-up under #278, and drop the "if anyone cares to file it" language so the agent doesn't interpret it as optional scope creep.

Decomposition Assessment

No decomposition needed. Applying the 5-minute rule:
  • File targets: 0 (API-only operations)
  • Acceptance criteria: 5 (under the 5-AC threshold; AC #5 should be dropped per accuracy issue #3, bringing it to 4)
  • Estimated agent work: ~2-3 minutes for a single agent — four mcp__forgejo__update_issue calls (close+wontfix for #234, #255, #257, #88), one mcp__forgejo__comment_on_issue pointer on the already-closed #87, five closing comments total, and two mcp__pal-e-docs__remove_board_item calls for #510 and #513. All operations are independent and idempotent.
  • Repos touched: 1 (pal-e-platform for the umbrella ticket, plus cross-repo API calls — not true decomposition triggers)
Housekeeping tickets are inherently flat. One agent, one pass, done.

Recommendation

  • [BODY] Note that pal-e-app#87 is already closed (2026-03-28); only a pointer comment + board item removal is needed.
  • [BODY] Cite forgejo_admin/pal-e-platform#278 explicitly in the Related section as "the canonical hostname swap ticket".
  • [BODY] Drop or clarify AC #5 (feedback_naming_convention update) — the slug is not a confirmed pal-e-docs note, and the lesson belongs in a separate docs ticket.
  • [BODY] Reconcile AC #4 with the per-ticket decision notes: explicitly defer any Keycloak/namespace rename-to-current-topology intent to follow-up work under #278, rather than leaving "file a new ticket if anyone cares" language in the body.
  • [SCOPE] Optional: flag for Ava that if the Keycloak client ID currently drifts from the pal-e-production deployment name, a forward-facing Keycloak rename ticket should be queued under #278 — separate decision, not this ticket's job.
  • Depends on #278 — confirm spawn prompt guidance (land this after the hostname swap dust settles) is respected on the board; do not advance #973 past todo until #278 is in at least in_progress.