docs(change): propose CR-DD-012B shared preview/execution consumption - #135
Merged
Merged
Conversation
Documentation-only proposal. Grants no implementation authority, no file allowlist, and no execution authority. CR-DD-012A (PR #107, bccaaad) and CR-YK-002 (PR #117, 5155bbb) are both merged, so CR-DD-012B's sequencing prerequisites are satisfied. Satisfying a prerequisite is not approval; the slice remains blocked on its own explicit human implementation approval and bounded allowlist. The proposal settles the ten questions the parent CR deferred: one snapshot/decision construction seam placed before the tc_run planning branch so context sources are read exactly once; projection rather than recomputation in the plan path, with governed_run_plan.v1 unchanged; a RuntimeObservation that subsumes CR-DD-013 capability evidence as provenance without re-deriving it; backend binding as a filter over a closed ordered envelope rather than an injection surface; bounded decision_id linkage through the existing open route/worker payload extension point, leaving route-worker-ledger.v1 untouched; an optional run_task parameter so direct callers keep current behavior; a fail-closed matrix in which termination is never repair and staleness is binding-defined rather than clock-defined; a provisional allowlist and focused parity, no-rebuild, mutation, runtime-separation, TOCTOU, privacy, and regression tests; explicit exclusions; and a stop point. Three questions are recorded as genuinely open rather than deferred. The load-bearing one: CR-DD-013 capability evidence currently feeds the route input booleans that choose_resilience_route reads, so it participates in route policy, which cannot coexist unchanged with the parent's invariant that decision identity is stable across runtime-health changes. Two resolutions are named with their consequences; the proposal recommends constraining binding rather than policy, and says plainly that this is a behavioral change requiring approval on its own terms. The proposal also records that tests/test_governed_decision_integration_ absence.py will fail by design once the slice integrates the foundation, so retiring that guard is a reviewable decision rather than a silent side effect of implementation. Scope: four documentation paths. No change log, code, tests, workflow, schema, CLI, ledger, renderer, router, worker, backend, or artifact contract change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
✅ Deploy Preview for poetic-quokka-0fd859 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Documentation-only. Still grants no implementation authority. Resolves the three questions the first draft left open, by recorded supervisor decision: 1. Capability volatility - binding only. Capability resolution constrains execution binding, never governed-decision formation. Stable inputs produce the decision, route intent, envelope, and decision ID; volatile observations may only execute, bind an already-authorized fallback, or fail closed. Capability answers "can the already-authorized plan execute right now?" and never "what policy or route should this task receive?" Otherwise identical inputs yield different decision IDs because a model server briefly disappeared, turning operational weather into policy input and weakening replay, comparison, audit, and caching. The behavioral cost is recorded plainly as a deliberate correction to CR-DD-013 semantics: a run with unknown local capability will produce a decision naming local routes and fail at binding, where today it resolves to no local route earlier. Nothing reopens CR-DD-013, whose authority stays spent; the change is to the consumer. 2. Classifier - the deterministic classifier is authoritative for decision-relevant fields. A model-assisted classifier may remain advisory and may become decision-bearing only through a separate CR that promotes its normalized output to an explicit stable input. 3. build_run_plan signature - preserved only if it remains one coherent projection. A narrow break is safer than an attractive second integration path. Adds a runtime outcome model naming the three permitted outcomes and the forbidden fourth: runtime capability inventing a route the decision never authorized. Adds five implementation approval gates, including that the CR-DD-012A integration-absence guard may be retired only in the same change that adds positive tests proving one snapshot, one decision, and two projections, plus negative tests that post-decision capability change cannot alter the decision ID, route policy, or envelope, and that unavailable capability yields only an authorized fallback or a closed failure. Scope: the same four documentation paths. No change log, code, tests, workflow, schema, CLI, ledger, renderer, router, worker, backend, or artifact contract change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Documentation-only. Still grants no implementation authority. The gates section contradicted itself: it claimed all five gates must be satisfied before implementation authority and that none were satisfied, then immediately marked gates 1-2 satisfied. Gates 3-5 assert properties of code that does not exist yet, so they cannot be satisfied before the authority to write that code is granted. The architecture spec repeated the same timing error. Both locations now record a two-stage model: - Permission to implement: a bounded approval with an explicit file allowlist and mandatory test obligations. Gates 1-2 (the recorded capability-volatility decision and the pre-`planning` seam statement) must already be satisfied, and they are. Gates 3-5 must be bound by that approval. - Permission to accept: acceptance, merge, and closeout of the implementation, granted only after gates 3-5 actually pass. An approval granting permission to implement without binding gates 3-5 is incomplete, and an implementation reaching acceptance, merge, or closeout without them passing must be rejected. The gate list is split into proposal-stage preconditions and implementation obligations so the two cannot be read as one bundle. Satisfying gates 1-2 still grants nothing: implementation authority remains a separate explicit approval with its own bounded allowlist. The parent CR status and both backlog entries are aligned to the same two-stage wording. Scope: the same four documentation paths. No change log, code, tests, workflow, schema, CLI, ledger, renderer, router, worker, backend, or artifact contract change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documentation-only proposal for CR-DD-012B. Grants no implementation
authority, no file allowlist, and no execution authority.
Scope — four documentation paths
docs/change/requests/CR-DD-012B-shared-preview-execution-consumption.md(new)docs/change/requests/CR-DD-012-shared-governed-run-decision.mddocs/current_backlog.mddocs/architecture/daily_driver_orchestrator_spec.mdNo change log, code, tests, workflow, schema, CLI, ledger, renderer, router,
worker, backend, or existing artifact contract change.
Gate status
CR-DD-012A is merged (PR #107,
bccaaad) and CR-YK-002 is merged (PR #117,5155bbb), so the sequencing prerequisites are satisfied. Satisfying aprerequisite is not approval. CR-DD-012B remains blocked on its own explicit
human implementation approval and its own bounded file allowlist. This proposal
is not that approval, and neither is merging it.
The ten questions, settled as recommendations
tc_cli.tc_run, after argumentassembly and privacy mapping, before the
if planning:branch. Contextsources are read exactly once there, which is what closes the TOCTOU gap; a
seam after the branch would not. The preview branch keeps its early
return,and the generated execution-correlation task ID stays after the branch so it
cannot enter
decision_id.build_run_planprojects a completeddecision instead of computing one; the v1 renderer and artifact builder are
unchanged; the artifact path stops assembling
prompt\ndataindependently andreads the snapshot's authoritative bytes. Validation is explicitly not
permission to rebuild.
RuntimeObservationand CR-DD-013 — subsumption without re-derivation.CapabilityResolutionstays the sole source of local capability evidence andcapability_evidence.pyis off the allowlist; the observation carries it asprovenance and adds only envelope member, actual binding, fallback occurrence,
and reason codes. The observed/configured/unknown distinction survives
verbatim.
flag, config value, env var, or caller argument may extend it. No permitted
member means the existing terminal outcome, not fall-through.
decision_idon theroute_decisionandworker_resultpayloads via the same open extension point CR-DD-013 used.route-worker-ledger.v1is untouched and unused by this path; if review findsotherwise, that is a stop condition, not a reason to widen the contract.
run_taskparameter, on theCR-DD-013 precedent. Stated plainly rather than as "inert": a caller who
supplies a decision does get different behavior; existing callers are
unaffected because they pass nothing.
construction, governed by three rules: termination is never repair, staleness
is binding-defined rather than clock-defined, and a missing observation stays
unknown rather than becoming unavailability.
files, with parity, no-rebuild traps, mutation, runtime separation, TOCTOU,
privacy, and regression coverage.
observation schemas, new cloud authority, acceptance, resume, quality scoring,
G3, and G6.
Three questions, now resolved by recorded decision
The first draft of this proposal left three questions open. All three are now
settled. Settling a design question is not implementation authority — the
slice remains unauthorized.
1. Capability volatility — binding only. Capability resolution constrains
execution binding, never governed-decision formation:
Capability answers "can the already-authorized plan execute right now?" and must
never silently answer "what policy or route should this task receive?" Otherwise
identical task and context inputs produce different decision IDs because a model
server briefly disappeared or a probe went stale — operational weather becoming
policy input, weakening replay, comparison, audit, and caching.
The behavioral cost is recorded plainly as a deliberate correction to CR-DD-013
semantics, not disguised as an implementation detail. Today
tc runmay choosea resilience route from live capability state; under this decision it no longer
may. A run with unknown local capability will produce a decision naming local
routes and fail at binding, where today it resolves to no local route earlier.
Nothing reopens CR-DD-013 — its authority stays spent,
capability_evidence.pystays off the allowlist, and the change is to the consumer.
2. Classifier — deterministic is authoritative for all decision-relevant
fields. A model-assisted classifier may remain advisory (suggestions, confidence
notes, review evidence) and may become decision-bearing only through a separate
CR that promotes its normalized output to an explicit, stable decision input.
3.
build_run_plansignature — coherence over compatibility. Preserved onlyif it still represents one coherent projection from the shared snapshot and
decision. A narrow signature break is safer than preserving an attractive second
integration path.
Runtime outcome model
The decision must encode the envelope richly enough for exactly three outcomes:
primary binding succeeds; primary unavailable with an authorized fallback bound
without changing the decision; or no authorized binding, failing closed.
The forbidden fourth outcome is recorded explicitly: runtime capability
resolution inventing a route the governed decision never authorized. Any
implementation permitting it has failed the slice regardless of what its tests
report.
Implementation approval gates — two stages
Gates 3–5 assert properties of code that does not exist yet, so they cannot be
satisfied before the authority to write that code is granted. The gates
therefore bind at two distinct stages:
An approval granting permission to implement without binding gates 3–5 is
incomplete, and an implementation reaching acceptance, merge, or closeout
without them passing must be rejected.
Proposal-stage preconditions — satisfied:
consequence.
planningbranch andconsumed by both paths.
Implementation obligations — bound at approval, satisfied before acceptance:
one snapshot, one decision, and two projections — not merely deletion.
cannot change the decision ID, route policy, or envelope.
fallback or a closed failure.
Satisfying gates 1–2 grants nothing on its own: implementation authority remains
a separate explicit approval with its own bounded file allowlist.
A guard that will fail by design
tests/test_governed_decision_integration_absence.pyasserts the CR-DD-012Afoundation stays unintegrated. It will fail the moment this slice integrates
it. The proposal names it so that retiring or narrowing the guard is a
reviewable part of the implementation approval rather than a silent side effect —
an implementation that quietly deletes it should be rejected. Per gate 3,
retirement is permitted only in the same change that adds the replacement
positive tests; the coverage is replaced, never merely removed.
Validation
git diff --check— clean, staged and unstagedorigin/main— the four paths above, nothing elsedocs/change/change_log.md— 0 changes, as requiredtests/test_governed_decision_integration_absence.py— 5 passed. This is theone focused guard that reads a file in this diff's neighbourhood and asserts
the foundation stays unintegrated; it passes because this change is
documentation-only.
Runtime tests were not otherwise run: the change is documentation-only and
touches no code path.
🤖 Generated with Claude Code