Creatidy/creatidy-kernel

Fork 0

D1-01 — Freeze the first real repository demo scenario #31

New issue

Closed

opened 2026-09-28 12:04:57 +00:00 by adrian.tkacz · 2 comments

adrian.tkacz commented

2026-09-28 12:04:57 +00:00

Owner

Parent: #30

Goal

Define and prepare the smallest real repository scenario that Creatidy Kernel will use for its first end-to-end dogfood demo.

This issue freezes the demo subject before Kernel gains new live-composition behavior.

The result must be specific enough that later D1 work can answer unambiguously:

what repository the agent is allowed to change;
what exact task it receives;
what files/effects are permitted;
what deterministic checks establish correctness;
what constitutes an accepted candidate;
what Forgejo effect is expected;
what credentials and trust assumptions exist;
what must remain impossible.

This issue does NOT implement the Kernel live demo runner.

Demo repository

Create a dedicated owner-controlled disposable repository on canonical Forgejo:

Creatidy/kernel-demo

The repository exists only to dogfood Creatidy Kernel.

It should be small, public if there is no reason to keep it private, Apache-2.0 licensed, and contain no credentials, private workload data or production dependencies.

GitHub mirroring is not required for D1-01.

The default development branch should be develop.

main remains human-controlled and is not needed by the demo.

Technology

Use a deliberately small Python 3.12 project.

Prefer:

pyproject.toml;
src/ package layout;
pytest;
ruff if useful;
no external runtime dependencies unless genuinely necessary.

The repository must be fast to clone, inspect and test.

Do not create a toy consisting only of a text file. The agent must edit real source code and satisfy real tests.

Frozen first task

The first demo task is:

Implement normalize_slug(value: str) -> str according to the repository contract and make the existing test suite pass.

The repository should initially contain the function as intentionally incomplete production code, for example by raising NotImplementedError.

The intended contract:

trim leading/trailing whitespace;
Unicode-normalize text before processing;
transliterate/normalize common accented Latin characters to their ASCII equivalents where the chosen implementation can do so deterministically without a new dependency;
lowercase;
convert runs of non-alphanumeric characters to a single -;
collapse repeated separators;
remove leading/trailing separators;
return only ASCII lowercase letters, digits and -;
reject or explicitly handle an input that normalizes to an empty slug according to one clearly documented rule;
impose a deterministic maximum output length without splitting the final separator structure incorrectly.

Do not hide requirements from the agent. The repository task/instructions and tests should agree.

If implementing accented-character handling correctly would require an unnecessary dependency, choose and document a smaller standard-library-only normalization contract instead. Determinism and a clean task contract matter more than feature breadth.

Why this task

The task should be:

real source-code modification;
small enough to finish predictably;
nontrivial enough to require reasoning;
independently testable;
deterministic;
free of network dependencies;
free of secrets;
safe to repeat;
easy for a human to inspect.

It must not require architectural changes, external APIs or broad repository exploration.

Repository shape

Keep the initial repository approximately this small:

kernel-demo/
├── pyproject.toml
├── README.md
├── LICENSE
├── src/
│   └── kernel_demo/
│       ├── __init__.py
│       └── slug.py
└── tests/
    └── test_slug.py

Additional files are allowed only when they materially improve the demo contract.

Acceptance checks

Freeze one deterministic verification command suitable for Kernel-controlled execution.

Preferred:

python -m pytest -q

If the repository uses uv, the exact command may instead be:

uv run --locked pytest -q

The command must:

run offline after dependencies are installed;
finish quickly;
have deterministic pass/fail semantics;
return nonzero on failure;
require no credentials;
write no state outside normal test/cache paths.

Also define an allowed changed-file set for the first demo.

Prefer:

src/kernel_demo/slug.py

The first demo should fail verification if the candidate modifies unrelated source, test, configuration or governance files.

Tests are controller-owned acceptance evidence. The coding Runtime must not be authorized to rewrite tests/test_slug.py to make itself pass.

Initial repository state

The starting develop branch must:

clone cleanly;
install successfully;
have the intended failing tests because normalize_slug is incomplete;
have no unrelated test failures;
contain no uncommitted/generated artifacts;
have a known exact base commit recorded in this issue.

Record:

repository canonical URL;
exact initial develop SHA;
Python version;
dependency/install command;
verification command;
expected failing tests before implementation.

Workspace authority

For this first demo, the coding Runtime may modify only the disposable checked-out worktree.

It must not receive authority to:

modify the Kernel repository;
modify the demo repository's tests;
alter .git configuration;
push directly;
merge;
deploy;
access parent directories;
access owner credentials;
access arbitrary network destinations.

The controller owns candidate collection, verification and Forge delivery.

Trusted-development limitations must be stated honestly. Do not claim hostile-code isolation unless a real sandbox proves it.

Forge behavior

The successful later D1 demo will:

start from the frozen develop base;
let the Runtime produce a candidate;
verify the exact candidate;
accept only the verified subject;
create one Forgejo PR targeting develop through Kernel's existing Forge/AGit boundary;
never merge it automatically.

D1-01 does not need to make that live PR yet. It prepares the repository and exact conditions required for it.

Repeatability

The scenario must be easy to reset.

Document the minimum owner action needed to return the demo repository to the frozen initial state after a successful demo.

Prefer a clean branch/base-reset procedure over scripts with hidden state.

Do not require deleting Kernel's durable evidence merely to reset the demo repository.

UX baseline

Record what a human would currently need to do manually to execute this scenario using today's Kernel APIs.

This is baseline evidence for D1.

Do not fix the UX in this issue.

The purpose is to identify which manual steps D1-02 must remove.

Reuse-first

Before adding scaffolding or helper code, inspect whether an existing minimal repository mechanism can be reused.

Do not import a large template/framework merely to create this tiny demo.

Deliverables

This issue is complete when:

Creatidy/kernel-demo exists on Forgejo.
Its initial develop state is frozen and revision-pinned.
The coding task is written down exactly.
The test suite discriminates incomplete vs correct behavior.
Allowed changed files are explicit.
Verification command is frozen.
Trust/credential/workspace assumptions are explicit.
Reset procedure is documented.
Current manual Kernel setup steps are recorded as D1-02 input.
No Kernel implementation has been changed.

Validation

Run the demo repository's own installation and test commands.

Demonstrate:

expected failing baseline caused only by the intentionally incomplete function;
a temporary known-good implementation makes all checks pass;
restore the repository to the intentionally incomplete baseline before closing this issue.

Do not leave the solution committed on develop.

Completion

Record the final evidence on this issue.

No Creatidy Kernel PR is expected from D1-01 unless investigation discovers that repository-side preparation genuinely belongs there.

Do not begin D1-02 automatically.

Parent: #30 ## Goal Define and prepare the smallest real repository scenario that Creatidy Kernel will use for its first end-to-end dogfood demo. This issue freezes the demo subject before Kernel gains new live-composition behavior. The result must be specific enough that later D1 work can answer unambiguously: - what repository the agent is allowed to change; - what exact task it receives; - what files/effects are permitted; - what deterministic checks establish correctness; - what constitutes an accepted candidate; - what Forgejo effect is expected; - what credentials and trust assumptions exist; - what must remain impossible. This issue does NOT implement the Kernel live demo runner. ## Demo repository Create a dedicated owner-controlled disposable repository on canonical Forgejo: `Creatidy/kernel-demo` The repository exists only to dogfood Creatidy Kernel. It should be small, public if there is no reason to keep it private, Apache-2.0 licensed, and contain no credentials, private workload data or production dependencies. GitHub mirroring is not required for D1-01. The default development branch should be `develop`. `main` remains human-controlled and is not needed by the demo. ## Technology Use a deliberately small Python 3.12 project. Prefer: - `pyproject.toml`; - `src/` package layout; - pytest; - ruff if useful; - no external runtime dependencies unless genuinely necessary. The repository must be fast to clone, inspect and test. Do not create a toy consisting only of a text file. The agent must edit real source code and satisfy real tests. ## Frozen first task The first demo task is: > Implement `normalize_slug(value: str) -> str` according to the repository contract and make the existing test suite pass. The repository should initially contain the function as intentionally incomplete production code, for example by raising `NotImplementedError`. The intended contract: - trim leading/trailing whitespace; - Unicode-normalize text before processing; - transliterate/normalize common accented Latin characters to their ASCII equivalents where the chosen implementation can do so deterministically without a new dependency; - lowercase; - convert runs of non-alphanumeric characters to a single `-`; - collapse repeated separators; - remove leading/trailing separators; - return only ASCII lowercase letters, digits and `-`; - reject or explicitly handle an input that normalizes to an empty slug according to one clearly documented rule; - impose a deterministic maximum output length without splitting the final separator structure incorrectly. Do not hide requirements from the agent. The repository task/instructions and tests should agree. If implementing accented-character handling correctly would require an unnecessary dependency, choose and document a smaller standard-library-only normalization contract instead. Determinism and a clean task contract matter more than feature breadth. ## Why this task The task should be: - real source-code modification; - small enough to finish predictably; - nontrivial enough to require reasoning; - independently testable; - deterministic; - free of network dependencies; - free of secrets; - safe to repeat; - easy for a human to inspect. It must not require architectural changes, external APIs or broad repository exploration. ## Repository shape Keep the initial repository approximately this small: ```text kernel-demo/ ├── pyproject.toml ├── README.md ├── LICENSE ├── src/ │ └── kernel_demo/ │ ├── __init__.py │ └── slug.py └── tests/ └── test_slug.py ``` Additional files are allowed only when they materially improve the demo contract. ## Acceptance checks Freeze one deterministic verification command suitable for Kernel-controlled execution. Preferred: ```sh python -m pytest -q ``` If the repository uses `uv`, the exact command may instead be: ```sh uv run --locked pytest -q ``` The command must: - run offline after dependencies are installed; - finish quickly; - have deterministic pass/fail semantics; - return nonzero on failure; - require no credentials; - write no state outside normal test/cache paths. Also define an allowed changed-file set for the first demo. Prefer: ```text src/kernel_demo/slug.py ``` The first demo should fail verification if the candidate modifies unrelated source, test, configuration or governance files. Tests are controller-owned acceptance evidence. The coding Runtime must not be authorized to rewrite `tests/test_slug.py` to make itself pass. ## Initial repository state The starting `develop` branch must: - clone cleanly; - install successfully; - have the intended failing tests because `normalize_slug` is incomplete; - have no unrelated test failures; - contain no uncommitted/generated artifacts; - have a known exact base commit recorded in this issue. Record: - repository canonical URL; - exact initial `develop` SHA; - Python version; - dependency/install command; - verification command; - expected failing tests before implementation. ## Workspace authority For this first demo, the coding Runtime may modify only the disposable checked-out worktree. It must not receive authority to: - modify the Kernel repository; - modify the demo repository's tests; - alter `.git` configuration; - push directly; - merge; - deploy; - access parent directories; - access owner credentials; - access arbitrary network destinations. The controller owns candidate collection, verification and Forge delivery. Trusted-development limitations must be stated honestly. Do not claim hostile-code isolation unless a real sandbox proves it. ## Forge behavior The successful later D1 demo will: 1. start from the frozen `develop` base; 2. let the Runtime produce a candidate; 3. verify the exact candidate; 4. accept only the verified subject; 5. create one Forgejo PR targeting `develop` through Kernel's existing Forge/AGit boundary; 6. never merge it automatically. D1-01 does not need to make that live PR yet. It prepares the repository and exact conditions required for it. ## Repeatability The scenario must be easy to reset. Document the minimum owner action needed to return the demo repository to the frozen initial state after a successful demo. Prefer a clean branch/base-reset procedure over scripts with hidden state. Do not require deleting Kernel's durable evidence merely to reset the demo repository. ## UX baseline Record what a human would currently need to do manually to execute this scenario using today's Kernel APIs. This is baseline evidence for D1. Do not fix the UX in this issue. The purpose is to identify which manual steps D1-02 must remove. ## Reuse-first Before adding scaffolding or helper code, inspect whether an existing minimal repository mechanism can be reused. Do not import a large template/framework merely to create this tiny demo. ## Deliverables This issue is complete when: 1. `Creatidy/kernel-demo` exists on Forgejo. 2. Its initial `develop` state is frozen and revision-pinned. 3. The coding task is written down exactly. 4. The test suite discriminates incomplete vs correct behavior. 5. Allowed changed files are explicit. 6. Verification command is frozen. 7. Trust/credential/workspace assumptions are explicit. 8. Reset procedure is documented. 9. Current manual Kernel setup steps are recorded as D1-02 input. 10. No Kernel implementation has been changed. ## Validation Run the demo repository's own installation and test commands. Demonstrate: - expected failing baseline caused only by the intentionally incomplete function; - a temporary known-good implementation makes all checks pass; - restore the repository to the intentionally incomplete baseline before closing this issue. Do not leave the solution committed on `develop`. ## Completion Record the final evidence on this issue. No Creatidy Kernel PR is expected from D1-01 unless investigation discovers that repository-side preparation genuinely belongs there. Do not begin D1-02 automatically.

kilo commented

2026-09-28 12:24:05 +00:00

Member

D1-01 evidence — synthetic demo plan superseded; real-backlog candidate scan

Parent program: #30

Supersession record

Owner decision (2026-09-28, interactive session): the synthetic Creatidy/kernel-demo repository approach is superseded. The first Kernel dogfood demo must perform a real useful task from one of the owner's existing repositories so the model work has value even if the demo exposes Kernel failures. kernel-demo must NOT be created.

Factual history of the aborted original path:

Forgejo MCP (user kilo) could not create repositories in the Creatidy org: "Given user is not allowed to create repository in organization" — an owner-only infrastructure step.
The owner was asked and chose the scope change instead. No Creatidy/kernel-demo exists; nothing was pushed; the unused local scratch workspace was deleted.
No creatidy-kernel file changed: develop working tree clean throughout (HEAD 49af0c4).
The issue-dependency API link to #30 returned 404; the parent link already exists in the issue body.

Scan scope and method

Canonical Forgejo open issues + open PRs inspected for: BioMedical-IT/ollama-monitoring, DemandTrace/creatidy, DemandTrace/creatidy-api, DemandTrace/creatidy-batch, DemandTrace/creatidy-frontend, DemandTrace/creatidy-ops, BioMedical-IT/scarcity-router, BioMedical-IT/trace-ct, BioMedical-IT/imaging-evidence-path — with implementation-status verification against develop file content where decisive.

Key finding: many "open" issues are already implemented on `develop`

Verification evidence (checked 2026-09-28):

scarcity-router #148 — implemented by merged PR #149 (D-057, merged 2026-09-28).
creatidy-batch #177 — apps/contract_wins/observability.py on develop already contains OUTCOME_SOURCE_INCOMPLETE and build_source_incomplete_signal (docstrings cite #177).
creatidy-ops #97 — scripts/prefect_observability.py on develop already contains AUTOMATION_NAME_SOURCE_INCOMPLETE and _source_incomplete_automation.
creatidy-batch #169 — Makefile db-check.* targets already use $(PY) -m scripts.db_check with the exact rationale comment.
creatidy-api #69 — app/learning/ (store + routes) and tests/test_learning_routes.py exist.
creatidy-api #67 — per-item approve/reject/mark-no-safe-match/reopen supplier-mapping endpoints already exist; the issue is largely superseded.
ollama-monitoring — zero open issues; no candidates possible from the highest-preference repository.

Consequence: issue state alone cannot select a dogfood task; develop content must be checked. This is relevant input for D1-02+ task selection and for any automated candidate-selection UX.

Shortlist (2 candidates; marginal candidates rejected aggressively)

1. PREFERRED — BioMedical-IT/scarcity-router #143

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

Genuinely useful: de-flakes the Scarcity Router full gate; open PRs #149/#152/#155 each hit this flake during full-suite runs — it is actively costing review reliability today.
Expected files/subsystem: tests/test_e2e_execution.py only; the racy drain loop is still present on develop in both scenario-11 tests (verified in source).
Verification command: make check (full deterministic suite, 2100+ tests) plus repeated runs of CancellationTests (the issue documents 8/8 isolation passes vs full-suite failures under load).
External dependencies/blockers: none; fully offline synthetic loopback harness; no credentials; no GPU; no live service; finishes in minutes. Unclaimed — no open PR targets #143.
Why safe enough: test-only change; the issue's non-goals forbid weakening the assertion (cancel propagation to the exact owning worker remains the property under test); no product behavior change; a bad candidate is trivially discardable. Suitable for one implementation attempt plus one bounded remediation.
Complexity: SMALL.
Honest caveat: proving a de-flake is partly statistical; deterministic acceptance = the prescribed wait-on-cancel-event refactor replaces the EOF-inference race, the scenario property is unchanged, and repeated class/full-suite runs pass.

2. BACKUP (caveated) — DemandTrace/creatidy-api #66

"[Public API][Later] Expose bounded public run history for What Changed"

Genuinely useful: required by the public What Changed workflow; creatidy-api currently has zero open PRs (unclaimed).
Expected files/subsystem: app/api/routes.py, response models, cohort sanitizer, tests.
Verification command: make check (offline deterministic test suite).
External dependencies/blockers: none hard; dependency #83 is integrated (per #94 links).
Why only backup: it touches the public/private sanitizer boundary — a sensitive surface for a first dogfood without proven isolation — and leaves contract design latitude (bounded snapshots vs sanitized change summary) that adds acceptance ambiguity.
Complexity: MEDIUM.

Rejected (with reasons)

SR #154/#155 (Z.ai campaign policy — routing policy change, already covered by open PR #155), #136/#152 (covered by open PR), #150 (audit program, not bounded code).
creatidy-batch #155 (currency-aware features): requires a governed FX-source/provenance decision — owner/data-governance judgment, not ordinary SWE.
creatidy-batch #137 (S3 endpoint sync): acceptance requires SOPS age key, encrypted-env regeneration, and live PRD MinIO reachability — credentials + live external service.
creatidy-batch #173/#174/#135: in-flight branches by others and live upstream API semantics (conflict/correctness risk).
creatidy-ops #67: one-line env-example digest — too trivial to exercise the coding runtime; protected Learning subsystem.
creatidy-frontend #66/#69/#75/#76/#79/#80/#81/#94/#95 and PRD children #86/#87: manual/Playwright-dependent acceptance or live-API verification.
creatidy-api #73 (security-critical auth), #90 (LARGE read-model rework), #67 (already implemented); creatidy-batch #122/#124/#166/#167 (deployment/DB-privilege/scale); creatidy-ops #95 (implementation already on branch).
trace-ct PUB-02 (network-dependent acceptance: pip-audit advisory DB, gitleaks install), PUB-03/04/05 (scientific/licence/release judgment); imaging-evidence-path #100/#188/#201/#235 (book-build toolchain-heavy verification, release gates).
DemandTrace/creatidy #44 (docs-only, weak deterministic verification), #13 (blocked on unfinished foundation), #31 (LARGE governance), #17 (master tracker).

Final recommendation

Freeze BioMedical-IT/scarcity-router #143 as the first Kernel dogfood task, pending owner approval. No suitable candidate existed in the higher-preference repositories: ollama-monitoring has an empty backlog, and every suitable DemandTrace-repo task found was either already implemented on develop or failed the offline/credential/deterministic-acceptance constraints.

Confirmations

Creatidy/kernel-demo was not created; no repository, branch, PR, or issue was created or modified in any target repository.
No creatidy-kernel implementation changed; no Scarcity Router policy modified; nothing was implemented; no live model call was made.

## D1-01 evidence — synthetic demo plan superseded; real-backlog candidate scan Parent program: #30 ### Supersession record **Owner decision (2026-09-28, interactive session):** the synthetic `Creatidy/kernel-demo` repository approach is superseded. The first Kernel dogfood demo must perform a real useful task from one of the owner's existing repositories so the model work has value even if the demo exposes Kernel failures. `kernel-demo` must NOT be created. Factual history of the aborted original path: - Forgejo MCP (user `kilo`) could not create repositories in the `Creatidy` org: "Given user is not allowed to create repository in organization" — an owner-only infrastructure step. - The owner was asked and chose the scope change instead. No `Creatidy/kernel-demo` exists; nothing was pushed; the unused local scratch workspace was deleted. - No `creatidy-kernel` file changed: `develop` working tree clean throughout (HEAD `49af0c4`). - The issue-dependency API link to #30 returned 404; the parent link already exists in the issue body. ### Scan scope and method Canonical Forgejo open issues + open PRs inspected for: `BioMedical-IT/ollama-monitoring`, `DemandTrace/creatidy`, `DemandTrace/creatidy-api`, `DemandTrace/creatidy-batch`, `DemandTrace/creatidy-frontend`, `DemandTrace/creatidy-ops`, `BioMedical-IT/scarcity-router`, `BioMedical-IT/trace-ct`, `BioMedical-IT/imaging-evidence-path` — with implementation-status verification against `develop` file content where decisive. ### Key finding: many "open" issues are already implemented on `develop` Verification evidence (checked 2026-09-28): - scarcity-router #148 — implemented by merged PR #149 (D-057, merged 2026-09-28). - creatidy-batch #177 — `apps/contract_wins/observability.py` on `develop` already contains `OUTCOME_SOURCE_INCOMPLETE` and `build_source_incomplete_signal` (docstrings cite #177). - creatidy-ops #97 — `scripts/prefect_observability.py` on `develop` already contains `AUTOMATION_NAME_SOURCE_INCOMPLETE` and `_source_incomplete_automation`. - creatidy-batch #169 — Makefile `db-check.*` targets already use `$(PY) -m scripts.db_check` with the exact rationale comment. - creatidy-api #69 — `app/learning/` (store + routes) and `tests/test_learning_routes.py` exist. - creatidy-api #67 — per-item approve/reject/mark-no-safe-match/reopen supplier-mapping endpoints already exist; the issue is largely superseded. - ollama-monitoring — zero open issues; no candidates possible from the highest-preference repository. Consequence: issue state alone cannot select a dogfood task; `develop` content must be checked. This is relevant input for D1-02+ task selection and for any automated candidate-selection UX. ### Shortlist (2 candidates; marginal candidates rejected aggressively) #### 1. PREFERRED — BioMedical-IT/scarcity-router #143 "Flaky under load: test_scenario_11 client-disconnect cancel can assert before the cancel reaches the worker reader" - **Genuinely useful:** de-flakes the Scarcity Router full gate; open PRs #149/#152/#155 each hit this flake during full-suite runs — it is actively costing review reliability today. - **Expected files/subsystem:** `tests/test_e2e_execution.py` only; the racy drain loop is still present on `develop` in both scenario-11 tests (verified in source). - **Verification command:** `make check` (full deterministic suite, 2100+ tests) plus repeated runs of `CancellationTests` (the issue documents 8/8 isolation passes vs full-suite failures under load). - **External dependencies/blockers:** none; fully offline synthetic loopback harness; no credentials; no GPU; no live service; finishes in minutes. Unclaimed — no open PR targets #143. - **Why safe enough:** test-only change; the issue's non-goals forbid weakening the assertion (cancel propagation to the exact owning worker remains the property under test); no product behavior change; a bad candidate is trivially discardable. Suitable for one implementation attempt plus one bounded remediation. - **Complexity:** SMALL. - **Honest caveat:** proving a de-flake is partly statistical; deterministic acceptance = the prescribed wait-on-cancel-event refactor replaces the EOF-inference race, the scenario property is unchanged, and repeated class/full-suite runs pass. #### 2. BACKUP (caveated) — DemandTrace/creatidy-api #66 "[Public API][Later] Expose bounded public run history for What Changed" - **Genuinely useful:** required by the public What Changed workflow; creatidy-api currently has zero open PRs (unclaimed). - **Expected files/subsystem:** `app/api/routes.py`, response models, cohort sanitizer, tests. - **Verification command:** `make check` (offline deterministic test suite). - **External dependencies/blockers:** none hard; dependency #83 is integrated (per #94 links). - **Why only backup:** it touches the public/private sanitizer boundary — a sensitive surface for a first dogfood without proven isolation — and leaves contract design latitude (bounded snapshots vs sanitized change summary) that adds acceptance ambiguity. - **Complexity:** MEDIUM. ### Rejected (with reasons) - SR #154/#155 (Z.ai campaign policy — routing policy change, already covered by open PR #155), #136/#152 (covered by open PR), #150 (audit program, not bounded code). - creatidy-batch #155 (currency-aware features): requires a governed FX-source/provenance decision — owner/data-governance judgment, not ordinary SWE. - creatidy-batch #137 (S3 endpoint sync): acceptance requires SOPS age key, encrypted-env regeneration, and live PRD MinIO reachability — credentials + live external service. - creatidy-batch #173/#174/#135: in-flight branches by others and live upstream API semantics (conflict/correctness risk). - creatidy-ops #67: one-line env-example digest — too trivial to exercise the coding runtime; protected Learning subsystem. - creatidy-frontend #66/#69/#75/#76/#79/#80/#81/#94/#95 and PRD children #86/#87: manual/Playwright-dependent acceptance or live-API verification. - creatidy-api #73 (security-critical auth), #90 (LARGE read-model rework), #67 (already implemented); creatidy-batch #122/#124/#166/#167 (deployment/DB-privilege/scale); creatidy-ops #95 (implementation already on branch). - trace-ct PUB-02 (network-dependent acceptance: pip-audit advisory DB, gitleaks install), PUB-03/04/05 (scientific/licence/release judgment); imaging-evidence-path #100/#188/#201/#235 (book-build toolchain-heavy verification, release gates). - DemandTrace/creatidy #44 (docs-only, weak deterministic verification), #13 (blocked on unfinished foundation), #31 (LARGE governance), #17 (master tracker). ### Final recommendation Freeze **BioMedical-IT/scarcity-router #143** as the first Kernel dogfood task, pending owner approval. No suitable candidate existed in the higher-preference repositories: ollama-monitoring has an empty backlog, and every suitable DemandTrace-repo task found was either already implemented on `develop` or failed the offline/credential/deterministic-acceptance constraints. ### Confirmations - `Creatidy/kernel-demo` was not created; no repository, branch, PR, or issue was created or modified in any target repository. - No `creatidy-kernel` implementation changed; no Scarcity Router policy modified; nothing was implemented; no live model call was made.

kilo commented

2026-09-28 12:38:35 +00:00

Member

D1-01 frozen real-task contract — OWNER APPROVED

Parent program: #30. Scan evidence and the supersession record for the original synthetic kernel-demo plan: see comment above. The synthetic plan was superseded by explicit owner decision; kernel-demo was never created.

Owner decision (2026-09-28, interactive session): BioMedical-IT/scarcity-router #143 is approved as the first Creatidy Kernel dogfood task. It is NOT implemented by D1-01; this comment freezes the scenario only.

Frozen base (re-read immediately before freezing, 2026-09-28)

Canonical repository: https://forgejo.creatidy.com/BioMedical-IT/scarcity-router
Frozen base: develop @ 781bace66cec4f91b952cbe1993a3524be90fb63 (merge of PR #155, 2026-09-28T12:30:06Z)
Issue #143 state at freeze: open, no linked PR (last updated 2026-09-28T12:31:49Z)
Active-PR check: the only open PR is #152 (targets #136). No open or merged PR implements #143.
Source verified at the exact frozen SHA (not just issue state): the racy mechanism is present.

Exact relevant tests (`tests/test_e2e_execution.py`, class `CancellationTests`)

test_scenario_11_client_disconnect_propagates_cancel
test_scenario_11_cancel_reaches_exactly_the_owning_worker

Current racy mechanism (verified at `781bace`)

After the client half-closes (SHUT_WR), both tests drain the response socket:

deadline = time.monotonic() + 15
while time.monotonic() < deadline and not worker.cancels:
    try:
        piece = raw.recv(4096)  # drain; may EOF or time out
        if not piece:
            break  # the server closed its side after cancelling
    except (TimeoutError, OSError):
        continue
self.assertTrue(worker.cancels, "cancel never reached the worker")

Under load, the server's FIN can be observed (EOF → break) before the worker reader thread records the cancel, so the assertion races cancel delivery against FIN observation; the 15 s deadline cannot protect it. Historical manifestation: full-suite make check failures (~2 of ~7 runs) while the class passes 8/8 in isolation.

Dogfood execution boundary

Implementation change limited to exactly: tests/test_e2e_execution.py. No production code unless a later owner decision explicitly expands scope.

Acceptance invariants (a candidate MUST NOT)

delete or weaken the cancellation assertion;
add skip/xfail;
catch and ignore the failure;
reduce scenario coverage;
reduce repeat counts merely to hide the race;
replace synchronization with an arbitrary large sleep;
remove the worker-ownership requirement (bystander.cancels == []);
change production code.

The semantic assertion that cancellation reaches exactly the owning worker must remain. The expected repair class: deterministic bounded synchronization around the cancel-delivery event (wait on the worker reader's cancel-received event, or a bounded post-EOF grace poll of worker.cancels), replacing the racy EOF/drain observation order.

Frozen verification plan (finite, recorded)

Targeted: uv run python -m unittest tests.test_e2e_execution.CancellationTests -v
Repeated targeted: exactly 8 consecutive runs of command 1 (matches the issue's own isolation-loop evidence)
Full gate: make check — one run (= uv run python tools/test_runner.py + uv run basedpyright per the repository Makefile; the full-suite environment is where the race historically manifested)
Controller-side diff inspection proving the acceptance invariant was not weakened.

Statistical repeated success is supporting evidence only. The primary correctness argument is structural: the race-producing observation order is replaced by deterministic synchronization. No additional stress testing is required or authorized.

Controller-owned acceptance — explicit D1-02 input

Because the implementation target is itself a test file, passing the edited test is not sufficient acceptance evidence. D1-02 must preserve an independent controller-side acceptance check over the candidate diff that rejects at minimum:

skipped/xfail tests;
removed relevant assertions;
materially relaxed cancellation semantics;
unrelated file changes.

Confirmations

Scarcity Router was not modified; no branch or PR was created for #143; creatidy-kernel unchanged; D1-02 not started; no coding model dispatched.

D1-01 deliverables are complete; closing this issue as completed.

## D1-01 frozen real-task contract — OWNER APPROVED Parent program: #30. Scan evidence and the supersession record for the original synthetic `kernel-demo` plan: see [comment above](https://forgejo.creatidy.com/Creatidy/creatidy-kernel/issues/31#issuecomment-12693). The synthetic plan was superseded by explicit owner decision; `kernel-demo` was never created. **Owner decision (2026-09-28, interactive session):** `BioMedical-IT/scarcity-router` #143 is approved as the first Creatidy Kernel dogfood task. It is NOT implemented by D1-01; this comment freezes the scenario only. ### Frozen base (re-read immediately before freezing, 2026-09-28) - Canonical repository: `https://forgejo.creatidy.com/BioMedical-IT/scarcity-router` - Frozen base: `develop` @ **`781bace66cec4f91b952cbe1993a3524be90fb63`** (merge of PR #155, 2026-09-28T12:30:06Z) - Issue #143 state at freeze: **open**, no linked PR (last updated 2026-09-28T12:31:49Z) - Active-PR check: the only open PR is #152 (targets #136). **No open or merged PR implements #143.** - Source verified at the exact frozen SHA (not just issue state): the racy mechanism is present. ### Exact relevant tests (`tests/test_e2e_execution.py`, class `CancellationTests`) 1. `test_scenario_11_client_disconnect_propagates_cancel` 2. `test_scenario_11_cancel_reaches_exactly_the_owning_worker` ### Current racy mechanism (verified at `781bace`) After the client half-closes (`SHUT_WR`), both tests drain the response socket: ```python deadline = time.monotonic() + 15 while time.monotonic() < deadline and not worker.cancels: try: piece = raw.recv(4096) # drain; may EOF or time out if not piece: break # the server closed its side after cancelling except (TimeoutError, OSError): continue self.assertTrue(worker.cancels, "cancel never reached the worker") ``` Under load, the server's FIN can be observed (EOF → `break`) before the worker reader thread records the cancel, so the assertion races cancel *delivery* against FIN *observation*; the 15 s deadline cannot protect it. Historical manifestation: full-suite `make check` failures (~2 of ~7 runs) while the class passes 8/8 in isolation. ### Dogfood execution boundary Implementation change limited to exactly: **`tests/test_e2e_execution.py`**. No production code unless a later owner decision explicitly expands scope. ### Acceptance invariants (a candidate MUST NOT) - delete or weaken the cancellation assertion; - add `skip`/`xfail`; - catch and ignore the failure; - reduce scenario coverage; - reduce repeat counts merely to hide the race; - replace synchronization with an arbitrary large sleep; - remove the worker-ownership requirement (`bystander.cancels == []`); - change production code. The semantic assertion that cancellation reaches exactly the owning worker must remain. The expected repair class: deterministic bounded synchronization around the cancel-delivery event (wait on the worker reader's cancel-received event, or a bounded post-EOF grace poll of `worker.cancels`), replacing the racy EOF/drain observation order. ### Frozen verification plan (finite, recorded) 1. Targeted: `uv run python -m unittest tests.test_e2e_execution.CancellationTests -v` 2. Repeated targeted: **exactly 8** consecutive runs of command 1 (matches the issue's own isolation-loop evidence) 3. Full gate: `make check` — one run (= `uv run python tools/test_runner.py` + `uv run basedpyright` per the repository Makefile; the full-suite environment is where the race historically manifested) 4. Controller-side diff inspection proving the acceptance invariant was not weakened. Statistical repeated success is supporting evidence only. The primary correctness argument is structural: the race-producing observation order is replaced by deterministic synchronization. No additional stress testing is required or authorized. ### Controller-owned acceptance — explicit D1-02 input Because the implementation target is itself a test file, passing the edited test is **not** sufficient acceptance evidence. D1-02 must preserve an independent controller-side acceptance check over the candidate diff that rejects at minimum: - skipped/xfail tests; - removed relevant assertions; - materially relaxed cancellation semantics; - unrelated file changes. ### Confirmations - Scarcity Router was not modified; no branch or PR was created for #143; `creatidy-kernel` unchanged; D1-02 not started; no coding model dispatched. D1-01 deliverables are complete; closing this issue as completed.

adrian.tkacz closed this issue

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

adrian.tkacz referenced this issue

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

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

kilo referenced this issue

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

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