pal-e-docs

Review: Validate gcal-mcp-remote (new CI, no steps)

review-517-2026-03-27 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type -- Task
  • [x] Scope -- present (replaces File Targets for Task type)
  • [x] Lineage -- present (inside Scope section)
  • [x] User Story -- present
  • [ ] Repo -- MISSING. No explicit ### Repo section. Should state forgejo_admin/gcal-mcp-remote.
  • [ ] Context -- MISSING. Scope section has partial context but no dedicated ### Context section explaining why this work exists.
  • [x] Acceptance Criteria -- present (6 items, but see quality issues below)
  • [x] Test Expectations -- present (inline, not a separate section)
  • [x] Constraints -- present
  • [ ] Checklist -- MISSING. No ### Checklist section with PR/test checkboxes.
  • [x] Related -- present

Traceability

  • [x] story:superuser-onboard -- board item label present
  • [x] arch:ci-pipeline -- board item label present
  • [x] Forgejo issue -- forgejo_admin/gcal-mcp-remote#6, open
All three legs verified. Traceability is complete.

File Targets

Task type -- file targets not required per template convention. The work involves Woodpecker admin configuration (secrets, trust settings) and possibly .woodpecker.yaml if the parse error is a YAML issue.

Repo Placement

OK. Issue is filed on forgejo_admin/gcal-mcp-remote and the fix is for that repo's CI pipeline. Single-repo scope is correct.

Dependencies

  • Board #516 (linkedin-scheduler-remote validation) -- sibling ticket with identical labels (type:task,arch:ci-pipeline,story:superuser-onboard,scope:validation) and identical root causes (no secrets, trust disabled, no steps parsed). These should reference each other.
  • Board #63 (gcal-mcp-remote#3 -- original CI pipeline creation) -- in done column. This is the parent work that created the .woodpecker.yaml. The pipeline passed on PR events (#1, #2 succeeded) but failed on merge-to-main push (#3 errored).
  • No blocking dependencies in in_progress column.

Acceptance Criteria

6 AC items. Quality issues:
  • AC #1 (diagnosis) and AC #2 (identify fixes) -- good, verifiable
  • AC #3 (pipeline runs clean on retry) -- good, verifiable via Woodpecker API
  • AC #4 (pipeline verified) -- vague, overlaps with AC #3
  • AC #5 (deployment confirmed) -- vague. What deployment artifact? Image in Harbor? Pod running in k8s? This is a new CI pipeline with no ArgoCD app yet.
  • AC #6 (features validated) -- vague. What features? This is CI infrastructure, not application code.
Recommend consolidating to 4 clear AC: (1) root cause documented, (2) secrets + trust configured, (3) pipeline green on retry, (4) container image pushed to Harbor registry.

Blast Radius

linkedin-scheduler-remote has identical issues. Board #516 is the exact sibling -- same batch of CI pipeline creation, same failures. Both repos: zero repo secrets, trusted=false, "no steps found" on main push. A fix pattern validated on one repo should be applied to both.
Compared to a working repo (pal-e-api): harbor_username and harbor_password secrets are configured as repo secrets. Note that pal-e-api also has trusted=false, so trust may not be the root cause of the parse error -- the "no steps found" issue may be a separate Woodpecker config/parser problem.

Decomposition

No decomposition needed. Single repo, 3-4 effective AC, estimated <5 minutes agent work. The fix is: configure Woodpecker repo secrets, debug the YAML parse issue, retry pipeline.

Recommendation

  • [BODY] Add ### Repo section: forgejo_admin/gcal-mcp-remote
  • [BODY] Add ### Checklist section with standard PR/test checkboxes
  • [BODY] Consolidate AC #4-#6 into specific verifiable criteria: "Container image pushed to Harbor" replaces the three vague items
  • [BODY] Add cross-reference to sibling ticket: forgejo_admin/linkedin-scheduler-remote#6 (identical issues)
  • [BODY] Incorporate investigation findings from existing comment into issue body -- root causes (no steps parsed, missing secrets, trust disabled) should be in the spec, not just a comment
  • [SCOPE] Clarify: does "deployment confirmed" mean a k8s pod running? Or just image in Harbor? This repo may not have an ArgoCD app yet.