Creatidy/creatidy-kernel

Fork 0

D1 — Make Creatidy Kernel visibly useful: first real repository demo #30

New issue

Open

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

adrian.tkacz commented

2026-09-28 12:03:19 +00:00

Owner

Mission

Turn the completed K1–K8 foundation into the first visibly useful Creatidy Kernel demonstration.

The program must prove a narrow real user outcome:

An owner starts one bounded software-engineering task against a controlled real repository; Kernel allocates intelligence through Scarcity Router, executes the work through an existing Runtime, verifies the resulting code independently, recovers safely from controller interruption, and opens a real Forgejo pull request without merging or deploying it.

This is a dogfooding program.

Its purpose is to expose missing product behavior, bad UX, incorrect abstractions and operational friction through real use. It is not authorization to build a general autonomous software-engineering platform.

Starting point

The first foundation program is complete:

K1 → K2A → K2B → K3 → K4 → K5 → K6 → K7 → K8.

Current capabilities include:

immutable Program intent and authority;
durable SQLite history and external-effect journal;
immutable Attempts and durable Allocation;
replaceable ResourceAllocator;
optional Scarcity Router allocation through its public recommendation contract;
exact provider/model/reasoning-effort propagation;
bounded Codex Runtime adapter;
candidate collection;
deterministic verification and acceptance;
explicit successor inputs;
restart/recovery semantics;
Forgejo AGit PR creation without merge/deploy;
reference CLI and evidence export.

The current public CLI still primarily exposes a synthetic offline reference. The live Codex/Forgejo composition exists as a library integration and still requires substantial manual setup.

D1 closes that product gap through one deliberately narrow real demo.

Demo target

The initial demo uses a small owner-controlled disposable repository created specifically for Kernel dogfooding.

It MUST contain real source code and deterministic tests.

The task must require an actual code change, for example:

Implement a small missing Python function according to existing tests and repository instructions.

The exact task/repository fixture will be frozen in a child issue before execution.

Do not begin with an arbitrary issue from a production repository.

Desired owner experience

The target UX is approximately:

creatidy-kernel demo \
  --repo <controlled-demo-repository> \
  --task <approved-demo-task> \
  --approve

The exact command is not frozen yet.

The owner should not need to:

call Python library APIs manually;
create Git objects manually;
edit SQLite;
construct Runtime/Forge objects in Python;
inspect internal operation records to know what happened.

A successful run should make major lifecycle facts understandable:

Program admitted;
Allocation chosen;
exact runtime configuration requested/resolved;
work started/completed;
verification results;
acceptance or rejection;
recovery state when applicable;
PR creation;
explicit statement that no merge/deployment occurred.

Evidence may remain available in structured form separately.

End-state acceptance

D1 is complete only when one controlled real-repository scenario demonstrates all of the following:

One supported user-facing command starts or resumes the demo.
A real Scarcity Router recommendation selects the Allocation.
A real supported model/runtime performs the coding work.
The runtime modifies real repository code, not a synthetic result.txt artifact.
Controller-owned deterministic checks run against the resulting code.
Only a verified exact candidate may become accepted Program state.
The accepted result of one WorkUnit can be an explicit successor input where the scenario requires it.
Restart/recovery is demonstrated across at least two meaningful durable boundaries without duplicate external work.
A real Forgejo pull request is created through the existing Forge boundary.
Kernel never automatically merges or deploys.
Router policy is not copied into Kernel.
Runtime/Forge/verification authority boundaries remain intact.
Owner-visible status and failure output is understandable without reading raw ledger JSON.
The full scenario is bounded in attempts, wall-clock behavior and external effects.
Every product/UX defect discovered during dogfooding is either fixed within the selected child issue or recorded as an explicit follow-up.

Development rule

Build the thinnest real vertical slice first.

Do not pre-design a general Program engine.

Do not generalize a mechanism merely because future use might need it. A generalization should be justified by repeated concrete pressure from the demo or another proven workflow.

Prefer exposing an existing K1–K8 mechanism through a usable composition over adding a new abstraction.

Initial expected work areas

These are planning areas, not pre-authorized implementation issues:

freeze the disposable demo repository and task contract;
compose existing ResourceAllocator + Runtime + verification + Forge into a supported runnable entry point;
allow the Runtime to work on a real controlled repository/worktree;
execute deterministic repository checks as verification evidence;
introduce the smallest bounded remediation path if the real demo proves it necessary;
provide owner-usable status/inspect/recovery UX.

Child issues should be created incrementally from real evidence. Do not create a large speculative issue tree upfront.

Explicit non-goals

D1 does NOT authorize:

arbitrary autonomous issue-to-PR operation on production repositories;
a generic workflow DSL;
generic multi-agent orchestration;
unbounded remediation loops;
arbitrary shell authority;
autonomous merge;
deployment;
release automation;
repository-wide unsupervised refactors;
a new coding-agent harness;
replacing Codex/Kilo/etc.;
moving Scarcity Router routing policy into Kernel;
a web UI;
multi-user SaaS;
cloud control plane;
hostile-code isolation claims not backed by a real sandbox.

Governance

Forgejo is canonical.

branch from develop;
target develop;
one selected issue / branch / PR;
main remains human-controlled;
no automatic merge or deployment;
exact reviewed HEAD required before owner merge;
independent review remains mandatory;
reuse-first applies before greenfield implementation;
existing proven operational properties must be preserved unless the selected issue explicitly changes them.

This parent issue is a coordination record.

Do not implement D1 directly from this parent. Select and deliver one child issue at a time.

First child

The first child should define and prove the smallest real demo contract:

D1-01 — Freeze first real repository demo scenario

It should establish the disposable repository, exact coding task, deterministic acceptance checks, permitted workspace effects, credentials/trust assumptions, bounded owner approval and concrete end-to-end success condition before new runtime/product behavior is implemented.

## Mission Turn the completed K1–K8 foundation into the first visibly useful Creatidy Kernel demonstration. The program must prove a narrow real user outcome: > An owner starts one bounded software-engineering task against a controlled real repository; Kernel allocates intelligence through Scarcity Router, executes the work through an existing Runtime, verifies the resulting code independently, recovers safely from controller interruption, and opens a real Forgejo pull request without merging or deploying it. This is a dogfooding program. Its purpose is to expose missing product behavior, bad UX, incorrect abstractions and operational friction through real use. It is not authorization to build a general autonomous software-engineering platform. ## Starting point The first foundation program is complete: K1 → K2A → K2B → K3 → K4 → K5 → K6 → K7 → K8. Current capabilities include: - immutable Program intent and authority; - durable SQLite history and external-effect journal; - immutable Attempts and durable Allocation; - replaceable ResourceAllocator; - optional Scarcity Router allocation through its public recommendation contract; - exact provider/model/reasoning-effort propagation; - bounded Codex Runtime adapter; - candidate collection; - deterministic verification and acceptance; - explicit successor inputs; - restart/recovery semantics; - Forgejo AGit PR creation without merge/deploy; - reference CLI and evidence export. The current public CLI still primarily exposes a synthetic offline reference. The live Codex/Forgejo composition exists as a library integration and still requires substantial manual setup. D1 closes that product gap through one deliberately narrow real demo. ## Demo target The initial demo uses a small owner-controlled disposable repository created specifically for Kernel dogfooding. It MUST contain real source code and deterministic tests. The task must require an actual code change, for example: > Implement a small missing Python function according to existing tests and repository instructions. The exact task/repository fixture will be frozen in a child issue before execution. Do not begin with an arbitrary issue from a production repository. ## Desired owner experience The target UX is approximately: ```text creatidy-kernel demo \ --repo <controlled-demo-repository> \ --task <approved-demo-task> \ --approve ``` The exact command is not frozen yet. The owner should not need to: - call Python library APIs manually; - create Git objects manually; - edit SQLite; - construct Runtime/Forge objects in Python; - inspect internal operation records to know what happened. A successful run should make major lifecycle facts understandable: - Program admitted; - Allocation chosen; - exact runtime configuration requested/resolved; - work started/completed; - verification results; - acceptance or rejection; - recovery state when applicable; - PR creation; - explicit statement that no merge/deployment occurred. Evidence may remain available in structured form separately. ## End-state acceptance D1 is complete only when one controlled real-repository scenario demonstrates all of the following: 1. One supported user-facing command starts or resumes the demo. 2. A real Scarcity Router recommendation selects the Allocation. 3. A real supported model/runtime performs the coding work. 4. The runtime modifies real repository code, not a synthetic `result.txt` artifact. 5. Controller-owned deterministic checks run against the resulting code. 6. Only a verified exact candidate may become accepted Program state. 7. The accepted result of one WorkUnit can be an explicit successor input where the scenario requires it. 8. Restart/recovery is demonstrated across at least two meaningful durable boundaries without duplicate external work. 9. A real Forgejo pull request is created through the existing Forge boundary. 10. Kernel never automatically merges or deploys. 11. Router policy is not copied into Kernel. 12. Runtime/Forge/verification authority boundaries remain intact. 13. Owner-visible status and failure output is understandable without reading raw ledger JSON. 14. The full scenario is bounded in attempts, wall-clock behavior and external effects. 15. Every product/UX defect discovered during dogfooding is either fixed within the selected child issue or recorded as an explicit follow-up. ## Development rule Build the thinnest real vertical slice first. Do not pre-design a general Program engine. Do not generalize a mechanism merely because future use might need it. A generalization should be justified by repeated concrete pressure from the demo or another proven workflow. Prefer exposing an existing K1–K8 mechanism through a usable composition over adding a new abstraction. ## Initial expected work areas These are planning areas, not pre-authorized implementation issues: - freeze the disposable demo repository and task contract; - compose existing ResourceAllocator + Runtime + verification + Forge into a supported runnable entry point; - allow the Runtime to work on a real controlled repository/worktree; - execute deterministic repository checks as verification evidence; - introduce the smallest bounded remediation path if the real demo proves it necessary; - provide owner-usable status/inspect/recovery UX. Child issues should be created incrementally from real evidence. Do not create a large speculative issue tree upfront. ## Explicit non-goals D1 does NOT authorize: - arbitrary autonomous issue-to-PR operation on production repositories; - a generic workflow DSL; - generic multi-agent orchestration; - unbounded remediation loops; - arbitrary shell authority; - autonomous merge; - deployment; - release automation; - repository-wide unsupervised refactors; - a new coding-agent harness; - replacing Codex/Kilo/etc.; - moving Scarcity Router routing policy into Kernel; - a web UI; - multi-user SaaS; - cloud control plane; - hostile-code isolation claims not backed by a real sandbox. ## Governance Forgejo is canonical. - branch from `develop`; - target `develop`; - one selected issue / branch / PR; - `main` remains human-controlled; - no automatic merge or deployment; - exact reviewed HEAD required before owner merge; - independent review remains mandatory; - reuse-first applies before greenfield implementation; - existing proven operational properties must be preserved unless the selected issue explicitly changes them. This parent issue is a coordination record. Do not implement D1 directly from this parent. Select and deliver one child issue at a time. ## First child The first child should define and prove the smallest real demo contract: **D1-01 — Freeze first real repository demo scenario** It should establish the disposable repository, exact coding task, deterministic acceptance checks, permitted workspace effects, credentials/trust assumptions, bounded owner approval and concrete end-to-end success condition before new runtime/product behavior is implemented.

adrian.tkacz referenced this issue

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

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