mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-09-20 13:30:46 +02:00
docs: add bounded productionization pilot artifacts
Freeze the first bounded pilot/preflight/stop/rollout-review artifact set and sync the global product ledgers so productionization can start from an explicit chosen-envelope discipline instead of ad hoc rollout judgment. Made-with: Cursor
This commit is contained in:
pingqiu
@@ -0,0 +1,138 @@
|
||||
# V2 Bounded Internal Pilot Pack
|
||||
|
||||
Date: 2026-04-05
|
||||
Status: draft
|
||||
Purpose: convert the frozen first-launch envelope into one bounded internal pilot
|
||||
package without silently broadening scope
|
||||
|
||||
## Reading Rule
|
||||
|
||||
This pilot pack is a bounded validation package for the already-frozen chosen path.
|
||||
|
||||
It does NOT mean:
|
||||
|
||||
1. broad launch approval
|
||||
2. generic production readiness
|
||||
3. support for surfaces outside the named first-launch matrix
|
||||
4. permission to redefine exclusions through pilot success
|
||||
|
||||
It means only:
|
||||
|
||||
1. the team may run a limited internal pilot inside the accepted chosen envelope
|
||||
2. pilot outcomes must be read against the existing `Phase 12-17` claim boundary
|
||||
3. incidents must be routed explicitly instead of becoming vague rollout lore
|
||||
|
||||
## Pilot Scope
|
||||
|
||||
The pilot is limited to the current first-launch support envelope:
|
||||
|
||||
1. replication / durability:
|
||||
- `RF=2`
|
||||
- `sync_all`
|
||||
2. control/runtime path:
|
||||
- existing master / volume-server heartbeat path
|
||||
- bounded `Phase 16` runtime checkpoint
|
||||
- bounded `Phase 17B/17C` contract/policy interpretation
|
||||
3. backend/runtime implementation:
|
||||
- `blockvol` through `v2bridge`
|
||||
- explicit `V2 core` as semantic owner
|
||||
4. product surfaces:
|
||||
- bounded `iSCSI`
|
||||
- bounded `CSI`
|
||||
- bounded `NVMe`
|
||||
|
||||
Anything outside that scope is not a pilot finding for this pack.
|
||||
It is either a known exclusion or later widening work.
|
||||
|
||||
## Pilot Environment And Topology
|
||||
|
||||
The pilot environment must stay fixed and reviewable:
|
||||
|
||||
1. use one explicit build/commit package for all pilot nodes
|
||||
2. keep topology inside the bounded chosen path and do not introduce `RF>2`
|
||||
3. keep transport/frontend choices inside the named supported matrix
|
||||
4. pin operator-facing configuration and startup procedure in a written runbook
|
||||
5. expose the existing diagnosis surfaces needed to read:
|
||||
- registry truth
|
||||
- publication/lookup truth
|
||||
- restart/failover state
|
||||
- inventory authority state
|
||||
|
||||
If the pilot needs ad hoc operator judgment to stay healthy, the pack is not ready.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
The pilot is considered successful only if ALL of the following hold:
|
||||
|
||||
1. no observed behavior contradicts the bounded `17B` failover/publication contract
|
||||
2. no observed behavior contradicts the bounded `17C` disturbance policy table
|
||||
3. `Phase 12 P4` floor-gate expectations stay non-regressed on the mapped chosen
|
||||
path workloads
|
||||
4. incidents can be classified using the explicit buckets in this pack without
|
||||
inventing new ambiguous categories
|
||||
5. operators can execute preflight, pilot operation, and bounded diagnosis from
|
||||
written artifacts rather than tribal knowledge
|
||||
6. pilot findings do not require silently widening the supported matrix
|
||||
|
||||
Pilot success validates the current bounded envelope only.
|
||||
It does not create a broader product claim by itself.
|
||||
|
||||
## Incident Intake And Classification
|
||||
|
||||
Every pilot incident must record:
|
||||
|
||||
1. time, node set, workload, and surface involved
|
||||
2. observed symptom
|
||||
3. affected bounded claim, exclusion, or blocker
|
||||
4. diagnosis evidence used
|
||||
5. immediate operator action taken
|
||||
6. final classification
|
||||
|
||||
Allowed classification buckets:
|
||||
|
||||
1. `config / environment issue`
|
||||
- the product behaved inside the bounded claim, but the deployment violated the
|
||||
pilot preflight or environment assumptions
|
||||
2. `known exclusion`
|
||||
- the incident came from a surface or claim already excluded from the first
|
||||
launch matrix
|
||||
3. `true product bug`
|
||||
- the incident contradicts an accepted bounded claim or reveals a real gap
|
||||
inside the named chosen envelope
|
||||
|
||||
If an incident does not fit one of those buckets, stop the pilot and refine the
|
||||
artifact set before continuing.
|
||||
|
||||
## Decision Outputs
|
||||
|
||||
At the end of a bounded pilot window, the allowed outcomes are:
|
||||
|
||||
1. `stay in pilot`
|
||||
- more evidence is needed inside the same envelope
|
||||
2. `widen within the same envelope`
|
||||
- the rollout review may expand exposure, but only without changing the named
|
||||
supported matrix
|
||||
3. `block expansion`
|
||||
- a contradiction, repeated unresolved bug, or operational ambiguity prevents
|
||||
widening
|
||||
|
||||
These outcomes require a later controlled-rollout review artifact.
|
||||
This pilot pack does not replace that review.
|
||||
|
||||
## Explicit Non-Claims
|
||||
|
||||
This pack does NOT claim:
|
||||
|
||||
1. generic production proof from limited pilot success
|
||||
2. support for `RF>2`
|
||||
3. support for a broad transport/frontend matrix
|
||||
4. broad failover-under-load guarantees
|
||||
5. hours/days soak proof outside the bounded chosen-path reading
|
||||
|
||||
## Primary Inputs
|
||||
|
||||
1. `sw-block/design/v2-first-launch-supported-matrix.md`
|
||||
2. `sw-block/.private/phase/phase-17.md`
|
||||
3. `sw-block/.private/phase/phase-17-checkpoint-review.md`
|
||||
4. `sw-block/.private/phase/phase-12-p4-rollout-gates.md`
|
||||
5. `sw-block/design/v2-product-completion-overview.md`
|
||||
@@ -0,0 +1,143 @@
|
||||
# V2 Controlled Rollout Review
|
||||
|
||||
Date: 2026-04-05
|
||||
Status: draft
|
||||
Purpose: define the bounded review used to decide whether the internal pilot stays
|
||||
limited, widens within the same first-launch envelope, or blocks expansion
|
||||
|
||||
## Reading Rule
|
||||
|
||||
This artifact is a bounded decision gate after pilot execution.
|
||||
|
||||
It does NOT mean:
|
||||
|
||||
1. broad launch approval
|
||||
2. generic production readiness
|
||||
3. permission to widen beyond the frozen first-launch matrix
|
||||
4. permission to reinterpret pilot survival as new protocol/runtime proof
|
||||
|
||||
It means only:
|
||||
|
||||
1. pilot outcomes may be reviewed against the already-accepted bounded envelope
|
||||
2. expansion decisions must stay inside the same named support boundary
|
||||
3. any broader claim still needs explicit new evidence and explicit new review
|
||||
|
||||
## Allowed Decisions
|
||||
|
||||
The rollout review may produce only one of these outputs:
|
||||
|
||||
1. `stay in pilot`
|
||||
- the chosen envelope is still the right boundary, but more bounded pilot
|
||||
evidence is needed before any exposure increase
|
||||
2. `widen within the same envelope`
|
||||
- exposure may increase only inside the current supported matrix, with no
|
||||
change to topology, durability, control/runtime path, or supported surfaces
|
||||
3. `block expansion`
|
||||
- the current evidence, incident record, or operational ambiguity is not strong
|
||||
enough to increase exposure safely
|
||||
|
||||
Any outcome outside those three is invalid for this review.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
The review must not start unless these inputs exist and are explicit:
|
||||
|
||||
1. the frozen first-launch matrix
|
||||
2. the bounded pilot pack
|
||||
3. the preflight checklist outcome(s)
|
||||
4. the pilot stop-condition artifact
|
||||
5. pilot incident records with explicit classification
|
||||
6. pilot outcome summary for the bounded chosen path
|
||||
7. the accepted evidence anchors that define the current boundary:
|
||||
- `Phase 12 P4`
|
||||
- `CP13-1..9`
|
||||
- `Phase 16` finish-line checkpoint
|
||||
- `Phase 17A-17D`
|
||||
|
||||
If any required input is missing, the correct review output is `block expansion`.
|
||||
|
||||
## Decision Questions
|
||||
|
||||
The rollout review must answer all of the following:
|
||||
|
||||
1. did the pilot remain fully inside the frozen first-launch envelope
|
||||
2. did any observed behavior contradict the bounded `17B` failover/publication
|
||||
contract
|
||||
3. did any observed behavior contradict the bounded `17C` disturbance policy table
|
||||
4. were any stop conditions triggered, and if so, how were they resolved
|
||||
5. are all incidents classified cleanly as:
|
||||
- `config / environment issue`
|
||||
- `known exclusion`
|
||||
- `true product bug`
|
||||
6. does any proposed next step depend on a broader claim than the current matrix
|
||||
7. can operators run the pilot and diagnose bounded failures from written
|
||||
artifacts rather than tribal knowledge
|
||||
|
||||
If the answer to question 6 is yes, the review must not approve widening inside
|
||||
this artifact. That request belongs to later evidence expansion work.
|
||||
|
||||
## Decision Rules
|
||||
|
||||
Use these bounded rules:
|
||||
|
||||
1. approve `stay in pilot` when:
|
||||
- the pilot stayed inside scope
|
||||
- no contradiction to accepted bounded claims was found
|
||||
- more same-envelope evidence is still needed
|
||||
2. approve `widen within the same envelope` only when:
|
||||
- the pilot stayed inside scope
|
||||
- no unresolved `true product bug` remains against the bounded envelope
|
||||
- stop conditions did not reveal structural ambiguity
|
||||
- operator workflow is explicit and repeatable from the artifact set
|
||||
- the widened exposure does not change the supported matrix
|
||||
3. approve `block expansion` when:
|
||||
- any unresolved contradiction exists
|
||||
- any unresolved `true product bug` exists
|
||||
- incident records are vague
|
||||
- operators depend on tribal knowledge
|
||||
- the requested widening outruns the current matrix
|
||||
|
||||
## Explicit Review Record
|
||||
|
||||
Each review result must record:
|
||||
|
||||
1. decision outcome
|
||||
2. date and reviewer set
|
||||
3. pilot window / environment covered
|
||||
4. summary of incidents by classification bucket
|
||||
5. any stop-condition events and their disposition
|
||||
6. exact reason the decision stays inside the current matrix
|
||||
7. explicit next action:
|
||||
- continue bounded pilot
|
||||
- widen exposure inside the same envelope
|
||||
- pause and fix
|
||||
|
||||
## Rejection Rules
|
||||
|
||||
Reject the review as invalid if:
|
||||
|
||||
1. it uses pilot success as generic production proof
|
||||
2. it broadens topology, durability mode, or supported surfaces without a new
|
||||
evidence package
|
||||
3. it treats a known exclusion as if the pilot cleared it
|
||||
4. it ignores stop-condition events or unresolved true product bugs
|
||||
5. it cannot map the decision back to the accepted evidence ladder
|
||||
|
||||
## Explicit Non-Claims
|
||||
|
||||
This artifact does NOT claim:
|
||||
|
||||
1. broad rollout approval
|
||||
2. generic production readiness
|
||||
3. support for `RF>2`
|
||||
4. support for a broad transport/frontend matrix
|
||||
5. broad failover-under-load or long-window soak proof
|
||||
|
||||
## Primary Inputs
|
||||
|
||||
1. `sw-block/design/v2-first-launch-supported-matrix.md`
|
||||
2. `sw-block/design/v2-bounded-internal-pilot-pack.md`
|
||||
3. `sw-block/design/v2-pilot-preflight-checklist.md`
|
||||
4. `sw-block/design/v2-pilot-stop-conditions.md`
|
||||
5. `sw-block/design/v2-phase-development-plan.md`
|
||||
6. `sw-block/.private/phase/phase-17.md`
|
||||
@@ -70,14 +70,25 @@ These are still required before this matrix can be read as a real launch
|
||||
decision package:
|
||||
|
||||
1. a frozen `Phase 17` checkpoint review outcome
|
||||
2. a pilot pack with:
|
||||
- preflight checklist
|
||||
- success criteria
|
||||
- stop / rollback conditions
|
||||
3. controlled-rollout review artifacts
|
||||
4. any additional evidence needed if the product wants claims broader than the
|
||||
2. any additional evidence needed if the product wants claims broader than the
|
||||
current bounded `17B/17C` contract/policy package
|
||||
|
||||
## Current Productionization Artifacts
|
||||
|
||||
The first bounded productionization artifacts now exist for the chosen path:
|
||||
|
||||
1. `v2-bounded-internal-pilot-pack.md`
|
||||
- bounded pilot scope
|
||||
- success criteria
|
||||
- incident classification
|
||||
2. `v2-pilot-preflight-checklist.md`
|
||||
- start/resume gate for the bounded pilot
|
||||
3. `v2-pilot-stop-conditions.md`
|
||||
- stop/contain/rollback-exposure rules
|
||||
4. `v2-controlled-rollout-review.md`
|
||||
- bounded post-pilot decision gate
|
||||
- allowed outcomes: stay in pilot / widen within same envelope / block expansion
|
||||
|
||||
## Not Launch-Blocking In This Draft
|
||||
|
||||
These are intentionally NOT blockers for the bounded first-draft envelope:
|
||||
@@ -121,3 +132,7 @@ When using this matrix, read it with these constraints:
|
||||
2. `sw-block/.private/phase/phase-17-checkpoint-review.md`
|
||||
3. `sw-block/design/v2-product-completion-overview.md`
|
||||
4. `sw-block/design/v2-protocol-claim-and-evidence.md`
|
||||
5. `sw-block/design/v2-bounded-internal-pilot-pack.md`
|
||||
6. `sw-block/design/v2-pilot-preflight-checklist.md`
|
||||
7. `sw-block/design/v2-pilot-stop-conditions.md`
|
||||
8. `sw-block/design/v2-controlled-rollout-review.md`
|
||||
|
||||
@@ -0,0 +1,109 @@
|
||||
# V2 Pilot Preflight Checklist
|
||||
|
||||
Date: 2026-04-05
|
||||
Status: draft
|
||||
Purpose: define the minimum explicit checks required before running the bounded
|
||||
internal pilot
|
||||
|
||||
## Reading Rule
|
||||
|
||||
This checklist is a gate for starting or resuming the bounded pilot.
|
||||
|
||||
If any item below is not satisfied:
|
||||
|
||||
1. do not treat the environment as pilot-ready
|
||||
2. either fix the issue or classify it explicitly before proceeding
|
||||
|
||||
## Scope Lock
|
||||
|
||||
Confirm the pilot is still inside the frozen first-launch envelope:
|
||||
|
||||
1. topology remains `RF=2`
|
||||
2. durability mode remains `sync_all`
|
||||
3. control/runtime path remains the existing master / volume-server heartbeat path
|
||||
4. execution backend remains `blockvol` through `v2bridge`
|
||||
5. product surface remains within bounded `iSCSI`, bounded `CSI`, or bounded
|
||||
`NVMe`
|
||||
6. no one is trying to use pilot success to claim broader launch approval
|
||||
|
||||
## Build And Artifact Pin
|
||||
|
||||
Confirm the software package is explicit and stable:
|
||||
|
||||
1. the exact build/commit for pilot nodes is written down
|
||||
2. all pilot nodes run the same intended package
|
||||
3. the operator runbook matches the package actually deployed
|
||||
4. any configuration delta from the documented chosen path is reviewed and
|
||||
accepted explicitly
|
||||
|
||||
## Environment Readiness
|
||||
|
||||
Confirm the pilot environment matches bounded assumptions:
|
||||
|
||||
1. node inventory and topology are written down
|
||||
2. transport/frontend choice is inside the supported matrix
|
||||
3. storage/network assumptions required by the chosen path are known to the
|
||||
operator
|
||||
4. known exclusions are acknowledged before start
|
||||
5. rollback/containment ownership is assigned for the pilot window
|
||||
|
||||
## Diagnosis Surface Readiness
|
||||
|
||||
Confirm bounded diagnosis can be performed without ad hoc spelunking:
|
||||
|
||||
1. registry truth can be inspected
|
||||
2. publication/lookup truth can be inspected
|
||||
3. restart/failover progression can be inspected
|
||||
4. inventory-authority state can be inspected
|
||||
5. the operator knows which artifact defines the current contract/policy boundary:
|
||||
- `v2-first-launch-supported-matrix.md`
|
||||
- `phase-17.md`
|
||||
- this preflight checklist
|
||||
- the stop-condition artifact
|
||||
|
||||
## Workload And Gate Alignment
|
||||
|
||||
Confirm the pilot workload is aligned with accepted evidence:
|
||||
|
||||
1. the workload maps to the bounded chosen-path reading rather than a new
|
||||
unsupported scenario
|
||||
2. success will be judged against the pilot pack criteria rather than generic
|
||||
"looks stable" judgment
|
||||
3. `Phase 12 P4` floor-gate expectations are known for the workload being run
|
||||
4. no required proof depends on failover-under-load, hours/days soak, `RF>2`, or
|
||||
broad transport claims that are still excluded
|
||||
|
||||
## Incident Routing Readiness
|
||||
|
||||
Confirm incident handling is explicit before starting:
|
||||
|
||||
1. every incident will be classified as one of:
|
||||
- `config / environment issue`
|
||||
- `known exclusion`
|
||||
- `true product bug`
|
||||
2. the recording location for pilot incidents is agreed before the pilot starts
|
||||
3. ownership for triage and decision-making is assigned
|
||||
4. operators know when they must stop instead of improvising
|
||||
|
||||
## Preflight Result
|
||||
|
||||
The pilot may start only if:
|
||||
|
||||
1. every scope-lock item is true
|
||||
2. the software package and environment are pinned
|
||||
3. diagnosis surfaces are available
|
||||
4. incident routing is explicit
|
||||
5. no remaining gap is being hand-waved as "we will figure it out during pilot"
|
||||
|
||||
If those conditions are not met, the correct output is:
|
||||
|
||||
1. `NOT READY`
|
||||
2. the missing item(s)
|
||||
3. the owner/action needed before retry
|
||||
|
||||
## Primary Inputs
|
||||
|
||||
1. `sw-block/design/v2-bounded-internal-pilot-pack.md`
|
||||
2. `sw-block/design/v2-first-launch-supported-matrix.md`
|
||||
3. `sw-block/.private/phase/phase-17.md`
|
||||
4. `sw-block/.private/phase/phase-12-p4-rollout-gates.md`
|
||||
@@ -0,0 +1,103 @@
|
||||
# V2 Pilot Stop Conditions
|
||||
|
||||
Date: 2026-04-05
|
||||
Status: draft
|
||||
Purpose: define when the bounded internal pilot must stop, contain scope, or roll
|
||||
back exposure
|
||||
|
||||
## Reading Rule
|
||||
|
||||
This artifact is about pilot containment, not protocol/data rollback semantics.
|
||||
|
||||
`Rollback` here means:
|
||||
|
||||
1. stop widening pilot exposure
|
||||
2. reduce or remove pilot usage if needed
|
||||
3. return to a previously accepted bounded state of operation
|
||||
|
||||
It does NOT mean:
|
||||
|
||||
1. a general storage/data rollback guarantee
|
||||
2. permission to claim a broader recovery contract than the current evidence
|
||||
3. ad hoc operator improvisation under ambiguity
|
||||
|
||||
## Immediate Stop Conditions
|
||||
|
||||
Stop the pilot immediately if ANY of the following occurs:
|
||||
|
||||
1. an observed behavior contradicts the bounded `17B` failover/publication
|
||||
contract
|
||||
2. an observed behavior contradicts the bounded `17C` disturbance policy table
|
||||
3. publication/lookup truth and registry truth diverge outside the currently
|
||||
allowed bounded interpretation window
|
||||
4. diagnosis surfaces are insufficient to classify the incident without guessing
|
||||
5. a `Phase 12 P4` floor-gate expectation is materially violated on the mapped
|
||||
chosen-path workload
|
||||
6. the deployment is being widened beyond the named supported matrix without an
|
||||
explicit review decision
|
||||
7. the incident does not fit the allowed buckets:
|
||||
- `config / environment issue`
|
||||
- `known exclusion`
|
||||
- `true product bug`
|
||||
|
||||
## Stop-And-Contain Actions
|
||||
|
||||
When a stop condition fires:
|
||||
|
||||
1. freeze new pilot expansion immediately
|
||||
2. preserve the evidence needed for later review
|
||||
3. classify the incident explicitly
|
||||
4. map the incident back to:
|
||||
- accepted bounded claim
|
||||
- known exclusion
|
||||
- unresolved blocker
|
||||
5. decide whether the pilot can continue in reduced scope or must fully pause
|
||||
|
||||
If the team cannot perform those actions clearly, the pilot remains stopped.
|
||||
|
||||
## Rollback Decision Rules
|
||||
|
||||
Use the following bounded rules:
|
||||
|
||||
1. `config / environment issue`
|
||||
- fix the environment/configuration
|
||||
- rerun preflight before resuming
|
||||
2. `known exclusion`
|
||||
- remove the excluded usage from the pilot
|
||||
- do not reinterpret it as product support
|
||||
3. `true product bug`
|
||||
- pause affected pilot scope
|
||||
- open an explicit fix or contradiction item before resuming
|
||||
|
||||
If repeated incidents of the same class continue without a bounded corrective path,
|
||||
block further pilot expansion.
|
||||
|
||||
## Expansion Blockers
|
||||
|
||||
Even if the pilot remains partially runnable, do NOT widen it when:
|
||||
|
||||
1. the same unresolved true product bug recurs
|
||||
2. operators depend on tribal knowledge to recover or diagnose
|
||||
3. incident records are vague or cannot be mapped back to the current evidence
|
||||
ladder
|
||||
4. success depends on ignoring explicit exclusions
|
||||
5. the desired next step requires broader launch claims than the current matrix
|
||||
|
||||
## Explicit Non-Claims
|
||||
|
||||
This artifact does NOT claim:
|
||||
|
||||
1. broad rollout approval
|
||||
2. generic production readiness from pilot survival
|
||||
3. support for `RF>2`
|
||||
4. support for a broad transport/frontend matrix
|
||||
5. failover-under-load proof or long-window soak proof beyond the current bounded
|
||||
evidence set
|
||||
|
||||
## Primary Inputs
|
||||
|
||||
1. `sw-block/design/v2-bounded-internal-pilot-pack.md`
|
||||
2. `sw-block/design/v2-pilot-preflight-checklist.md`
|
||||
3. `sw-block/design/v2-first-launch-supported-matrix.md`
|
||||
4. `sw-block/.private/phase/phase-17.md`
|
||||
5. `sw-block/.private/phase/phase-12-p4-rollout-gates.md`
|
||||
@@ -1,6 +1,6 @@
|
||||
# V2 Product Completion Overview
|
||||
|
||||
Date: 2026-04-04
|
||||
Date: 2026-04-05
|
||||
Status: active
|
||||
Purpose: provide one product-level overview of current V2 engineering completion, V1 reuse strategy, and the roadmap from the accepted candidate path to a production-ready block engine
|
||||
|
||||
@@ -48,6 +48,8 @@ It already has:
|
||||
5. an accepted `Phase 16` finish-line runtime checkpoint
|
||||
6. an active `Phase 17` product-claim package that now makes broader branch,
|
||||
contract, policy, and launch-envelope boundaries explicit
|
||||
7. a first bounded productionization artifact set for pilot / preflight /
|
||||
stop-condition / rollout-review discipline
|
||||
|
||||
The most important current distinction is:
|
||||
|
||||
@@ -165,9 +167,9 @@ working path". They are closure and launch-envelope gaps:
|
||||
3. restart / disturbance preservation outside the current `17C` policy table
|
||||
- current long-window behavior is now policy-shaped, but not yet a broad
|
||||
production hardening statement
|
||||
4. pilot / rollout package
|
||||
- the first launch envelope is now drafted, but pilot pack, preflight, stop
|
||||
conditions, and rollout review artifacts are still missing
|
||||
4. pilot execution and review outcome
|
||||
- the bounded productionization artifacts now exist, but no bounded pilot run,
|
||||
incident ledger, or rollout decision outcome has been accepted yet
|
||||
5. long-run / soak / performance extension beyond the bounded floor
|
||||
- `Phase 12 P4` remains the bounded floor; broader confidence still belongs to
|
||||
later productionization
|
||||
@@ -183,7 +185,8 @@ Target:
|
||||
|
||||
Status:
|
||||
|
||||
1. in progress
|
||||
1. checkpoint package drafted
|
||||
2. review outcome still pending
|
||||
|
||||
Main output:
|
||||
|
||||
@@ -211,13 +214,15 @@ Status:
|
||||
|
||||
1. first draft frozen inside `Phase 17`
|
||||
2. not yet accepted as a launch decision package
|
||||
3. bounded productionization artifacts now exist for pilot discipline, but do not
|
||||
by themselves imply launch approval
|
||||
|
||||
Main work:
|
||||
|
||||
1. accept or refine the bounded supported matrix
|
||||
2. accept or refine explicit exclusions outside the first launch claim
|
||||
3. bind product-facing surfaces to the named supported envelope
|
||||
4. define preflight, success, and stop conditions
|
||||
4. keep pilot/preflight/stop/rollout artifacts aligned to the same frozen matrix
|
||||
|
||||
### Stage 3: Internal pilot and incident-driven hardening
|
||||
|
||||
@@ -227,13 +232,17 @@ Target:
|
||||
|
||||
Main work:
|
||||
|
||||
1. run a limited internal pilot package
|
||||
1. run a limited internal pilot package using the existing bounded artifact set
|
||||
2. route incidents with explicit classification:
|
||||
- config / environment issue
|
||||
- known exclusion
|
||||
- true product bug
|
||||
3. harden only within the named supported envelope
|
||||
4. perform controlled rollout review only within the named supported envelope
|
||||
5. record one explicit decision outcome:
|
||||
- stay in pilot
|
||||
- widen within the same envelope
|
||||
- block expansion
|
||||
|
||||
Rules:
|
||||
|
||||
@@ -294,7 +303,8 @@ It is:
|
||||
|
||||
1. finish review/freeze of the bounded `Phase 17` branch/contract/policy/envelope
|
||||
package
|
||||
2. run a limited internal pilot with explicit stop conditions
|
||||
2. execute the bounded internal pilot using the explicit preflight/stop/rollout
|
||||
artifacts
|
||||
3. harden from incidents without silently broadening scope
|
||||
4. only broaden claims when new evidence supports them
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# V2 Protocol Claim And Evidence
|
||||
|
||||
Date: 2026-04-03
|
||||
Date: 2026-04-05
|
||||
Status: active
|
||||
Purpose: keep one centralized ledger for the current chosen envelope, accepted claims, supporting evidence, invalidated evidence, and rerun obligations
|
||||
|
||||
@@ -111,6 +111,7 @@ These are the claims that may currently be made without overreach.
|
||||
| `C-PHASE16-RUNTIME-CHECKPOINT` | the bounded heartbeat/master/API runtime path now preserves accepted explicit truth across the delivered `16M-16W` restart/disturbance seams | bounded chosen path only; excludes broad recovery-loop, broad failover/publication, and launch claims | `sw-block/.private/phase/phase-16-finish-review.md`, `phase-16.md`, focused `weed/server` tests | allowed |
|
||||
| `C-PHASE17-PRODUCT-CHECKPOINT` | the current broader recovery-branch map, bounded failover/publication contract, bounded disturbance policy table, and first-launch envelope draft are explicit for the chosen path | bounded chosen path only; excludes broad production readiness, broad transport/frontend approval, and broad whole-surface failover/publication proof | `sw-block/.private/phase/phase-17.md`, `sw-block/.private/phase/phase-17-checkpoint-review.md` | allowed |
|
||||
| `C-FIRST-LAUNCH-ENVELOPE-DRAFT` | one bounded first-launch supported matrix is frozen as a draft with explicit exclusions and launch blockers | bounded chosen path only; not a launch decision, pilot approval, or rollout approval | `sw-block/design/v2-first-launch-supported-matrix.md` | allowed |
|
||||
| `C-PRODUCTIONIZATION-ARTIFACT-SET` | one bounded productionization artifact set now exists for internal pilot, preflight, stop-condition, and controlled-rollout discipline inside the frozen chosen envelope | bounded chosen path only; artifact existence only, not pilot success, rollout approval, or broader launch proof | `sw-block/design/v2-bounded-internal-pilot-pack.md`, `v2-pilot-preflight-checklist.md`, `v2-pilot-stop-conditions.md`, `v2-controlled-rollout-review.md` | allowed |
|
||||
| `C-LAUNCH-APPROVAL` | broad product launch readiness | outside current phase | future | not allowed |
|
||||
|
||||
## Evidence Map
|
||||
@@ -131,6 +132,7 @@ These are the claims that may currently be made without overreach.
|
||||
| Failover/publication bounded contract | one bounded whole-chain statement is explicit for publication ownership/address coherence after failover completion and winning assignment delivery | `phase-17.md`, `phase-17-checkpoint-review.md`, publication/disturbance tests in `weed/server` | `v2-first-launch-supported-matrix.md` |
|
||||
| Disturbance policy table | startup/restart/rejoin/repeated-failover/degraded-sparsity behavior is explicit as runtime rule, temporary inconsistency policy, or non-claim | `phase-17.md`, `phase-17-checkpoint-review.md`, restart/disturbance tests in `weed/server` | `v2-product-completion-overview.md` |
|
||||
| First-launch supported matrix | one bounded launch envelope draft is explicit with supported scope, exclusions, and launch blockers | `v2-first-launch-supported-matrix.md` | `phase-17-checkpoint-review.md`, `Phase 12 P4`, `CP13`, `Phase 16` |
|
||||
| Productionization artifact set | one bounded artifact set defines pilot scope, preflight gate, stop/contain rules, and post-pilot rollout review discipline | `v2-bounded-internal-pilot-pack.md`, `v2-pilot-preflight-checklist.md`, `v2-pilot-stop-conditions.md`, `v2-controlled-rollout-review.md` | `v2-first-launch-supported-matrix.md`, `v2-product-completion-overview.md` |
|
||||
|
||||
## Invalidated Or Narrowed Evidence
|
||||
|
||||
|
||||
Reference in New Issue
Block a user