Ticket graphs

INVARIANT: no code runs in production (the congruency.jazz-stack.com droplet) that is not a BLESSED crank — the shadow gate passed AND it was authorized — and the deploy/run/rollback of the droplet is itself an AUDITABLE, checks-and-balanced procedure whose provenance is recorded in congruency. Today production is OUTSIDE the crank discipline; this RFC is to research the right way to bring it in and then take the follow-up actions. WHY (measured 2026-07-19): the droplet was stood up ad-hoc during bring-up and the deploy pipeline (deploy/droplet/deploy.py + the artifact/rotate tooling) sits beside the discipline, not inside it. Three gaps, all verified against the live DB: (1) the deployed tags version-4.200/4.201/4.202 are PRIVACY-SWEPT ORPHAN REBUILDS from rebuild_deploy_repo.py — they never went through mint_crank, so by construction they can never have a crank_runs blessing row; the sweep step SEVERS the tag from its canonical crank. (2) crank_runs on the droplet is EMPTY (0 rows) and run.version returns nothing for any version — a naive blessing gate would refuse everything. (3) the formal gate crank_discipline.gate() has NO production caller; mint_crank reimplements a subset inline and does NOT refuse when no ticket is open (records authorized_by='policy', ticket_id=NULL). Real enforcement lives at the crankd daemon boundary. So 'deploy only blessed cranks' and 'deploy only privacy-swept code' currently CONFLICT. RESEARCH (investigate properly before building): (a) Reconcile the sweep/orphan lineage with blessing — how does a swept deploy artifact CARRY and PROVE its canonical source version's blessing? (rebuild records the source version; deploy verifies THAT version via run.version). (b) Is a production deploy itself a CRANK-GATED action (needs its own ticket + wallet approval, like crank_approve) or only a DOWNSTREAM VERIFIER of an existing crank blessing? (c) The blessing linkage details: run.version (migrations/0036) ok=1 + ticket_id NOT NULL; the TWO-DIGEST problem (crank_runs.digest = sha256(shadow transcript) vs crankd's ticket-content digest that crank_approve signs — they tie only via ticket_id); the version- prefix (tag version-4.146 vs bare 4.146). (d) The authorization model for production: human wallet approval vs standing policy; who may authorize a deploy; the audit-veto and rollback governance. (e) COORDINATION: crankd is under ACTIVE REFACTOR right now — the deploy governance must be designed against where crankd is going, not where it was; do not fight the in-flight work. FOLLOW-UP ACTIONS (deploy, run, develop the governance): (1) DEVELOP — bridge sweep->blessing; wire deploy.py to verify the source crank's blessing (refuse UNBLESSED, treating 'no crank_runs row' as unblessed, not pass); record every droplet deploy's provenance in congruency (a deploy_runs record or reuse crank_runs). (2) INCORPORATE CHECKS & BALANCES — production-deploy authorization (approval signature), audit trail, rollback-as-governed-action, separation between minting/blessing (crankd) and deploying (deploy.py). (3) DEPLOY & RUN the procedure itself and prove it end-to-end on the droplet. DELIVERABLE: an RFC document (docs/RFC-DROPLET-GOVERNANCE.md or next RFC number) capturing the as-decided procedure + state machine, and SPAWNED build tickets for each follow-up action. REFERENCES: deploy/droplet/deploy.py, deploy/droplet/rebuild_deploy_repo.py, forge2/agent_tools_suite/{crankd,crank_discipline,crank_approve,audit_guard}.py, tools/mint_crank.py, migrations/0006_crank_runs.sql + 0036_required_params.sql (run.version), and the bring-up record in ~/code/congruency_changes/. Relates to the crank discipline (blessing) and the privacy-sweep lineage (rebuild_deploy_repo.py).

— browse congruency source (forge-parked tree)