Review: Validate: linkedin-scheduler-remote (new CI, no steps)

review-516-2026-03-27 Review

review needs-refinement

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type — Task
  • [x] Scope — describes validation of PR #5 merge, CI error diagnosis
  • [x] Lineage — "Validation audit — session 2026-03-28 pipeline gap"
  • [x] User Story — present, well-formed
  • [x] Acceptance Criteria — 7 items listed
  • [x] Test Expectations — present (inline in scope, not separate section)
  • [x] Constraints — present, good guidance ("diagnose before fixing")
  • [x] Related — references project-pal-e-platform
  • [ ] Repo — MISSING. Template requires ### Repo section. Should state forgejo_admin/linkedin-scheduler-remote.
  • [ ] Checklist — MISSING. Template requires ### Checklist (PR opened, tests pass, no unrelated changes).

Traceability

  • [x] story:superuser-onboard — board item label present
  • [x] arch:ci-pipeline — board item label present
  • [x] Forgejo issue — forgejo_admin/linkedin-scheduler-remote#6, open

File Targets

Task type — no file targets required per template. Scope section used instead. OK.

Repo Placement

Issue filed on linkedin-scheduler-remote, work is on linkedin-scheduler-remote. Correct.

Dependencies

  • Board item #65 ("Add Woodpecker CI pipeline and k8s manifests" for same repo) — done. This validation is the natural follow-up.
  • Board item #517 ("Validate: gcal-mcp-remote") — sibling validation with identical failure pattern, not a blocker.
  • No items in in_progress block this work.

Acceptance Criteria

7 AC listed. Assessment:
  • Redundancy: AC 5 ("Pipeline verified"), AC 6 ("Deployment confirmed"), and AC 7 ("Features validated") overlap heavily with AC 3 ("Pipeline runs clean on retry") and AC 4 ("/metrics endpoint verified"). These appear to be boilerplate from a validation template. An agent could interpret them but they add noise.
  • Testability: AC 1-4 are agent-verifiable via Woodpecker MCP + curl. AC 5-7 are vague but achievable by restating them as AC 3+4.
  • Missing criterion: No AC for verifying the Harbor project exists for linkedin-scheduler-remote/server. The constraints mention checking this but no AC captures it.

Blast Radius

Critical finding: The investigation comment on issue #6 claims the primary issue is .woodpecker.yml needing rename to .woodpecker.yaml. This is incorrect. Verified:
  • gcal-mcp-remote already uses .woodpecker.yaml and still errors identically on push (pipeline #3 = error, "no steps found").
  • gcal-scheduler uses .woodpecker.yaml and all push pipelines error with the same pattern.
  • Woodpecker officially supports both .yml and .yaml extensions.
  • The consistent pattern: PR events succeed (test step only), push events error (build-and-push with Kaniko). This points to missing secrets + trust as the root cause, not file extension.
The same fix (secrets + trust) is needed across at least 3 repos: linkedin-scheduler-remote, gcal-mcp-remote, gcal-scheduler. Board item #517 covers gcal-mcp-remote. gcal-scheduler has no validation ticket yet.

Decomposition

7 AC (exceeds 5 threshold), but 3 are redundant boilerplate. Actual discrete steps: ~3 (add secrets, enable trust, retry pipeline). Single repo, single domain. No decomposition needed — consolidate AC to 4 and this fits a single agent pass under 5 minutes.

Recommendation

  • [BODY] Add missing ### Repo section: forgejo_admin/linkedin-scheduler-remote
  • [BODY] Add missing ### Checklist section (PR opened, tests pass, no unrelated changes)
  • [BODY] Correct investigation comment: file extension (.yml vs .yaml) is NOT the primary issue — Woodpecker supports both. Real primary cause is missing secrets + disabled trust. gcal-mcp-remote uses .yaml and fails identically.
  • [BODY] Add AC for Harbor project verification: "Harbor project linkedin-scheduler-remote exists and is accessible"
  • [BODY] Consolidate redundant AC 5-7 into AC 3-4 or remove them
  • [LABEL] No label changes needed — traceability is complete
  • [SCOPE] Clarify: should the agent also fix gcal-scheduler (same root cause, no validation ticket)? Or create a separate ticket?