Skip to content

plane-delete-test: a pinned plane is deleted by its pin and feature (stacked on #888) - #894

Merged
MattJackson merged 15 commits into
predevfrom
lane-plane-delete-pinned
Oct 15, 2026
Merged

MattJackson merged 15 commits into
predevfrom
lane-plane-delete-pinned

Conversation

@MattJackson

Copy link
Copy Markdown
Collaborator

Stacked on #888, which is stacked on #838. Once both land, this is one commit touching two scripts. Not $.

scripts/plane-delete-test.sh, the manual strong-form harness (not in .ci), assumed every plane is a crates/busbar-<P> directory. Spec #39 (BUSBAR-1.6.0.md l.2220) says plugin source never re-enters busbar. So for a plane pinned from its own repo (mcp in #838, decisions in #888), deleting it means dropping its root pin row plus the bin's workspace = true rows and its feature, not git rm -r.

What

  • pinned_in / plane_present:
    • A plane is PINNED when the root pins it as a git row and nothing of it is on disk.
    • A plane on disk is never read as pinned.
  • drop_member also drops the pin row. The key is matched exactly, so a -plugin twin row is not taken with it.
  • neutralise_bin matches the { workspace = true …} row (normal and dev) as well as the path row.
  • remove_and_assert:
    • PINNED is a removable state. ABSENT is still refused, and the renamed-crate RED control still holds.
    • After the removal it asserts zero pin rows, zero bin rows and a rewritten root.
    • A pinned plane must have been named by the bin.
  • Selftest (6b) and the roster-coverage check accept a pinned one-crate plane. The decisions roster line passes again.
  • scripts/plane-keys.sh: two comments now describe the pinned layout. No code changes.

Checked (no cargo build)

  • remove_and_assert asserts the removal of llm, a2a, voice, plane-mcp and plane-decisions on scratch copies:
    • plane-mcp: PINNED->GONE, bin rows 2->0.
    • plane-decisions: PINNED->GONE, bin rows 1->0.
  • An unknown plane is refused.
  • cargo metadata loads the scratch after each pinned removal.
  • bash -n is clean.

Overlap: #824 (draft, llm default) edits bin_feature on line 207. This PR does not touch that line.

…p, pulled at a pinned rev; every gate reads the pinned planes as its base layer (P5, rows 106/107)

- crates/busbar-plane-mcp is deleted. GetBusbar/busbar-plane-mcp holds it, history imported with
  filter-repo; its logic crate is predev 00555bd's crate and its -plugin cdylib runs busbar's
  published conformance suite. The root pins it as one git row; the root's two edges take the
  workspace row; deny.toml allows the repo; plugins.yaml drops pending_crate and checks busbar out
  (its tests read the battery and qa/method-inventory.json at the pin).
- THE BASE LAYER (ARCHITECT row 106 (A)): Ctx gains a base beneath the overlay and above the disk.
  Ctx::workspace lays every pinned package of the plane kind at crates/<package>, read from the
  checkout cargo metadata resolves for the rev Cargo.lock pins (kind_isolation::plane_base), never
  written into the tree. with_overlay keeps it, so a plant still wins. Generic over the kind, no
  plane named. Fails closed: a pinned plane cargo cannot resolve is an Err naming it and its rev.
  kind-isolation's own mount is unchanged. No ledger row moves.
- RED arms: xtask/tests/pinned_planes_base.rs (the base is laid from the checkout and nothing of it
  is on disk; a plant wins over it; structure-lint, config-schema, no-float-money, plane-purity and
  reachability each lose a passing row without it); declared_classes reads the pinned planes and
  none without the base.
- The tests that read the filesystem resolve a pinned plane through the same rule
  (crates/busbar/tests/common/pinned_planes.rs): capability-equality's proven mcp-server cells and
  its five-plane floor (with a RED arm that the evidence is not on disk and is read from the
  checkout); the kernel trust and core-admin plane-key ratchets take the pinned planes' keys;
  proto-deletion-gate.sh reads the door crate from its checkout.
- plugin-ci.yml: a plane repo runs plane-purity, structure-lint and config-schema at its busbar pin
  over its own change (scripts/fleet/plane-gates.sh, BUSBAR_PLANE_SOURCE): no row that passes over
  busbar's pinned plane may fail over the change.
… take the pinned planes too (tests/common/pinned.rs, fail-closed), and the sibling set is every plane the roster registers, with its five-plane floor (ARCHITECT row 106 (A))
…a door home; the plane step is an xtask plugin-gate; the pin moves to the merged plugin head

- Ctx::exists and Ctx::is_dir answer a directory the base layer lays (a pinned plane's crate and
  every directory in it), and Ctx::base_children lists what it lays under a directory: qa-names,
  plane-purity:roots, plane-pricing-blindness and structure-lint's scope rows read the pinned plane
  where it lived. construction's glob_dirs lists the laid crate beside the disk's, so the census's
  plane glob still matches its five crates.
- workspace-deps: a manifest the base lays is a pinned git dependency, never a crate on disk.
- PlaneRoots::over(cx): a door crate the base lays is its plane's door home (settings-leak,
  response-header, blocking-ffi).
- plugin-ci's plane step is `xtask plugin-gates plane` (the busbar gates over busbar's pinned plane
  and over the change, a row that stops passing is a finding), with selftest cases; the shell
  script is gone (script-allowlist: product checks are cargo xtask).
- busbar-plane-mcp pinned at a5e2ae355c, the head GetBusbar/busbar-plane-mcp#10 merged.
…oml keeps predev's store-memory row (no fixture-store: the kernel links an in-crate store double) beside this lane's busbar-plane-mcp pin
…s; the root pins it (/status rows 106/107)

BUSBAR-1.6.0.md l.2220 (#39): "plugin SOURCE never re-enters busbar". l.3962: extract each
plugin crate to its repo, pinned back as a git dependency in the root manifest's linked rows.
This takes the same shape as #838 for mcp and stacks on its base layer (ARCHITECT row 106 (A)).
Crates go 23 -> 22.

- crates/busbar-plane-decisions is deleted. GetBusbar/busbar-plane-decisions#13 carries predev
  5c99bef's crate byte for byte, with tests/conformance.{rs,json} in its -plugin twin, at
  busbar pin 5c99bef. The root pins that PR's head d78c070da4 with one git row. The
  `plane-decisions` edge in crates/busbar takes the workspace row.
- deny.toml allow-git gains the repo. plugins.yaml drops pending_crate. The decisions tests read
  none of busbar's files, so it needs no busbar_checkout.
- Cargo.lock: busbar-plane-decisions resolves from git. busbar-contract stays patched to the path
  crate, and the plugin-loader dev edge leaves with tests/conformance.rs.
- Every gate, test and script that reads crates/busbar-plane-decisions reads it through #838's
  base layer and pinned_planes resolver: Ctx::workspace lays every pinned plane at
  crates/<package> from its checkout, and nothing in it names a plane. So no reference in xtask,
  the tests or the ledgers changes. Ledgers: none touched (#838's ruling condition 6). The
  pinned plane is measured at the path it had, from the same bytes.
- .ci/default.yaml already builds the pinned busbar-plane-decisions-plugin cdylib ("plugin
  busbar-plane-decisions busbar-plane-decisions-plugin optional").
…its feature, not by git rm crates/busbar-<P>

BUSBAR-1.6.0.md l.2220 (#39): plugin source never re-enters busbar, so a plane that left for its own
repo (P5: mcp #838, decisions #888) has no crates/busbar-<P> directory and no workspace member. Its
strong-form removal is the root's `busbar-<P> = { git = …, rev = … }` pin row plus the bin's
`busbar-<P> = { workspace = true, … }` rows and the feature that names it.

- pinned_in / plane_present: a plane is PINNED when the root pins it as a git row and nothing of it
  is on disk. A plane on disk is never read as pinned.
- drop_member also drops the pin row. The key is matched exactly, so a -plugin twin row stays.
  neutralise_bin's dependency pattern takes the workspace row as well as the path row.
- remove_and_assert: PINNED is a removable state, as PRESENT is. ABSENT is still refused. After the
  removal it asserts zero pin rows and zero bin rows, a rewritten root, and a pinned plane that the
  bin named in at least one row.
- Selftest (6b) and the roster check accept a one-crate plane that is pinned. The decisions roster
  line passes again, for mcp and decisions alike.

Checked without cargo build: remove_and_assert over llm, a2a, voice, plane-mcp and plane-decisions on a
scratch copy (all asserted; the renamed-crate control is still refused), and `cargo metadata` loads
the scratch after each pinned removal.
… pinned-plane helper by reference (root is a PathBuf; E0308 at :1233)
…ut (dirs_for_globs filters with Ctx::is_dir, disk then base layer); RED: a plane present only in the base layer is counted
…dirs_for_globs counts a pinned plane from the base layer) into lane-p5-extract-plane-decisions
…er the scan roots (a pinned plane's crate), so rules that read lines read a pinned plane; RED: forbid-unsafe finds the attribute in a base-laid plane's lib and reports its absence MISSING
… scan carries pinned-plane sources; forbid-unsafe MISSING fix) into lane-p5-extract-plane-decisions
MattJackson added a commit that referenced this pull request Oct 15, 2026
…lares.json in the tree

#887 (row 114) wrote crates/busbar-plane-decisions/declares.json and
crates/busbar-transport-stdio/declares.json while both crates lived here; #901/#894 (under
#935) moved both crates to their own repos, which hold their own declares.json at the
pinned revs (plane-decisions/declares.json needs http, transport-stdio/declares.json needs
none; plugins.yaml points there). The two orphans left crates/<package> as directories on
disk, and the pinned base mounts a pinned crate only where no directory sits, so every gate
reading pinned plugins (reachability, plane-purity, plane-pricing-blindness, structure-lint
plane-roots, forbid-unsafe, config-schema tracked sources) read the decisions plane and the
stdio transport as absent.
@MattJackson
MattJackson merged commit 17b41a3 into predev Oct 15, 2026
1 check was pending
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.

1 participant