The external audit (2026-08-16) asked for two things the docs alone cannot give: a real demo and a reproducible example. One artifact can be both — and also solve a real need: the community website.
Proposal: build the CDev community website with CDev itself, and keep it under an examples/ layer of the project (in-repo directory or linked example repositories — decide at planning time). Two services:
frontend — the public community site (docs, walkthrough, releases, contribution guide).backend — a small API the site consumes (e.g. releases feed, community links, field reports index).
Both conditioned with bootstrap / bootstrap-monorepo and developed through the cdev loop, so the repositories accumulate what CDev promises: the plan (SPRINTS.md), the state (AGENT_PROGRESS.md handoffs), and the proof (git history with batch commits).
Why frontend + backend and not a single static page: two coordinated services are the minimum honest demonstration of the multi-repo layer (cdev-monorepo, cdev-monorepo-planner) — CDev building a microservice AND maintaining it across sessions, which is the product's core claim.
Fix shape:
- Decide placement:
examples/ directory in this repo vs. separate cdev-example-* repositories linked from an examples/README.md here.
- Condition both services with the shipped templates (no hand-written plan files — the bootstrap must produce them).
- Run real sprints through the loop: initial build, then at least one maintenance sprint in a later session that continues purely from repository state (the handoff, not conversational memory).
- Deploy the site; link it from the README.
- The example doubles as the raw material for the demo GIF the audit requested (install → bootstrap → run → close session → continue).
Verify: both services exist with template-derived SPRINTS.md and newest-first AGENT_PROGRESS.md; git history shows batch commits before/after a session boundary; the site is reachable and documents the community; scripts/validate.sh stays green; a reader can replay the conditioning from the walkthrough alone.
The external audit (2026-08-16) asked for two things the docs alone cannot give: a real demo and a reproducible example. One artifact can be both — and also solve a real need: the community website.
Proposal: build the CDev community website with CDev itself, and keep it under an
examples/layer of the project (in-repo directory or linked example repositories — decide at planning time). Two services:frontend— the public community site (docs, walkthrough, releases, contribution guide).backend— a small API the site consumes (e.g. releases feed, community links, field reports index).Both conditioned with
bootstrap/bootstrap-monorepoand developed through thecdevloop, so the repositories accumulate what CDev promises: the plan (SPRINTS.md), the state (AGENT_PROGRESS.mdhandoffs), and the proof (git history with batch commits).Why frontend + backend and not a single static page: two coordinated services are the minimum honest demonstration of the multi-repo layer (
cdev-monorepo,cdev-monorepo-planner) — CDev building a microservice AND maintaining it across sessions, which is the product's core claim.Fix shape:
examples/directory in this repo vs. separatecdev-example-*repositories linked from anexamples/README.mdhere.Verify: both services exist with template-derived
SPRINTS.mdand newest-firstAGENT_PROGRESS.md; git history shows batch commits before/after a session boundary; the site is reachable and documents the community;scripts/validate.shstays green; a reader can replay the conditioning from the walkthrough alone.