Creatidy/creatidy-kernel

Fork 0

D1-03a — Repair live dogfood preflight blockers #35

New issue

Closed

opened 2026-09-28 22:26:19 +00:00 by adrian.tkacz · 0 comments

adrian.tkacz commented

2026-09-28 22:26:19 +00:00

Owner

Parent: #30
Unblocks: #34 — D1-03 live dogfood preflight
Depends on merged D1-02 / PR #33

Goal

Repair the three deterministic blockers discovered by D1-03 before the first live Creatidy Kernel dogfood inference.

This is a narrow corrective implementation issue.

Do NOT execute Scarcity Router #143.
Do NOT start a live model turn.
Do NOT create a Scarcity Router PR.

After this issue is merged, D1-03 / #34 must be re-run from the beginning before any live dogfood execution is authorized.

Evidence

D1-03 preflight ran against:

Creatidy Kernel:

develop @ 72bee742ec0b34d2bb16ace95b03794b17ccc1d3

Scarcity Router:

develop @ 59538e949d2b3488668c9649cf3728dbe87b38bb

Real Router selection:

provider: zai
model: glm-5.3
reasoning effort: low

No model inference occurred.

D1-03 ended:

LIVE_CONFIGURATION_BLOCKED

because of the three issues below.

Blocker 1 — frozen structural token does not match the real target source

Current Kernel scarcity_router_143_task() requires:

assertEqual(bystander.cancels, [])

The actual Scarcity Router source at the verified live base contains:

self.assertEqual([], bystander.cancels)

Therefore a legitimate candidate would deterministically fail the structural gate even if the coding task were implemented correctly.

Required correction

Update the frozen #143 structural token to match the actual assertion-bearing source form:

assertEqual([], bystander.cancels)

Preserve the semantic invariant:

the bystander worker receives no cancellation or other ownership effect.

Do not weaken the structural gate.

Do not generalize this into AST policy infrastructure or a generic assertion matcher.

Regression

Tests must prove:

the real/current assertion form passes the structural baseline;
removal of the bystander ownership assertion still rejects;
weakening the ownership requirement still rejects as before.

The optional D1-02 review idea to detect novel assignments such as bystander.cancels = ... remains DEFERRED. Do not expand this issue unless required by an existing failing test.

Blocker 2 — live CodexStdio construction omits schema_version

Current live dogfood composition calls CodexStdio with:

schema_methods=CODEX_METHODS
no schema_version

CodexStdio deliberately requires:

when schema_methods is non-empty, schema_version == expected_version.

Therefore the live dogfood connection_factory() fails before any model dispatch.

Required correction

Pass the already configured exact Codex version as the schema version:

schema_version=codex_version

Do not relax the CodexStdio validation.

Do not remove method inventory checking.

Regression

Add/adjust a deterministic live-composition test proving:

dogfood constructs CodexStdio with the pinned version as both expected binary version and schema version;
mismatched schema/version remains fail-closed.

No real Codex inference.

Blocker 3 — trusted reasoning-effort evidence is not wired into live CLI

CodexRuntime correctly requires an explicit trusted support binding for any non-null reasoning effort:

(provider, model, effort) in supported_efforts

Current dogfood CLI does not pass supported_efforts to run_dogfood().

The default is therefore:

frozenset()

The real Router selected:

zai / glm-5.3 / low

so the Runtime would fail closed with UnsupportedExecution before dispatch.

This fail-closed behavior is correct and MUST remain.

Existing authority source

Do not invent a new model registry.

The existing CREATIDY_DOGFOOD_RUNTIME_BINDING is already used to construct the Allocation passed as a Scarcity Router runtime binding.

ScarcityRouterAllocator explicitly defines these runtime bindings as:

controller assertions of executable limits, not Router policy.

A binding contains the exact:

runtime;
provider;
model;
reasoning effort;
capability/context limits.

This controller-owned configured runtime binding is therefore the appropriate existing source for trusted supported-effort evidence.

The Router recommendation itself is NOT the evidence.

Required correction

Extend the dogfood live composition minimally so that its configured runtime binding also produces the trusted supported_efforts set used by CodexRuntime.

Conceptually:

controller-configured runtime binding
    |
    +--> ScarcityRouterAllocator runtime_bindings
    |
    +--> CodexRuntime supported_efforts

For a binding with explicit effort:

zai / glm-5.3 / low

the composition should expose:

frozenset({("zai", "glm-5.3", "low")})

and the CLI must pass that exact set to run_dogfood().

For a binding with reasoning_effort is None, do not manufacture an effort binding.

Preserve the existing distinction:

None != "none"

Critical invariant

Do NOT derive supported_efforts from the Router response.

The direction of authority must remain:

controller configuration
        |
        v
executable runtime binding
        |
        +--> constrains Router selection
        |
        +--> proves Runtime effort support

The Router may select only something compatible with the configured binding.

It must never expand Runtime capability.

Fail-closed cases

Tests must prove:

configured zai/glm-5.3/low + Router selects same tuple -> accepted by Runtime support gate;
configured effort differs from Router selection -> allocation fails before execution;
no configured explicit effort + Router returns explicit effort -> no trusted effort support exists / selection cannot become executable;
null/unconfigured effort remains null and is not silently mapped to "none";
unsupported explicit effort remains UnsupportedExecution.

Do not weaken CodexRuntime._inputs().

Composition shape

A minimal change may extend DogfoodLiveComponents with something equivalent to:

supported_efforts

and pass it from CLI into:

run_dogfood(..., supported_efforts=...)

Exact implementation is owned by the issue implementer.

Prefer reuse of the already parsed controller runtime binding rather than parsing the same configuration twice.

Do not add a second environment variable merely to duplicate the same provider/model/effort assertion unless source-level evidence shows the existing binding cannot safely serve both roles.

Scope guard

This issue MUST NOT introduce:

a model registry;
a Router policy copy;
dynamic model discovery inside Kernel;
effort inference from model names;
a workflow engine;
generic configuration framework;
a new Runtime abstraction;
a new allocator abstraction;
live inference;
Scarcity Router modifications.

Keep the correction local to D1 dogfood composition and existing adapter seams.

Preserve D1-02 invariants

Regression coverage must continue to prove:

controller-owned task authority;
exact base/candidate binding;
closed Codex child environment;
no controller secrets inherited by Codex;
controller-owned verification;
Git-clean post-verification requirement;
exact accepted candidate delivered through existing AGit;
no automatic merge;
no deploy.

Validation

Run normal /deliver-issue governance.

Required:

full make check;
make package-check;
exact-head CI;
fresh independent whole-PR review.

No paid/live inference is required or authorized for this implementation issue.

Reviewer preference:

Z.ai GLM-5.3
fresh context
max reasoning when available
no OpenAI fallback unless owner explicitly changes the instruction.

Acceptance

D1-03a is complete when deterministic tests prove all three original D1-03 blockers are removed:

#143 structural token matches the verified real source contract;
live CodexStdio composition supplies the exact required schema_version;
controller-owned runtime binding supplies the exact supported_efforts evidence used by live CodexRuntime.

The merged implementation must still fail closed on mismatched or unsupported provider/model/effort.

After merge

Do NOT start the live dogfood run.

Return to Issue #34 and repeat the complete D1-03 preflight against:

the new Kernel develop;
the then-current Scarcity Router develop;
a fresh real Router selection.

Only a new:

READY_FOR_LIVE_DOGFOOD

result may authorize the subsequent live execution issue.

Parent: #30 Unblocks: #34 — D1-03 live dogfood preflight Depends on merged D1-02 / PR #33 ## Goal Repair the three deterministic blockers discovered by D1-03 before the first live Creatidy Kernel dogfood inference. This is a narrow corrective implementation issue. Do NOT execute Scarcity Router #143. Do NOT start a live model turn. Do NOT create a Scarcity Router PR. After this issue is merged, D1-03 / #34 must be re-run from the beginning before any live dogfood execution is authorized. ## Evidence D1-03 preflight ran against: Creatidy Kernel: `develop @ 72bee742ec0b34d2bb16ace95b03794b17ccc1d3` Scarcity Router: `develop @ 59538e949d2b3488668c9649cf3728dbe87b38bb` Real Router selection: - provider: `zai` - model: `glm-5.3` - reasoning effort: `low` No model inference occurred. D1-03 ended: `LIVE_CONFIGURATION_BLOCKED` because of the three issues below. --- ## Blocker 1 — frozen structural token does not match the real target source Current Kernel `scarcity_router_143_task()` requires: ```text assertEqual(bystander.cancels, []) ``` The actual Scarcity Router source at the verified live base contains: ```text self.assertEqual([], bystander.cancels) ``` Therefore a legitimate candidate would deterministically fail the structural gate even if the coding task were implemented correctly. ### Required correction Update the frozen #143 structural token to match the actual assertion-bearing source form: ```text assertEqual([], bystander.cancels) ``` Preserve the semantic invariant: the bystander worker receives no cancellation or other ownership effect. Do not weaken the structural gate. Do not generalize this into AST policy infrastructure or a generic assertion matcher. ### Regression Tests must prove: - the real/current assertion form passes the structural baseline; - removal of the bystander ownership assertion still rejects; - weakening the ownership requirement still rejects as before. The optional D1-02 review idea to detect novel assignments such as `bystander.cancels = ...` remains DEFERRED. Do not expand this issue unless required by an existing failing test. --- ## Blocker 2 — live CodexStdio construction omits schema_version Current live dogfood composition calls `CodexStdio` with: - `schema_methods=CODEX_METHODS` - no `schema_version` `CodexStdio` deliberately requires: when `schema_methods` is non-empty, `schema_version == expected_version`. Therefore the live dogfood `connection_factory()` fails before any model dispatch. ### Required correction Pass the already configured exact Codex version as the schema version: ```text schema_version=codex_version ``` Do not relax the `CodexStdio` validation. Do not remove method inventory checking. ### Regression Add/adjust a deterministic live-composition test proving: - dogfood constructs CodexStdio with the pinned version as both expected binary version and schema version; - mismatched schema/version remains fail-closed. No real Codex inference. --- ## Blocker 3 — trusted reasoning-effort evidence is not wired into live CLI `CodexRuntime` correctly requires an explicit trusted support binding for any non-null reasoning effort: ```text (provider, model, effort) in supported_efforts ``` Current dogfood CLI does not pass `supported_efforts` to `run_dogfood()`. The default is therefore: ```text frozenset() ``` The real Router selected: ```text zai / glm-5.3 / low ``` so the Runtime would fail closed with `UnsupportedExecution` before dispatch. This fail-closed behavior is correct and MUST remain. ### Existing authority source Do not invent a new model registry. The existing `CREATIDY_DOGFOOD_RUNTIME_BINDING` is already used to construct the `Allocation` passed as a Scarcity Router runtime binding. `ScarcityRouterAllocator` explicitly defines these runtime bindings as: controller assertions of executable limits, not Router policy. A binding contains the exact: - runtime; - provider; - model; - reasoning effort; - capability/context limits. This controller-owned configured runtime binding is therefore the appropriate existing source for trusted supported-effort evidence. The Router recommendation itself is NOT the evidence. ### Required correction Extend the dogfood live composition minimally so that its configured runtime binding also produces the trusted `supported_efforts` set used by `CodexRuntime`. Conceptually: ```text controller-configured runtime binding | +--> ScarcityRouterAllocator runtime_bindings | +--> CodexRuntime supported_efforts ``` For a binding with explicit effort: ```text zai / glm-5.3 / low ``` the composition should expose: ```text frozenset({("zai", "glm-5.3", "low")}) ``` and the CLI must pass that exact set to `run_dogfood()`. For a binding with `reasoning_effort is None`, do not manufacture an effort binding. Preserve the existing distinction: ```text None != "none" ``` ### Critical invariant Do NOT derive `supported_efforts` from the Router response. The direction of authority must remain: ```text controller configuration | v executable runtime binding | +--> constrains Router selection | +--> proves Runtime effort support ``` The Router may select only something compatible with the configured binding. It must never expand Runtime capability. ### Fail-closed cases Tests must prove: - configured `zai/glm-5.3/low` + Router selects same tuple -> accepted by Runtime support gate; - configured effort differs from Router selection -> allocation fails before execution; - no configured explicit effort + Router returns explicit effort -> no trusted effort support exists / selection cannot become executable; - null/unconfigured effort remains null and is not silently mapped to `"none"`; - unsupported explicit effort remains `UnsupportedExecution`. Do not weaken `CodexRuntime._inputs()`. --- ## Composition shape A minimal change may extend `DogfoodLiveComponents` with something equivalent to: ```text supported_efforts ``` and pass it from CLI into: ```text run_dogfood(..., supported_efforts=...) ``` Exact implementation is owned by the issue implementer. Prefer reuse of the already parsed controller runtime binding rather than parsing the same configuration twice. Do not add a second environment variable merely to duplicate the same provider/model/effort assertion unless source-level evidence shows the existing binding cannot safely serve both roles. --- ## Scope guard This issue MUST NOT introduce: - a model registry; - a Router policy copy; - dynamic model discovery inside Kernel; - effort inference from model names; - a workflow engine; - generic configuration framework; - a new Runtime abstraction; - a new allocator abstraction; - live inference; - Scarcity Router modifications. Keep the correction local to D1 dogfood composition and existing adapter seams. ## Preserve D1-02 invariants Regression coverage must continue to prove: - controller-owned task authority; - exact base/candidate binding; - closed Codex child environment; - no controller secrets inherited by Codex; - controller-owned verification; - Git-clean post-verification requirement; - exact accepted candidate delivered through existing AGit; - no automatic merge; - no deploy. ## Validation Run normal `/deliver-issue` governance. Required: - full `make check`; - `make package-check`; - exact-head CI; - fresh independent whole-PR review. No paid/live inference is required or authorized for this implementation issue. Reviewer preference: - Z.ai GLM-5.3 - fresh context - max reasoning when available - no OpenAI fallback unless owner explicitly changes the instruction. ## Acceptance D1-03a is complete when deterministic tests prove all three original D1-03 blockers are removed: 1. #143 structural token matches the verified real source contract; 2. live CodexStdio composition supplies the exact required `schema_version`; 3. controller-owned runtime binding supplies the exact `supported_efforts` evidence used by live `CodexRuntime`. The merged implementation must still fail closed on mismatched or unsupported provider/model/effort. ## After merge Do NOT start the live dogfood run. Return to Issue #34 and repeat the complete D1-03 preflight against: - the new Kernel `develop`; - the then-current Scarcity Router `develop`; - a fresh real Router selection. Only a new: `READY_FOR_LIVE_DOGFOOD` result may authorize the subsequent live execution issue.

adrian.tkacz referenced this issue from a commit

2026-09-28 22:42:19 +00:00

fix: repair three live dogfood preflight blockers (D1-03a, #35)