GameCult/Idunn
Watch
9
0
Fork
You've already forked Idunn
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Idunn/docs/deploy-provenance-target.md
Eureka d5ea779096 Idunn: static release transaction (flip in Starting) and the v5 control record 
A static release is the same DeploymentTransaction in three phases: Sealing,
Starting (carry and flip, behind the deployment brake) and Complete. It has no
Expected, activation, workload, warming, isolation, fencing, leasing, ready or
routing, and creates no AdmittedGeneration.

DeploymentTransaction gains key 37 `flip` (FlipEvidence: release, previous
release, carry source, carried sha256, time). Adding a key changes the bytes of
every record, and the control store refuses a record that does not re-encode to
what is stored, so this is schema idunn.deployment_transaction.v5. The v4
layout is kept as LegacyDeploymentTransactionV4 and lifted by the existing
mechanism (read_transaction_record, history decode, and the boot migration,
which rewrites v4 records in control.cc to v5). Migration is forward-only: an
Idunn that predates v5 cannot read a migrated control.cc.

Also: is_static() and brake_subject() (the brake names the binding's runtime id
and the sealed release, read by deployment_authorization, durable-authority
validation and status); validate_static; advance_sealing skips readiness_class
and expected_projection for static; advance_starting delegates to
advance_static (intent with the previous release read from current_link,
carry_and_flip then record, observe link == release, then Complete with
Admitted{generation-<tx>} and post_commit_cleanup(SkippedNoIncumbent, source
Pending)); a failure in Starting takes the existing pre-fencing abort;
Engine.static_release Arc<dyn StaticReleasePort>. Docs: a Static release
section in deployment-authority.md and a scope line in
deploy-provenance-target.md.

Tests: control_plane::tests::static_release_ (3), a pinned v4 record lifts and
re-encodes as the pinned v5, a v4 control store copy in a temp dir migrates to
v5 and an already-v5 store is untouched byte for byte, and the pinned-bytes
test now pins v5 with the v4 bytes kept as a legacy fixture. The test runner is
a stand-in over the real seal_artifact behind a cfg(test) Engine seam, because
DockerRunnerDriver workspace ownership requires root.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-11-13 16:32:06 +00:00

3 KiB
Raw Blame History

Deployment provenance instead of an approval gate: target

Status: target, Self, 2026-10-19 (campaign idunn-deploy-provenance in Eureka's mind). It states the ends. The map will live in deploy-provenance-map.md.

Why

Operator, 2026-10-19:

The rule about the deployment brake was instituted by a cautious agent, but it doesn't actually suit how GameCult operates. The whole point of Eureka is to give the Mind, Persona and Self agency over its own Body. It's requiring my approval for every deployment that violates our principles. Yes, we certainly want to know which agent approved the deployment and why (this is the authority provenance which we might want to add to the transaction), but that's not the same as gating every deploy on my approval.

On the same day a StreamPixels deploy (tx-b40c7240) waited on the brake because only the root-held operator identity could release it. The agent running the deploy could neither proceed nor record why it should.

F:\Projects\CLAUDE.md says a deployment brake may gate artifact, revision, configuration, schema, unit or authority changes. It does not say that operator approval is the gate.

Invariants

  1. No deployment waits on a per-transaction operator approval. An agent acting for the Mind, Persona or Self may admit a deployment of a target it is authorized for.
  2. Every transaction carries typed authority provenance. That is: who approved it (agent or instance, and faculty), under which session or ruling, and why. It is written before Fencing, it is immutable, and idunn status and history show it. It is part of the transaction document, not a log line.
  3. A brake that survives is a stop, not a gate. The operator or an authorized agent can halt deployment of a target, and the halt is itself provenance-bearing. The deployment brake and the continuity lifecycle brake stay separate (F:\Projects\CLAUDE.md Infrastructure). Neither gates Idunn itself, and the deployment brake never gates continuity.
  4. Existing invariants hold. These are idunn-reincarnation target r2, route-continuity-target.md 1-7 and authority-map.md.

Scope

In:

  • The deployment-brake release path in Idunn and idunn-provision.

  • The provenance record on the transaction.

  • idunn status and history projection of the provenance.

  • The gamecult-ops runbooks that describe a per-transaction operator release (heimdall-discord-launch.md, idunn-host-raven.md, the StreamPixels runbook).

  • A static release (a sealed tree published by repointing a link, with no workload): its transaction records flip (release, previous release, the sha256 of the carried per-site file) beside the brake bytes. See deployment-authority.md, "Static release".

Out:

  • idunn-reincarnation. This campaign is mapped after that campaign's cut 2 merges, and coordinates with it rather than bundling.
  • Harness permission rules on the workstation, which are the operator's.
  • Heimdall's onboarding failures.