docs(config-upgrade-snapshot): expand spec to 6 requirements/26 ACs
Adds crash-safety, determinism, host-status, and apply-activate requirements; records research on bug-1418 as a pre-work dependency (its apply-lag promotion-gate fix is the template for this spec's own Req3 graceful-degrade gate, and contaminates Req6's chaos-soak signal if left unfixed first).
This commit is contained in:
parent
bf6a9b3405
commit
8ee98beed7
4 changed files with 172 additions and 10 deletions
|
|
@ -19,4 +19,6 @@ This spec **cannot proceed without entity-bearing snapshots**. Today snapshots a
|
|||
Empirically reproduce bug-857 first (upgrade config during the chaotic-multi-kill repro and diff materialized state across nodes via `waldump`/state dump) to establish the RED, then prove every member converges to identical materialized state + active config after an upgrade interleaved with failover.
|
||||
|
||||
## Dependencies
|
||||
HARD: `entity-bearing-snapshots` (entity payload), `ha-term-safety` (the config-change marker it anchors on). Consumes the `snapshot_transfer_s` transport. Closes bug-857.
|
||||
HARD (both now satisfied — 2026-07-21): `entity-bearing-snapshots` → satisfied by `ha-entity-snapshots` (21/21 tasks). `ha-term-safety` (the config-change marker it anchors on) → `implementation-complete`, GO 2026-07-17. Consumes the `snapshot_transfer_s` transport. Closes bug-857.
|
||||
|
||||
**Prepare work (decided 2026-07-21):** fix **bug-1418** (apply-lag promotion-gate liveness deadlock, still open, no owning spec) before or alongside this spec's implementation. It reliably fires inside the same chaotic-multi-kill soak Requirement 6 needs, so left unfixed it contaminates that test's signal; its own (unimplemented) fix — become primary, self-apply, then serve, instead of hard-blocking promotion — is also the template Requirement 3's activation gate must mirror to avoid reintroducing the same liveness-deadlock shape for materialization-lag. Scope as task 0 / a small prerequisite fix, not optional cleanup.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ This feature makes a configuration upgrade establish a **full, entity-bearing st
|
|||
|
||||
## Boundary Context
|
||||
|
||||
- **In scope**: a full entity-bearing state snapshot materialized at the configuration-change marker's `(term, lsn)`; embedding the new configuration in that snapshot; installing it on every member via the out-of-band snapshot-install transport; activation gating until the snapshot is installed and hash-verified; the post-upgrade materialized-state + active-configuration consistency invariant; superseding `ha-term-safety` R7's interim config-push byte delivery for the upgrade case.
|
||||
- **In scope**: a full entity-bearing state snapshot (the upgrade snapshot) materialized at the configuration-change marker's `(term, lsn)`; embedding the new configuration in that snapshot; every member ending up holding it, via local materialization (already applied the marker) or the out-of-band snapshot-install transport (behind or freshly joining); an activation gate on the serving primary tied to its own materialization-and-hash-verification completing, not to Raft election eligibility; the post-upgrade materialized-state + active-configuration consistency invariant; superseding `ha-term-safety` R7's interim config-push byte delivery for the upgrade case.
|
||||
- **Out of scope**:
|
||||
- The configuration-change marker and consensus ordering of the change — owned by `ha-term-safety` (Requirement 7).
|
||||
- The entity-serialization machinery that produces an entity-bearing snapshot — owned by `entity-bearing-snapshots`; this spec **consumes** it.
|
||||
|
|
@ -18,6 +18,9 @@ This feature makes a configuration upgrade establish a **full, entity-bearing st
|
|||
- **Dependency on entity-bearing snapshots — SATISFIED (2026-07-09) by `ha-entity-snapshots` (21/21 tasks, fully approved).** That spec landed `write_snapshot`/`load_snapshot` (persist.c) as a direct Cap'n-Proto entity-encode/decode of job and queue records at checkpoint time, restoring before advancing position — not the COW `xzarray_freeze`/`thaw` mechanism this line originally anticipated (that machinery remains dormant; `ha-entity-snapshots` took a different, already-shipped implementation path). This spec no longer needs to wait; verify `write_snapshot`'s actual on-disk entity format (persist.c, `ha-entity-snapshots` design.md) before writing this spec's own design so it builds on the real interface, not the COW one originally assumed here.
|
||||
- Anchors on the `(term, lsn)` configuration-change marker from `ha-term-safety`.
|
||||
- Reuses the existing `snapshot_transfer_s` snapshot-install transport (chunked, `(term, lsn)`-anchored, hash-verified, install-before-activate).
|
||||
- Reuses the existing checkpoint machinery (`persist.c` `persist_checkpoint`/`write_snapshot`/`schedule_checkpoint`) as the materialization mechanism rather than a bespoke path: it already runs off the raft apply path via `delaymgr` (never blocks a vtask handler — see `ha-async-io.md`), already guards a single in-flight checkpoint with a CAS (`checkpoint_in_progress`), and already pins `checkpoint_lsn` to `last_applied_lsn`. It already caches a committed-config *reference* (`cfgref_present`/`cfgref_tag`/`cfgref_sha`, `ha-term-safety` task 4.2) in the snapshot header — this spec extends that to a full *embedded* configuration payload, it does not replace the mechanism.
|
||||
- **Gap identified 2026-07-21 — host frames are missing from the entity-bearing payload.** `write_snapshot` as shipped by `ha-entity-snapshots` calls only `collect_job_frames`/`collect_queue_frames` (persist.c) — there is no `collect_host_frames` and no host section in the on-disk format. Requirement 1.6 (host admin-status in the snapshot) needs this codec extended before it can be satisfied; this is new work, not covered by any existing spec. Design must decide whether host-frame collection/restore belongs in this spec's own tasks or is a small follow-up dependency on `ha-entity-snapshots`'s owners. `resources` (named in the Introduction alongside hosts) has the same open question and was not resolved this session — treat as still-undecided scope, not silently included or excluded.
|
||||
- **Prepare work (decided 2026-07-21, tracked in `spec.json.blocked_on`) — fix `bug-1418` before or alongside this spec's implementation.** bug-1418 is a still-open, unowned liveness deadlock: a primary whose local *apply* lags behind (but is otherwise safe, not divergent) gets hard-blocked from promotion rather than gracefully catching up, reliably by round 5 of a 10-round chaotic soak. Left unfixed it contaminates Requirement 6's own chaotic-multi-kill soak signal (can't distinguish a real regression from this known unrelated bug firing), and its unimplemented proposed fix — become primary, self-apply, then serve, instead of hard-blocking — is the exact graceful-degrade template Requirement 3's activation gate must follow for materialization-lag. Treat as task 0, not optional cleanup. See project memory `project_bug1418_prework_decision.md`.
|
||||
|
||||
## Requirements
|
||||
|
||||
|
|
@ -26,10 +29,14 @@ This feature makes a configuration upgrade establish a **full, entity-bearing st
|
|||
**Objective:** As an operator, I want a configuration upgrade to materialize a full state snapshot at the change boundary, so that every member adopts the same post-upgrade state rather than re-deriving it.
|
||||
|
||||
#### Acceptance Criteria
|
||||
1. When a configuration change commits, the Controller shall materialize a full state snapshot at the configuration-change marker's `(term, lsn)` boundary.
|
||||
2. The Controller shall install that same snapshot on every member.
|
||||
1. When a member applies a committed configuration-change marker, the Controller shall materialize a full state snapshot (the "upgrade snapshot") at that marker's `(term, lsn)` boundary — apply, not commit, since `checkpoint_lsn` is already defined as the apply cursor (`last_applied_lsn`), and apply is decoupled from and can lag commit under load (`raft-apply-decoupling`).
|
||||
2. The Controller shall ensure every member ends up holding the upgrade snapshot for the current marker — via that member's own local materialization once it has applied the marker itself, or via the out-of-band snapshot-install transport for a member that has not yet applied the marker (behind or freshly joining) — with both paths producing identical content per Requirement 5.1, never a mix of stale local state and a differently-sourced remote snapshot.
|
||||
3. The Controller shall not require any member to re-derive post-upgrade state by replaying pre-upgrade WAL entries under the new configuration.
|
||||
4. The Controller shall transfer the upgrade snapshot through the out-of-band snapshot-install path, not through WAL entry payloads.
|
||||
5. The Controller shall trigger snapshot materialization synchronously upon applying the configuration-change marker (a forced checkpoint at that exact `(term, lsn)`), executed through the existing asynchronous checkpoint mechanism rather than inline within the raft apply path, so that the trigger is immediate and deterministic while the write itself never blocks a vtask handler.
|
||||
6. The Controller shall include each host's administratively-set status (e.g., open/closed, locked, tagged) in the materialized snapshot, so that admin-set host state survives a configuration upgrade the same way admin-set queue status already does.
|
||||
7. The Controller shall exclude dynamic, non-administratively-set host metrics (e.g., load averages, real-time resource utilization samples) from the materialized snapshot, since these naturally re-populate after restart and pinning them would make the snapshot's content non-deterministic (Requirement 5.1) for no correctness benefit.
|
||||
8. Applying the configuration-change marker shall advance the Controller's apply position and trigger materialization (Requirement 1.5) but shall NOT itself change how the Controller interprets or re-homes entities (e.g., `lost_and_found` re-homing) under the new configuration — that interpretive switch is the activation step gated by Requirement 3.2, never an immediate side effect of apply. Without this separation, Requirement 3.3's "keep serving under the last-verified configuration" is incoherent: apply and activation must be distinct steps, not one.
|
||||
|
||||
### Requirement 2: Configuration embedded in the upgrade snapshot
|
||||
|
||||
|
|
@ -39,15 +46,17 @@ This feature makes a configuration upgrade establish a **full, entity-bearing st
|
|||
1. The Controller shall embed the new configuration in the upgrade snapshot so that installing the snapshot delivers configuration and materialized state as one consistent artifact.
|
||||
2. The Controller shall make this upgrade snapshot supersede the interim out-of-band config-push byte delivery (`ha-term-safety` Requirement 7) for the upgrade case.
|
||||
3. The Controller shall keep the configuration bytes out of WAL entry payloads (the WAL holds only the `(term, lsn)` configuration-change marker).
|
||||
4. The Controller shall embed the currently active configuration in every checkpoint taken after a configuration change, not only the marker-triggered upgrade checkpoint, so that a member joining or catching up after the upgrade snapshot has been rotated away still receives configuration and materialized state together from whichever checkpoint it installs.
|
||||
|
||||
### Requirement 3: Activation gating
|
||||
|
||||
**Objective:** As an operator, I want a member to serve under a new configuration only after it holds the matching materialized state, so that no member operates on mismatched configuration or state.
|
||||
**Objective:** As an operator, I want the serving primary — whichever member that is, self-promoted or freshly elected — to never serve client requests under a configuration whose materialized snapshot it has not itself completed and verified, so that Raft's log-completeness guarantee (who CAN be elected) is never mistaken for materialization-completeness (who SHOULD start serving).
|
||||
|
||||
#### Acceptance Criteria
|
||||
1. While a member has not installed the upgrade snapshot, the Controller shall not let that member serve under or activate the new configuration.
|
||||
2. When a member installs an upgrade snapshot, the Controller shall verify the embedded configuration against the configuration-change marker's content hash before activating it.
|
||||
3. If the embedded configuration does not match the marker's content hash, then the Controller shall reject the snapshot and continue retrying rather than activating mismatched configuration.
|
||||
1. The Controller shall rely on Raft's existing log-freshness election gate (a candidate's log must be at least as up-to-date as the voter's) to prevent a member missing the committed configuration-change marker from being elected; this spec introduces no separate promotion-eligibility mechanism for WAL/log completeness.
|
||||
2. Regardless of whether a member authored the configuration-change marker itself or inherited it via replication and a later election, the Controller shall not let that member serve client requests under the new configuration until its own upgrade-snapshot materialization for the current marker has durably completed and the embedded configuration has been hash-verified against the marker.
|
||||
3. While its own materialization for the current marker is incomplete, a member that is otherwise the serving primary shall continue serving under its own last-verified configuration rather than stopping service, consistent with the never-self-terminate / stay-alive invariant (`controller/CLAUDE.md`).
|
||||
4. If the embedded configuration does not hash-verify against the marker, the Controller shall keep serving under the last-verified configuration (or remain in a loud non-serving fence if none exists yet) and continue retrying materialization rather than activating mismatched configuration.
|
||||
|
||||
### Requirement 4: Post-upgrade consistency invariant
|
||||
|
||||
|
|
@ -58,10 +67,22 @@ This feature makes a configuration upgrade establish a **full, entity-bearing st
|
|||
2. When members complete a configuration upgrade, every member's active configuration shall be identical.
|
||||
3. While configuration upgrades interleave with failover, the Controller shall preserve the post-upgrade identical-state invariant across leadership changes.
|
||||
|
||||
### Requirement 5: Reproduction and regression
|
||||
### Requirement 5: Crash-safety and idempotent resumption
|
||||
|
||||
**Objective:** As an operator, I want a configuration upgrade to survive a controller crash or leadership change at any point, so that correctness after failure is never traded away for upgrade progress.
|
||||
|
||||
#### Acceptance Criteria
|
||||
1. The Controller shall make the upgrade snapshot's content a deterministic function of the configuration-change marker's `(term, lsn)` and the embedded configuration's content hash, so that independent materialization by any member — including a newly elected leader — yields identical content.
|
||||
2. If a member crashes after the configuration-change marker commits but before that member's upgrade snapshot write completes durably, then upon restart the Controller shall resume materialization from the marker rather than serving under the new configuration with an incomplete or absent snapshot.
|
||||
3. The Controller shall guard the forced upgrade checkpoint with the same single-in-flight-checkpoint idempotency mechanism used by periodic checkpoints, so that a post-crash retry or a concurrent periodic checkpoint cannot corrupt or partially overwrite the upgrade snapshot.
|
||||
4. If leadership changes after the configuration-change marker commits but before every member has installed the upgrade snapshot, then the new leader shall resume driving materialization and distribution rather than treating the upgrade as complete or abandoning it.
|
||||
5. Under no sequence of crashes, restarts, or leadership changes shall a member serve under the new configuration without having durably installed and hash-verified the matching upgrade snapshot (a failure-mode restatement of Requirement 3.2).
|
||||
|
||||
### Requirement 6: Reproduction and regression
|
||||
|
||||
**Objective:** As a maintainer, I want the bug-857 divergence reproduced and guarded, so that the fix is proven.
|
||||
|
||||
#### Acceptance Criteria
|
||||
1. When the regression scenario interleaves a configuration upgrade with chaotic multi-kill failover, the test shall assert that every member's materialized state and active configuration are identical afterwards.
|
||||
2. The test shall reproduce the bug-857 materialized-state divergence on the pre-fix code (config-push + per-node replay) and pass on the fixed code.
|
||||
3. The test shall inject a controller crash/restart and a leadership change between configuration-change marker commit and upgrade-snapshot-install completion, and assert the post-upgrade consistency invariant (Requirement 4) and the crash-safety invariant (Requirement 5.5) still hold.
|
||||
|
|
|
|||
|
|
@ -175,3 +175,140 @@ gating + hash-verify + loud-fence.
|
|||
(only one freeze/thaw consumer allowed — `zarray.c` / roadmap note).
|
||||
- Build `snapdump` + `walcompare` (roadmap Hardening §) first — they are the RED/GREEN
|
||||
assertion tools for R5 (entity-less snapshot detection + cross-node WAL/state diff).
|
||||
|
||||
---
|
||||
|
||||
## Update — 2026-07-21 (dependencies resolved; requirements extended; harness gap analysis)
|
||||
|
||||
This section is current as of 2026-07-21 and supersedes the stale parts of the
|
||||
2026-06-24 analysis above (kept for history). Do not re-derive the gating
|
||||
status or tool inventory from the sections above without reading this first.
|
||||
|
||||
### Gating blocker — RESOLVED
|
||||
|
||||
- **`entity-bearing-snapshots`** — satisfied 2026-07-09 by `ha-entity-snapshots`
|
||||
(21/21 tasks, fully approved). It shipped `write_snapshot`/`load_snapshot`
|
||||
(`persist.c`) as a direct Cap'n-Proto entity-encode/decode of job and queue
|
||||
records at checkpoint time — **not** the COW `xzarray_freeze`/`thaw` path this
|
||||
research doc's Option A/C assumed (that machinery is still dormant,
|
||||
`kvmgr.c:297`). Design must build on the real `write_snapshot`/`load_snapshot`
|
||||
interface, not the COW one.
|
||||
- **`ha-term-safety`** (owns the `(term,lsn)` config-change marker this spec
|
||||
anchors on) — `implementation-complete`, GO-validated 2026-07-17, 46/46
|
||||
acceptance criteria mapped, live chaotic soak clean.
|
||||
- Net effect: this spec is **unblocked**. `spec.json.blocked_on` should be
|
||||
cleared and the phase can move to design once requirements are approved.
|
||||
|
||||
### Tool inventory — CORRECTED (contradicts the "unbuilt" note above)
|
||||
|
||||
`snapverify`, `snapdiff`, and `walcompare`/`walcompare_report` all **already
|
||||
exist** (`src/controller/testsuite/`), built 2026-07-02 during bug-1386/1389
|
||||
triage. The line-57/176 framing above ("planned", "unbuilt", "build first") is
|
||||
stale — do not re-propose building them.
|
||||
|
||||
- `snapverify_path` — structural-only checkpoint-file validator (magic,
|
||||
format_version, frame walk to EOF). Reports `has_cfgref` as a bool but does
|
||||
**not** decode or assert the tag/hash value.
|
||||
- `snapdiff_paths` — byte-for-byte comparator between two checkpoint files,
|
||||
with chunk-boundary diagnosis. Built for source-vs-received comparison but
|
||||
directly reusable for a determinism check (two independently materialized
|
||||
snapshots at the same boundary should be byte-identical).
|
||||
- `walcompare`/`walcompare_report` — cross-member committed-prefix divergence
|
||||
detector, compares `(term, pcrc)` per LSN, and already has a **per-member
|
||||
checkpoint floor** concept (an LSN below a member's own installed-snapshot
|
||||
floor is "legitimately compacted," never flagged divergent — `ha-entity-
|
||||
snapshots` task 7.1 / `raft-ha-core-safety` task 5.10a). It does **not**
|
||||
compare active configuration across members.
|
||||
|
||||
### Requirements extended this session (2026-07-21)
|
||||
|
||||
`requirements.md` gained content not reflected in this doc's "Recommendations"
|
||||
section (items 1-5 above predate these):
|
||||
- **Req 1.5** — snapshot materialization is triggered synchronously by
|
||||
marker-apply but executed through the *existing* async checkpoint mechanism
|
||||
(`persist_checkpoint`/`schedule_checkpoint`/`write_snapshot`, delaymgr-driven,
|
||||
CAS-guarded single-in-flight), not inlined into the raft apply path — answers
|
||||
the "should this be one atomic Raft FSM operation" question: the marker
|
||||
commit already is one FSM op; materialization should be triggered by it but
|
||||
run via the existing decoupled checkpoint mechanism (never block a vtask
|
||||
handler); cross-node install must never be — it's inherently async.
|
||||
- **Req 2.4** — every checkpoint taken after a config change embeds the
|
||||
*current* config, not only the marker-triggered one, so a member joining
|
||||
after the upgrade snapshot has rotated away (`rotate_snapshots`, `snap_keep_n`)
|
||||
still gets config + state together. Piggybacks on the existing
|
||||
`scan_latest_committed_config_ref` (`persist.c:1999`), which already re-stamps
|
||||
the latest committed config *reference* into every checkpoint — Req 2 extends
|
||||
that from a reference to the full embedded bytes.
|
||||
- **Req 5 (new)** — Crash-safety and idempotent resumption: deterministic
|
||||
snapshot content (any member's independent materialization at the same
|
||||
`(term,lsn,config-hash)` is identical), crash-safe resumption if a member
|
||||
dies mid-materialization, idempotency guard reusing the existing
|
||||
`checkpoint_in_progress` CAS, and leader-change-mid-distribution resumption.
|
||||
- **Req 6.3 (was Req 5.2)** — regression test must inject a crash/restart and a
|
||||
leadership change specifically between marker-commit and snapshot-install-
|
||||
complete, not just rely on general chaotic-kill timing.
|
||||
|
||||
### Invariant risk carried forward from this session's controller-invariant check (2026-07-21)
|
||||
|
||||
Checked the new requirements (esp. Req 3's activation gate) against
|
||||
`controller/CLAUDE.md`'s TLA+ invariants and Protocol Verification Checklist.
|
||||
One real precedent-risk, already fixed at the requirements level (Req 1.8) but
|
||||
flagging for design/implementation attention:
|
||||
|
||||
- **bug-1418 (open, NOT FIXED)** is the same failure shape this spec's Req 3
|
||||
risks reintroducing in a new flavor. bug-1418: a newly-elected primary whose
|
||||
*apply* is behind (`apply_divergent=1`) hits a **liveness deadlock** — the
|
||||
existing promotion gate blocks it hard, repeatedly, rather than degrading
|
||||
gracefully; the (unimplemented) proposed fix is "become primary, self-apply,
|
||||
then serve." Req 3.2/3.3 of this spec assume exactly that graceful pattern
|
||||
for *materialization*-lag instead of *apply*-lag. Since the apply-lag version
|
||||
of this pattern is proven broken in production today, design must not
|
||||
implement Req 3's gate as a hard promotion block (Req 3.1 already commits to
|
||||
this — no separate promotion-eligibility mechanism) and must verify the
|
||||
"keep serving under last-verified config" fallback (Req 3.3) is genuinely
|
||||
implemented, not degrade into the same stall bug-1418 exhibits.
|
||||
- Root cause of the *need* for Req 1.8 (apply must not itself re-home entities;
|
||||
activation is a separate, later-gated step): without that split, Req 3.3
|
||||
("keep serving under last-verified configuration" while materialization is
|
||||
incomplete) is incoherent — there would be no old interpretation left to
|
||||
serve under once apply had already mutated live entity state. This is the
|
||||
same family of apply-ordering subtlety behind bug-1417/1418/1419.
|
||||
- **Design-verification item (unconfirmed, not yet checked in code):** does
|
||||
`persist_load_snapshot`/`load_snapshot` advance `durable_lsn` (not just
|
||||
`checkpoint_lsn`/`current_lsn`) when a member catches up via the transport-
|
||||
install path (Req 1.2's second branch)? If not, a snapshot-caught-up member
|
||||
may not correctly count toward commit majority for LSNs at/below the
|
||||
snapshot boundary even though it durably holds that state via the snapshot
|
||||
file rather than raw WAL — a possible Commit Durability invariant gap
|
||||
specific to the transport-install path. Verify in design before assuming
|
||||
Req 1.2's two paths are equally safe.
|
||||
|
||||
### Harness gaps for design phase (new, from this session's analysis)
|
||||
|
||||
Three items, only two are genuinely new build work:
|
||||
|
||||
1. **No cross-member config comparator (new gap).** `walcompare` diffs WAL only.
|
||||
Req 4.2 ("every member's active configuration identical") has no assertion
|
||||
tool. Extend `walcompare` (or add a sibling) to decode+compare the embedded
|
||||
config tag/hash (and eventually bytes) per member, mirroring how it already
|
||||
compares `(term,pcrc)`. Also extend `snapverify` to decode/assert the
|
||||
cfgref tag+hash value, not just report its presence.
|
||||
2. **No deterministic fault-injection at the marker-apply → forced-checkpoint-
|
||||
durable window (new gap, needed for Req 5.2/6.3).** `/xce-test-ha --chaotic`
|
||||
kills at random points — could hit this narrow window eventually, too flaky
|
||||
for a CI regression gate. Precedent for the right shape of hook already
|
||||
exists twice in `config_repl.c`: `ha_stream_body_read_fault_hook`,
|
||||
`xce_snapshot_chunk_hook` (both `#ifdef XCE_TESTING` seams). Add an
|
||||
equivalent hook at the marker-apply/forced-checkpoint boundary.
|
||||
3. **No deterministic leadership-change-mid-distribution injection (new gap,
|
||||
Req 5.4/6.3).** Same precedent pattern as #2 — a targeted "kill/step-down
|
||||
primary exactly after marker commits, before all standbys ACK install,"
|
||||
not reliance on chaos-soak probability.
|
||||
4. **Reusable, no new work needed:** `snapdiff_paths` for the Req 5.1
|
||||
determinism check; `/xce-test-ha --force-snapshot` for Req 2.4's
|
||||
fresh-join-after-rotation (already exercises wiped-node-rejoins-empty via
|
||||
bug-1386's own test mode — just needs its assertions extended once config
|
||||
embedding lands); `config_commit_change`/`do_upgrade_config_with_bytes`
|
||||
(bug-970) already wires `WAL_CONFIG_MARKER` into the live upgrade path, so
|
||||
the bug-857 repro (Req 6.2) is triggerable today with existing tooling —
|
||||
no blocker there.
|
||||
|
|
|
|||
|
|
@ -19,5 +19,7 @@
|
|||
}
|
||||
},
|
||||
"ready_for_implementation": false,
|
||||
"blocked_on": []
|
||||
"blocked_on": [
|
||||
"bug-1418 (apply-lag promotion-gate liveness deadlock) — decided 2026-07-21 as prepare work for this spec: fix before/alongside implementation. Contaminates this spec's own Requirement 6 chaotic-multi-kill soak signal, and its graceful-degrade fix pattern is the template Requirement 3's activation gate must mirror. No spec currently owns it — scope as task 0 / a small prerequisite fix. See project memory project_bug1418_prework_decision.md."
|
||||
]
|
||||
}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue