Build Launchplane-backed Every Code automation

[cbusillo]

Objective

Move Every Code issue-triggered automation from a GitHub API polling script into Launchplane-owned durable ingress, queueing, status, and future UI records.

Finish Line

Every Code issue labels create durable Launchplane work requests that a local Mac worker can claim and run visibly

Current Status

State: Core Launchplane-backed Every Code automation is implemented and deployed. Main now has durable work-request records/API/storage, signed GitHub issues.labeled webhook ingress, a local every-code run-once tmux worker handoff, and every-code reconcile-issue for missed/manual issue-label reconciliation without high-volume GitHub polling.
Next action: Validate with a real every-code labeled issue in the live GitHub webhook setup, then decide whether to add a follow-up for a long-running worker daemon or scheduled wrapper.
Blocked by: Real-world webhook/label setup only; the tracked implementation scope is complete.
Last verified: 2026-05-06, PR #290 main CI/Security/CodeQL passed and Deploy Launchplane succeeded for ac426f4.

Scope

• Add Launchplane contracts for Every Code webhook deliveries, normalized work requests, worker claims, status transitions, and result metadata.
• Add DB-backed storage and idempotency around GitHub delivery IDs and work-request claims.
• Add authenticated GitHub webhook ingress for issues.labeled events carrying label every-code.
• Add worker-facing APIs for a registered local host to claim work and report progress/results.
• Preserve the local Mac as the executor for visible tmux/Code sessions; Launchplane should coordinate, not directly open local terminals.
• Add read models that a future Launchplane UI can use to show queued/running/done/blocked automation.
• Keep a low-frequency reconciliation path for missed webhook deliveries.

Acceptance Criteria

• A GitHub webhook payload for issues.labeled + every-code creates exactly one durable work request per delivery/issue trigger.
• Duplicate webhook deliveries are deduped by X-GitHub-Delivery and/or normalized work-request identity.
• Untrusted or out-of-scope requests fail closed with an inspectable blocked/skipped status.
• A local worker can claim one pending request without races and report running/done/blocked status.
• Work-request state is queryable from Launchplane service read endpoints for future UI use.
• GitHub API usage is event-driven and does not require per-minute scans across all active repos.
• A fallback reconciliation flow can identify missed labeled issues without reintroducing high-volume polling.

Relationships

• Related prototype: feat(scripts): add local Every Code issue poller code#26 adds the first local shell poller and tmux job launcher.
• Related Launchplane workstream: Absorb remaining product-repo orchestration into Launchplane drivers #164 absorbs remaining product-repo orchestration into Launchplane drivers.
• Future UI surface can build on the product/environment operator UI workstream.

Validation

• Unit tests for webhook payload adaptation, signature/idempotency handling, request-state transitions, trust gating, worker claim concurrency, and read models.
• Service-level tests for ingress, worker claim/status routes, and duplicate webhook delivery behavior.
• A manual local smoke test can post a captured webhook fixture to Launchplane, claim it from the local worker, and verify the tmux job launcher receives repo/issue coordinates.

Decisions

• Launchplane owns durable coordination; the local Mac owns visible execution.
• Repository topic every-code remains enrollment metadata, not the hot-path polling mechanism.
• Issue label every-code remains the human approval/trigger.
• The standalone poller should become fallback/prototype material rather than the final trigger architecture.

Open Questions

• Should ingress use a GitHub App webhook from the start, or start with repository webhooks and migrate to an App?
• What is the first worker authentication mechanism: Launchplane-issued worker token, Tailscale identity, or another host registration flow?
• Should trusted-label authorization be based on GitHub App permission lookup, explicit Launchplane allowlist, or both?
• How much of the existing shell worker should stay in code versus become a Launchplane companion worker command?

[cbusillo]

Closed after PR #290 deployed. Launchplane now has durable Every Code work-request records/API/storage, signed GitHub label webhook ingress, local tmux worker handoff, and fallback issue reconciliation without high-volume polling. Main CI/Security/CodeQL passed and Deploy Launchplane succeeded for ac426f4.