Skip to content

Single-use rung drop: admit one D0 lifecycle for group-a while the store walls are unfinished - #12744

Merged
gunbai-bot[bot] merged 1 commit into
mainfrom
lively-dove-256-d0drop
Sep 30, 2026
Merged

gunbai-bot[bot] merged 1 commit into
mainfrom
lively-dove-256-d0drop

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Sep 30, 2026

Copy link
Copy Markdown
Contributor

Operator ruling, 2026-09-30, option A, relayed by proud-deer-538: take the fabric store walls off DS4.1's critical path with a declared, single-use rung drop.

The row: gunbc.rung_drop.d0_store_walls_single_lifecycle.

  • Previous rung: MechanicallyPreventable. Both store walls are required before D0 runs.
  • Temporary rung: Mitigatable. One operator-admitted lifecycle runs.
  • Reason: ReplacementStaged. The store walls are in flight: Fabric store per-operation admission fold (d0_store_operation_wall PR 4a) #12537 and the rest of the d0_store_operation_wall chain.
  • Population: exactly one D0 lifecycle, FabricGroupA under escalation id d0-group-a-ds41-2026-09-30, including reruns of that same lifecycle (same id, the frozen filing's execution revision). No other id and no other group.
  • Restoration trigger: both walls live. fabric_storage_append_principal_unrefused retired and effective on srv1, and d0_store_operation_wall at StoreOperationWallRestored, sufficient for a rostered writer without D0 authorization to be refused at the store.
  • Projection: docs/design-rung-drops.md regenerated locally with generated_artifact_gate main_wet: exit 0, one path changed.

The gate. gunbc.spark.pair_serving_d0 d0_store_write_wall_standing(group, escalation_id):

  • if both walls are finished, every lifecycle is admitted;
  • otherwise only the declared lifecycle is admitted (d0_single_lifecycle_admits), and every other lifecycle gets the walls' refusal exactly as today.

The wet door passes its group and its authorization= escalation id. Everything else in D0 is unchanged: operator approval through the approvals app, the durable claim, the frozen filing and the authority event log.

Witnesses (test.claim.spark.pair_serving_d0_witness), all PASS locally, ≤94 eval steps each:

  • Positive control: the_declared_single_lifecycle_is_admitted_while_the_drop_stands, on the real row.
  • REDs: a_second_consent_id_or_group_b_or_a_retired_drop_refuses_the_single_lifecycle. The earlier id ds41-group-a-d0-20260927 refuses; group-b refuses; a retired drop refuses. The last is over a supplied standing, d0_single_lifecycle_admits_under.
  • Unchanged: the_wet_door_refuses_while_the_fabric_storage_write_wall_drop_stands still asserts the walls' own refusal, now for a lifecycle the drop does not admit (group-b).

The earlier escalation id ds41-group-a-d0-20260927. proud-deer-538 reports that the dispatches under it refused before filing anything, so no filing exists under it. I could not confirm that with a store read from this session. srv1 refuses this session's ssh (publickey), and the store's door is a unix socket on srv1. The confirming read is gunbc.spark.pair_serving_d0 d0_read_filing for that escalation on srv1, answering D0FilingAbsent. It needs someone with srv1 access. Either way, this drop refuses that id; the RED above is exactly that case.

🤖 Generated with Claude Code

…escalation d0-group-a-ds41-2026-09-30) while the store walls are unfinished

Operator-ruled 2026-09-30 (option A, relayed by proud-deer-538).
gunbc.rung_drop.d0_store_walls_single_lifecycle declares the drop (previous
MechanicallyPreventable, temporary Mitigatable, replacement staged, one
lifecycle including its reruns, restoration: both walls live on srv1).
d0_store_write_wall_standing now takes the group and escalation id: both
walls finished admits every lifecycle; otherwise only the declared one is
admitted and everything else refuses as before. Witnesses: the declared
lifecycle is admitted on the real row; a second consent id, group-b and a
retired drop refuse; the walls' own refusal still answers for group-b.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@gunbai-bot
gunbai-bot Bot added this pull request to the merge queue Sep 30, 2026
Merged via the queue into main with commit 4decd6f Sep 30, 2026
5 checks passed
@gunbai-bot
gunbai-bot Bot deleted the lively-dove-256-d0drop branch September 30, 2026 12:33
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.

0 participants