Skip to content

Mission run authority: parse, render and store the authority block - #6260

Merged
schickling-assistant merged 7 commits into
mainfrom
schickling/2026-11-10-program-engine-authority
Nov 10, 2026
Merged

schickling-assistant merged 7 commits into
mainfrom
schickling/2026-11-10-program-engine-authority

Conversation

@schickling-assistant

@schickling-assistant schickling-assistant commented Nov 10, 2026 •

Copy link
Copy Markdown
Contributor

Problem

The program engine design (docs/st3/program-engine.md §3, decision D2) has program steps act as mission-run/RUN with the authority the mission revision declares. There is no way to declare that authority today: a top-level mission has no authority child.

Goal

First of the M1.4 run-authority stack, split by risk: the declaration only. A top-level mission can declare authority { VERB "PATTERN" }; it parses, renders, is stored in the mission spec (so it enters the revision), and is held behind the fleet field barrier. Nothing binds a run actor or enforces the block here; later PRs add the run credential and binding, then enforcement (audit, then enforce).

Decisions

  • Grammar in the shape of the agent *-authority blocks: publish, start, revise, cancel take mission IDs as mission-authority does (no mission/ prefix); write takes a subject, or a registered family alone, before /*. A pattern is exact or ends in /*; any other * is refused, which keeps intersection of two rule sets exact later.
  • No "none" form: a mission without the block grants its runs nothing, so none would be a second spelling of absence.
  • MissionSpec.authority: Vec<AuthorityGrant>, kept in canonical order (reordering is not a revision) and omitted when empty, so undeclared revisions hash as before (pinned by the existing top_level_loop_retains_local_path_and_legacy_publication_hashes).
  • Top-level only (nested-mission-authority), like resources.
  • Mixed fleets: an older member re-hashes a replicated revision without the field and quarantines it. store/mission_capacity.rs already gated capacity on daemon.started.features.mission_capacity; it is now a table of mission-field barriers with a mission_authority row (mission-authority-unavailable), and the daemon advertises mission_authority=1. Program steps (M1.1a) will add their own row.

Verification

Focused tests, run on the Linux build host at this PR's code (via the stack head 5494372, which contains it; all pass):

  • fractal-missions-base: mission_authority_parses_in_canonical_order_and_enters_the_revision, mission_authority_refusals (every refusal code), canonical_mission_authority_round_trip (render → parse → render).
  • fractal-store: a_revision_that_declares_run_authority_waits_until_every_member_reads_it, plus the existing capacity barrier test on the generalized table.
cargo test -p fractal-missions-base --lib -- authority     -> 3 passed
cargo test -p fractal-store --lib -- declares_ ...          -> mission_capacity tests (capacity + run authority) passed

Hosted CI at the exact head is the proof; pushed with ST_EVIDENCE_LOCAL=off.

Complexity

High risk by docs/review.md: a trust/permission declaration and a new stored field in mission revisions. Lowered by landing it additive and unenforced, with the barrier keeping older members from quarantining it.

Concerns

  • The SQL in the barrier now reads $.fields.features and checks the feature in Rust, so one inventory site in docs/st3/large-value-sites.json moved id (proposal applied verbatim, guard passes).
  • The §3 design note (grammar, starter, intersection, credential, binding, journal, enforcement and its audit/enforce setting) is in docs/st3/program-engine.md (docs: accepted program engine design and build plan #6253 merged; main merged in).

Friction & bottlenecks

The shared build host is near its memory limit; builds are serialized across the program engine slices.

Follow-ups

  • Run credential, ancestry binding to mission-run/RUN, journal claims as the run (next PR).
  • Enforcement of declared ∩ starter authority at the write chokepoint, audit then enforce (daemon setting).

References

docs/st3/program-engine.md §3 (design #6253); docs/st3/seat-lanes.md "Mixed versions".

@schickling-assistant
schickling-assistant marked this pull request as ready for review November 10, 2026 16:16
@schickling-assistant

Copy link
Copy Markdown
Contributor Author

Review record for head 76665ee920aac22e85c966c35a20dbb895f44b46.

@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Nov 10, 2026
@schickling-assistant

Copy link
Copy Markdown
Contributor Author

Delta review record: independent reviewer GO, delta at 08bbc16b9214e7e4746c82efc1d9e5b04b4162c2. The only change since 76665ee920 is a one-line clippy-ratchet fix (*code → code, mission_capacity.rs:91) with no behaviour change. Risk medium. Queue on CI green at this head.

@schickling-assistant
schickling-assistant added this pull request to the merge queue Nov 10, 2026
Merged via the queue into main with commit 787e8ed Nov 10, 2026
38 checks passed
@schickling-assistant
schickling-assistant deleted the schickling/2026-11-10-program-engine-authority branch November 10, 2026 18:31

This branch was previously deployed

1 inactive deployment
evidence-signing — 08bbc16b Deployed Nov 10, 2026 by schickling via evidence-note-linux-gate #19532
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants