Creatidy/creatidy-kernel

Fork 0

D1-02 — Make the frozen Scarcity Router task runnable end-to-end #32

New issue

Closed

opened 2026-09-28 12:43:34 +00:00 by adrian.tkacz · 1 comment

adrian.tkacz commented

2026-09-28 12:43:34 +00:00

Owner

Parent: #30
Depends on completed D1-01: #31

Goal

Turn the completed K1-K8 foundation into the thinnest supported real-task execution path needed to run the first frozen dogfood scenario:

BioMedical-IT/scarcity-router#143

The next step after this issue must be able to execute that real task through Creatidy Kernel without manually assembling Python objects or Git plumbing.

This issue modifies Creatidy Kernel only.

It does NOT implement Scarcity Router #143.

Frozen dogfood subject

D1-01 selected and froze:

Repository:

BioMedical-IT/scarcity-router

Issue:

#143 — Flaky under load: test_scenario_11 client-disconnect cancel can assert before the cancel reaches the worker reader

Frozen repository base at D1-01 completion:

develop @ 781bace66cec4f91b952cbe1993a3524be90fb63

The implementation target is limited to:

tests/test_e2e_execution.py

The semantic requirement is to remove the cancellation race using deterministic bounded synchronization without weakening the assertion that cancellation reaches exactly the owning worker.

The authoritative verification plan from #31 remains the acceptance authority for the eventual dogfood run.

D1-02 must not implement that repair itself.

Desired outcome

After D1-02, the owner should be able to start the frozen task through one supported Kernel entry point, approximately:

creatidy-kernel dogfood run \
  --repo <Scarcity Router checkout or canonical repository> \
  --issue 143 \
  --approve

The exact CLI is implementation-owned.

The owner must not need to manually:

construct ScarcityRouterAllocator;
construct CodexRuntime;
construct ForgejoForge;
call run_live_reference() from Python;
create controller-owned Git objects;
create a worktree manually;
wire Runtime callbacks;
interpret SQLite directly.

The command may still require explicit configuration for credentials, Router origin, model-runtime evidence and Forge identity. Security-critical material must never be accepted through unsafe command-line arguments if that would expose it in process listings or shell history.

Scope principle

Build the narrowest real vertical slice that can execute the frozen #143 scenario.

Do NOT build a generic Program engine, arbitrary workflow language or universal repository automation layer.

Generalize only where the existing K1-K8 port boundary already requires it.

Required capabilities

1. Real repository subject

Kernel must operate from an explicit exact repository/base subject.

For the frozen dogfood scenario:

canonical repository is BioMedical-IT/scarcity-router;
base branch is develop;
exact base SHA is established before execution;
work occurs in a disposable isolated worktree or equivalent workspace;
the owner's existing checkout must remain untouched.

Kernel must refuse a workspace whose base cannot be established exactly.

Do not silently update or mutate canonical develop.

2. Frozen task input

The first real task may use an explicit checked-in or controller-owned task specification representing the frozen #143 contract.

Do not require a generic issue parser.

The task input must preserve at minimum:

repository identity;
exact base SHA;
task text;
allowed changed paths;
verification commands;
acceptance invariants;
attempt budget;
no-merge/no-deploy authority boundary.

Fetching arbitrary Forgejo issue prose and turning it into authority is NOT required for D1-02.

3. Workspace preparation

Create the disposable coding workspace automatically.

Required properties:

derived from the exact authorized base;
separate from Kernel control state;
separate from the owner's normal checkout;
no modification of canonical branch;
bounded writable repository workspace;
controller knows the exact pre-execution tree.

Do not claim hostile-worker isolation beyond what the existing Runtime actually enforces.

4. Real Scarcity Router allocation

Use the existing ScarcityRouterAllocator.

Do not introduce another model-selection path.

A new Attempt receives one real Router recommendation.

Existing Attempt recovery keeps its durable Allocation and does not reselect.

5. Real Codex Runtime composition

Use the existing Codex Runtime port and exact provider/model/reasoning-effort semantics.

D1-02 may add the minimal composition/configuration layer needed to instantiate the already-proven Runtime in a supported user-facing path.

Do not embed provider selection logic in the Runtime or CLI.

Do not weaken requested/resolved/observed identity evidence.

6. Coding prompt / task execution

The Runtime must receive the frozen task and relevant repository instructions.

Do not feed hidden acceptance secrets to the coding model unnecessarily.

For #143, the coding model may inspect the repository and edit only the authorized coding workspace.

The model is not the acceptance authority.

7. Candidate changed-path gate

Before repository tests can establish acceptance, Kernel/controller must compare the candidate against the exact base and reject changes outside:

tests/test_e2e_execution.py

This must be controller-owned evidence.

The coding model must not be able to redefine the allowed changed-file set.

8. Independent structural acceptance for #143

Because #143 modifies a test file, green tests alone are insufficient.

Implement the smallest controller-owned structural verification needed to enforce the frozen D1-01 invariants.

It must reject at minimum obvious weakening such as:

removing the relevant cancellation assertion;
skip / xfail;
catch-and-ignore of the relevant failure;
deletion of the relevant scenario;
unrelated file changes;
obvious large-sleep substitution where the frozen contract forbids it.

Do not build a generic static-analysis policy language.

If some semantic property cannot be safely established deterministically, preserve it as an explicit verification limitation for the later independent review rather than pretending it is proved.

9. Deterministic repository verification

Kernel must be able to run the frozen verification commands under controller authority.

For #143 the frozen plan is:

targeted CancellationTests;
exactly 8 repeated targeted runs;
one full make check;
structural diff inspection.

Command execution must be:

bounded by timeout;
performed in the candidate workspace;
output-bounded;
captured as evidence;
nonzero-exit = failed verification;
free of shell-string interpolation from worker-controlled text.

Do not add arbitrary worker-selected verification commands.

10. Candidate and acceptance subject

Verification must bind to the exact candidate Git subject.

A verification result for one tree/commit must never accept another.

The existing K4/K7 acceptance separation remains authoritative.

11. Real Forgejo PR delivery

After acceptance, use the existing Forge port / Forgejo AGit mechanism.

The PR must:

originate from the exact accepted candidate;
target develop;
use the existing exact-head/readback discipline;
never merge automatically;
never deploy.

No direct worker push authority.

12. Recovery

The supported path must retain the existing durable semantics across controller restart.

At minimum, D1-02 tests must prove recovery does not duplicate:

allocation;
runtime dispatch when outcome is uncertain;
accepted Program state;
Forge PR creation.

A live crash exercise will occur in the later dogfood execution issue; deterministic fixtures remain acceptable for implementation validation here.

User-facing status

The command should provide concise lifecycle output suitable for a human.

At minimum distinguish:

Program/task admitted;
Allocation selected or recovered;
Runtime dispatched/recovered;
candidate produced;
changed-path validation;
verification running/passed/failed;
accepted/rejected;
PR created or delivery unknown;
explicit no merge / no deploy.

Raw evidence may remain available through a separate inspect/export path.

Do not turn this into a dashboard or TUI.

Configuration

Use explicit configuration and existing secure mechanisms where possible.

Do not:

persist Router/Forge/provider secrets in Program evidence;
print secrets;
put bearer credentials in URLs;
invent a secrets manager;
copy credentials between products;
require owner credentials inside the coding workspace.

If the current existing adapters cannot be safely composed without an additional bounded configuration mechanism, implement only the smallest one necessary and document its trust assumptions.

Reuse-first

Before building new composition/plumbing, inspect existing:

K7/K8 live reference composition;
CLI;
workspace helpers;
Forgejo adapter;
Scarcity Router adapter;
Codex Runtime;
any reusable mechanisms from appropriately licensed external projects if directly relevant.

Prefer ADAPT/PORT over duplicate implementation where semantics match.

Do not perform a broad framework search.

Explicit non-goals

D1-02 does NOT authorize:

implementation of Scarcity Router #143;
arbitrary Forgejo issue execution;
arbitrary repositories/tasks;
dynamic workflow generation;
automatic remediation loops;
automatic reviewer dispatch;
automatic merge;
deployment;
production repository mutation;
generic shell access supplied by a worker;
web UI;
multi-user operation;
new Scarcity Router behavior;
new model-routing policy;
hostile-code isolation claims;
release packaging.

Acceptance

D1-02 is complete when deterministic evidence proves that the frozen #143 scenario can be composed through one supported Kernel entry point up to and including a synthetic/effect-controlled Forge PR proof, with:

exact real-repository subject semantics;
automatic disposable workspace preparation;
existing Scarcity Router allocation;
existing Codex Runtime;
bounded controller-owned verification;
changed-file enforcement;
structural anti-test-weakening guard appropriate to #143;
exact candidate acceptance;
existing AGit delivery semantics;
recovery/no-duplicate guarantees;
understandable CLI lifecycle output.

The implementation tests must not perform paid inference or create a real Scarcity Router PR.

Completion

Deliver through normal /deliver-issue governance:

one branch;
one PR targeting develop;
full validation;
fresh independent whole-PR review;
no automatic merge.

After owner merge, do NOT automatically execute Scarcity Router #143.

The next child will be the actual live dogfood run against the then-current canonical Scarcity Router develop.

Parent: #30 Depends on completed D1-01: #31 ## Goal Turn the completed K1-K8 foundation into the thinnest supported real-task execution path needed to run the first frozen dogfood scenario: `BioMedical-IT/scarcity-router#143` The next step after this issue must be able to execute that real task through Creatidy Kernel without manually assembling Python objects or Git plumbing. This issue modifies Creatidy Kernel only. It does NOT implement Scarcity Router #143. ## Frozen dogfood subject D1-01 selected and froze: Repository: `BioMedical-IT/scarcity-router` Issue: `#143 — Flaky under load: test_scenario_11 client-disconnect cancel can assert before the cancel reaches the worker reader` Frozen repository base at D1-01 completion: `develop @ 781bace66cec4f91b952cbe1993a3524be90fb63` The implementation target is limited to: `tests/test_e2e_execution.py` The semantic requirement is to remove the cancellation race using deterministic bounded synchronization without weakening the assertion that cancellation reaches exactly the owning worker. The authoritative verification plan from #31 remains the acceptance authority for the eventual dogfood run. D1-02 must not implement that repair itself. ## Desired outcome After D1-02, the owner should be able to start the frozen task through one supported Kernel entry point, approximately: ```text creatidy-kernel dogfood run \ --repo <Scarcity Router checkout or canonical repository> \ --issue 143 \ --approve ``` The exact CLI is implementation-owned. The owner must not need to manually: - construct `ScarcityRouterAllocator`; - construct `CodexRuntime`; - construct `ForgejoForge`; - call `run_live_reference()` from Python; - create controller-owned Git objects; - create a worktree manually; - wire Runtime callbacks; - interpret SQLite directly. The command may still require explicit configuration for credentials, Router origin, model-runtime evidence and Forge identity. Security-critical material must never be accepted through unsafe command-line arguments if that would expose it in process listings or shell history. ## Scope principle Build the narrowest real vertical slice that can execute the frozen #143 scenario. Do NOT build a generic Program engine, arbitrary workflow language or universal repository automation layer. Generalize only where the existing K1-K8 port boundary already requires it. ## Required capabilities ### 1. Real repository subject Kernel must operate from an explicit exact repository/base subject. For the frozen dogfood scenario: - canonical repository is `BioMedical-IT/scarcity-router`; - base branch is `develop`; - exact base SHA is established before execution; - work occurs in a disposable isolated worktree or equivalent workspace; - the owner's existing checkout must remain untouched. Kernel must refuse a workspace whose base cannot be established exactly. Do not silently update or mutate canonical `develop`. ### 2. Frozen task input The first real task may use an explicit checked-in or controller-owned task specification representing the frozen #143 contract. Do not require a generic issue parser. The task input must preserve at minimum: - repository identity; - exact base SHA; - task text; - allowed changed paths; - verification commands; - acceptance invariants; - attempt budget; - no-merge/no-deploy authority boundary. Fetching arbitrary Forgejo issue prose and turning it into authority is NOT required for D1-02. ### 3. Workspace preparation Create the disposable coding workspace automatically. Required properties: - derived from the exact authorized base; - separate from Kernel control state; - separate from the owner's normal checkout; - no modification of canonical branch; - bounded writable repository workspace; - controller knows the exact pre-execution tree. Do not claim hostile-worker isolation beyond what the existing Runtime actually enforces. ### 4. Real Scarcity Router allocation Use the existing `ScarcityRouterAllocator`. Do not introduce another model-selection path. A new Attempt receives one real Router recommendation. Existing Attempt recovery keeps its durable Allocation and does not reselect. ### 5. Real Codex Runtime composition Use the existing Codex Runtime port and exact provider/model/reasoning-effort semantics. D1-02 may add the minimal composition/configuration layer needed to instantiate the already-proven Runtime in a supported user-facing path. Do not embed provider selection logic in the Runtime or CLI. Do not weaken requested/resolved/observed identity evidence. ### 6. Coding prompt / task execution The Runtime must receive the frozen task and relevant repository instructions. Do not feed hidden acceptance secrets to the coding model unnecessarily. For #143, the coding model may inspect the repository and edit only the authorized coding workspace. The model is not the acceptance authority. ### 7. Candidate changed-path gate Before repository tests can establish acceptance, Kernel/controller must compare the candidate against the exact base and reject changes outside: `tests/test_e2e_execution.py` This must be controller-owned evidence. The coding model must not be able to redefine the allowed changed-file set. ### 8. Independent structural acceptance for #143 Because #143 modifies a test file, green tests alone are insufficient. Implement the smallest controller-owned structural verification needed to enforce the frozen D1-01 invariants. It must reject at minimum obvious weakening such as: - removing the relevant cancellation assertion; - `skip` / `xfail`; - catch-and-ignore of the relevant failure; - deletion of the relevant scenario; - unrelated file changes; - obvious large-sleep substitution where the frozen contract forbids it. Do not build a generic static-analysis policy language. If some semantic property cannot be safely established deterministically, preserve it as an explicit verification limitation for the later independent review rather than pretending it is proved. ### 9. Deterministic repository verification Kernel must be able to run the frozen verification commands under controller authority. For #143 the frozen plan is: 1. targeted `CancellationTests`; 2. exactly 8 repeated targeted runs; 3. one full `make check`; 4. structural diff inspection. Command execution must be: - bounded by timeout; - performed in the candidate workspace; - output-bounded; - captured as evidence; - nonzero-exit = failed verification; - free of shell-string interpolation from worker-controlled text. Do not add arbitrary worker-selected verification commands. ### 10. Candidate and acceptance subject Verification must bind to the exact candidate Git subject. A verification result for one tree/commit must never accept another. The existing K4/K7 acceptance separation remains authoritative. ### 11. Real Forgejo PR delivery After acceptance, use the existing Forge port / Forgejo AGit mechanism. The PR must: - originate from the exact accepted candidate; - target `develop`; - use the existing exact-head/readback discipline; - never merge automatically; - never deploy. No direct worker push authority. ### 12. Recovery The supported path must retain the existing durable semantics across controller restart. At minimum, D1-02 tests must prove recovery does not duplicate: - allocation; - runtime dispatch when outcome is uncertain; - accepted Program state; - Forge PR creation. A live crash exercise will occur in the later dogfood execution issue; deterministic fixtures remain acceptable for implementation validation here. ## User-facing status The command should provide concise lifecycle output suitable for a human. At minimum distinguish: - Program/task admitted; - Allocation selected or recovered; - Runtime dispatched/recovered; - candidate produced; - changed-path validation; - verification running/passed/failed; - accepted/rejected; - PR created or delivery unknown; - explicit `no merge / no deploy`. Raw evidence may remain available through a separate inspect/export path. Do not turn this into a dashboard or TUI. ## Configuration Use explicit configuration and existing secure mechanisms where possible. Do not: - persist Router/Forge/provider secrets in Program evidence; - print secrets; - put bearer credentials in URLs; - invent a secrets manager; - copy credentials between products; - require owner credentials inside the coding workspace. If the current existing adapters cannot be safely composed without an additional bounded configuration mechanism, implement only the smallest one necessary and document its trust assumptions. ## Reuse-first Before building new composition/plumbing, inspect existing: - K7/K8 live reference composition; - CLI; - workspace helpers; - Forgejo adapter; - Scarcity Router adapter; - Codex Runtime; - any reusable mechanisms from appropriately licensed external projects if directly relevant. Prefer ADAPT/PORT over duplicate implementation where semantics match. Do not perform a broad framework search. ## Explicit non-goals D1-02 does NOT authorize: - implementation of Scarcity Router #143; - arbitrary Forgejo issue execution; - arbitrary repositories/tasks; - dynamic workflow generation; - automatic remediation loops; - automatic reviewer dispatch; - automatic merge; - deployment; - production repository mutation; - generic shell access supplied by a worker; - web UI; - multi-user operation; - new Scarcity Router behavior; - new model-routing policy; - hostile-code isolation claims; - release packaging. ## Acceptance D1-02 is complete when deterministic evidence proves that the frozen #143 scenario can be composed through one supported Kernel entry point up to and including a synthetic/effect-controlled Forge PR proof, with: - exact real-repository subject semantics; - automatic disposable workspace preparation; - existing Scarcity Router allocation; - existing Codex Runtime; - bounded controller-owned verification; - changed-file enforcement; - structural anti-test-weakening guard appropriate to #143; - exact candidate acceptance; - existing AGit delivery semantics; - recovery/no-duplicate guarantees; - understandable CLI lifecycle output. The implementation tests must not perform paid inference or create a real Scarcity Router PR. ## Completion Deliver through normal `/deliver-issue` governance: - one branch; - one PR targeting `develop`; - full validation; - fresh independent whole-PR review; - no automatic merge. After owner merge, do NOT automatically execute Scarcity Router #143. The next child will be the actual live dogfood run against the then-current canonical Scarcity Router `develop`.

kilo referenced this issue from a pull request that will close it,

2026-09-28 13:37:51 +00:00

D1-02: Make the frozen Scarcity Router task runnable end-to-end #33

kilo commented

2026-09-28 13:38:23 +00:00

Member

D1-02 delivery ledger

Issue: #32 (selected by owner)
PR: #33 → develop
Branch: feat/d1-02-dogfood-composition
Current HEAD: 72f3ddcee754f1d67cc75e914375971818a45372
Base: 49af0c4fd7475b6066a8f06fccdbe6b187042673 (canonical develop)
max_remediation_cycles = 10, remediation_used = 0
Validation: make check (788 passed; ruff format/check, basedpyright strict, lint-imports, secrets scan, git diff --check), make package-check passed
Review status: pending first independent full-PR review dispatch (repository_review / architecture-security criticality: persistence durability, recovery, external effects, authority boundaries)

**D1-02 delivery ledger** - Issue: #32 (selected by owner) - PR: #33 → `develop` - Branch: `feat/d1-02-dogfood-composition` - Current HEAD: `72f3ddcee754f1d67cc75e914375971818a45372` - Base: `49af0c4fd7475b6066a8f06fccdbe6b187042673` (canonical `develop`) - `max_remediation_cycles = 10`, `remediation_used = 0` - Validation: `make check` (788 passed; ruff format/check, basedpyright strict, lint-imports, secrets scan, `git diff --check`), `make package-check` passed - Review status: pending first independent full-PR review dispatch (repository_review / architecture-security criticality: persistence durability, recovery, external effects, authority boundaries)

adrian.tkacz closed this issue

2026-09-28 20:15:30 +00:00

adrian.tkacz referenced this issue

2026-09-28 20:17:53 +00:00

D1-03 — Preflight the first live dogfood run against Scarcity Router #143 #34

kilo referenced this issue

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

D1-03a: Repair the three live dogfood preflight blockers (#35) #36

kilo referenced this issue

2026-10-04 22:24:52 +00:00

[Kernel][G03] Implement durable candidate-bound product review and remediation #54