Skip to content

Instantly share code, notes, and snippets.

@konovalov-nk

konovalov-nk/plan.md

Last active June 23, 2026 03:37
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save konovalov-nk/38570de24300cbe1e5cd675160c76e2b to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save konovalov-nk/38570de24300cbe1e5cd675160c76e2b to your computer and use it in GitHub Desktop.
Download ZIP
Plan for tomorrow.md
Raw
plan.md

TODO.md — Coherence Bootstrap Demos + Agent Onboarding Surface

TOC

Goal

Create a clean public onboarding path for Coherence.

coherence-bootstrap remains the engine/tooling repository.

A new repository, usecoherence/coherence-bootstrap-demos, becomes the demo/onboarding surface where humans and agents can see how Coherence is supposed to work on real projects.

The core demo should show this workflow:

vague user intent
  -> agent inspects repo/spec/task state
  -> agent proposes specs + AC changelist
  -> human reviews in TUI / DSL
  -> agent implements one local task
  -> agent produces evidence linked to spec/AC

This is dogfooding. The demo repository must contain its own .coherence/ specs, acceptance criteria, and intent graph.

1. New repository: usecoherence/coherence-bootstrap-demos

Intent

Create a separate repository for demos.

This repo is not the engine. It is the onboarding surface.

It should contain:

  • demo projects
  • seed specs
  • expected outputs
  • agent instructions
  • prompts
  • llms.txt
  • its own .coherence/ graph describing the intent of the demo repo itself

Proposed structure

coherence-bootstrap-demos/
  .coherence/
    specs.jsonl

  README.md
  llms.txt

  demos/
    xrun-probe/
      README.md
      AGENTS.md
      prompt.md
      expected/
        specs.jsonl
        tree.txt
      seed/
        .coherence/
          specs.jsonl

    url-shortener/
      README.md
      AGENTS.md
      prompt.md
      expected/
        specs.jsonl
        tree.txt
      seed/
        .coherence/
          specs.jsonl

Repository-level .coherence/

The demos repo must describe itself using Coherence.

Minimum specs:

Product
  coherence-bootstrap-demos
    - provides runnable demos for agents and humans
    - demonstrates intent -> spec -> AC -> code/evidence workflow

System
  demo-layout
    - each demo has README, AGENTS.md, prompt.md, expected output, seed specs

System
  llms-onboarding
    - llms.txt gives compressed instructions for agents

System
  dogfood-specs
    - the demo repository tracks its own intent using .coherence/specs.jsonl

First demos

xrun-probe

Purpose:

Show Coherence working on a real, non-trivial, low-level Linux/audio problem.

User requirement example:

Let's write a tool that detects XRUNs and prints them somewhere so we can track them and link them to applications/nodes that didn't have time to process packets in the pipeline.

Expected high-level spec tree:

Product
  alsa-xrun-probe
  correlator-engine
  deployment-packaging
  output-storage
  pipewire-node-monitor

Foundation
  event-schema
  interception-mechanism
  pw-snapshot-api

url-shortener

Purpose:

Show Coherence on a small, familiar web app.

User requirement example:

Build a URL shortener.
It should accept long URLs, generate short slugs, redirect users, reject invalid URLs, and persist mappings.

Expected spec examples:

Product
  url-shortener

System
  redirect-flow
  url-creation-flow

Foundation
  domain-model-url
  slug-generation
  url-validation

2. llms.txt content

Create llms.txt in coherence-bootstrap-demos.

This file is the compressed manual for agents.

It should be short enough for agents to read quickly, but complete enough to explain the core model.

Required content

What Coherence is

Coherence is a developer-native intent traceability layer.

It connects:

why -> what -> constraints -> code -> evidence

Coherence is not a replacement for code, tests, docs, issue trackers, or architecture tools.

It is the missing layer between ambiguous requirements and executable implementation.

It helps humans and agents keep product/system intent close to the codebase.

Core concepts

Spec
  An intended outcome / future system state.
  Example: "Payment API requires authenticated client."

Acceptance Criterion / AC
  A granular piece of intent that can be reviewed, verified, or tested.
  Example: "Unauthenticated payment requests are rejected."

Evidence
  A concrete artifact proving that an AC still holds.
  Example: test result, code link, log output, generated report.

Intent graph
  The graph of specs, ACs, constraints, code links, and evidence.

Table architecture

Coherence currently stores intent as structured rows.

Minimum tables/concepts:

specs
  id
  slug
  title
  level
  status
  description

acceptance_criteria
  id
  spec_id
  slug
  title
  intent
  risk
  review_mode

spec_relations
  from_spec_id
  to_spec_id
  relation_type

acceptance_criterion_concerns
  ac_id
  concern

code_links / evidence links
  ac_id or spec_id
  link_type
  target

The current portable format is JSONL:

.coherence/specs.jsonl

Dolt DB is the current backing database during bootstrap.

Later, Coherence may support a local embedded mode.

How tables relate to code

Specs and ACs do not replace code.

They explain why code exists, what it claims to satisfy, and what evidence proves it.

Example:

Spec:
  Payment API

AC:
  Requires authenticated client

Code link:
  implemented_by backend/payment.rb

Evidence:
  verified_by test/features/payment_auth_test.rb

CLI examples

Preferred short binary name:

cohb doctor
cohb tui
cohb db import-jsonl .coherence/specs.jsonl
cohb db export-jsonl .coherence/specs.jsonl
cohb spec add
cohb ac add
cohb verify-spec
cohb verify-ac

The full binary may remain:

coherence-bootstrap

But demos should prefer:

cohb

3. What an intent graph is

Definition

An intent graph is a graph of intended system states and the reasons, constraints, code links, and evidence behind them.

It is not just a knowledge graph for docs.

A knowledge graph can say what is known.

An intent graph says what the system is supposed to become, why, and how we prove the implementation still matches that intent.

Shape:

knowledge -> intent -> code/evidence

Example:

PCI DSS is knowledge.
API contract shape is knowledge.
Polish tax rules are knowledge.

backend/payment.rb is code.

Intent is the chosen synthesis:
  - payment requires authenticated client
  - anonymous payment is not allowed
  - API rejects unauthenticated requests
  - test proves this behavior still holds

Granular intent

Granular intent is the smallest useful unit of system intent that can be reviewed and verified.

Example:

Spec:
  URL model

AC:
  URL contains id, short, original, updated_at

The AC is small enough that a human can understand what needs to be true.

It is also small enough that code or tests can produce evidence for it.

Why AC links to spec

A spec names the outcome.

An AC names one piece of intent required for that outcome to hold.

Spec/outcome:
  URL shortener persists URLs

AC/intent:
  URL has id, short, original, updated_at
  URL rejects invalid original URL
  URL creates unique short slug

The spec gives context.

The AC gives verifiable intent.

Why spec links to spec

Specs can depend on, constrain, refine, or support other specs.

Example relations:

depends_on
  Payment API depends_on Authentication

constrained_by
  Payment API constrained_by PCI DSS compliance

refines
  Public API refines Product requirement

implemented_by
  Product behavior implemented_by module/component spec

verified_by
  Spec verified_by test/evidence spec

Spec-to-spec links allow the graph to explain why a change matters.

If Authentication changes, Payment API may be affected.

If PCI DSS constraints change, Payment API may need review.

Minimum viable context

Minimum viable context means: provide only enough context for a human or agent to understand and verify a piece of intent.

Not too little:

"add field"

Not too much:

1000 lines of unrelated specs, docs, and historical decisions

Good:

Spec:
  URL model

AC:
  URL contains id, short, original, updated_at

Relevant code:
  app/models/url.rb
  db/schema.rb

Relevant evidence:
  test/models/url_test.rb

The goal is to optimize for understanding.

A changelist should be small enough to review, but meaningful enough to represent a real intentional update.

4. How agents should work

Important note

There is no full Coherence workflow engine yet.

For now, the workflow is described as protocol and convention.

Future work may integrate with workflow engines. Sayiir is a useful reference because it is Rust-based and MIT licensed:

https://docs.sayiir.dev/

Do not block on workflow engine integration.

For now, implement the workflow manually in agent instructions and CLI/TUI behavior.

Assumptions

Before starting, assume:

- repository exists
- git exists
- task management may exist, likely beads
- Dolt DB may be installed and running
- .coherence/specs.jsonl may or may not exist
- agent may be Claude Code, Codex, opencode, etc.

Agent workflow

Step 1: Receive unstructured requirements

User may say something vague:

Build a URL shortener.

or:

Write a tool to detect ALSA XRUNs and correlate them with PipeWire nodes.

Do not jump straight into code.

First, inspect state.

Step 2: Inspect repository state

Agent must check:

- Does code already exist?
- Is git clean?
- Are there active tasks?
- Are there existing specs?
- Is .coherence/specs.jsonl present?
- Is Dolt installed?
- Is Dolt SQL server running?
- Is the project database initialized?
- Are specs synced between DB and JSONL?

Purpose:

Figure out what mode we are in.

Step 3: Determine mode

Possible modes:

new-plan
  Clean repo, no active task, new requirements arrived.

continue-task
  Active task exists and repo state matches that task.

dirty-repo
  Repo has uncommitted changes and no clear active task.

review-changelist
  Specs/ACs changed and need human review.

idle
  No task, no plan, no new requirement.

Step 4: Act based on mode

new-plan

Agent should:

1. inspect existing specs
2. infer missing specs/ACs from requirement
3. propose a changelist
4. ask human to review
5. wait for approval before coding

continue-task

Agent should:

1. inspect active task
2. inspect linked spec/AC
3. implement one local deliverable
4. show diff/evidence
5. ask human whether result matches intent

dirty-repo

Agent should not blindly continue.

Agent should explain:

- what changed
- whether changes match an active task
- whether specs/evidence are out of sync
- what needs confirmation

Then ask the user what to do.

review-changelist

Agent should show:

- specs added
- specs changed
- specs removed
- ACs added
- ACs changed
- ACs removed
- affected code/evidence links

Human can approve, edit, reset, or cancel.

idle

Agent should ask:

What should we work on next?

5. Planning mode

Planning mode handles new requirements.

Requirements may come from:

- user prompt
- previous evidence
- bug report
- comments
- code review feedback
- product feedback
- failing tests

Agent should produce a changelist, not code.

Changelist rules

A changelist should be:

- small enough for a human to review
- meaningful enough to represent real intent
- local to the relevant specs/ACs
- connected to expected evidence

Avoid giant changelists.

If DSL view becomes 1000+ lines, the intent is probably low-cohesion.

Split into smaller intentional updates.

Task creation after approval

When human approves a changelist, create tasks.

Each task must have deliverables that are understandable at the same level as the spec/AC.

Good task deliverables:

- code that adds the API endpoint
- test that verifies the AC
- evidence output from verify command
- updated spec/AC link

Bad task deliverables:

- perform SQL update
- modify internal table X
- refactor random utility

The problem with bad deliverables is that the human has to mentally descend from product intent into foundation mechanics.

Keep task locality close to the spec/AC.

6. Coding mode

Coding mode means there is an approved plan and an active task.

Agent should:

1. read the linked spec/AC
2. inspect relevant code
3. implement one local deliverable
4. run tests/checks
5. produce evidence
6. show diff and evidence to human
7. ask whether the result matches intent

Do not silently expand scope.

If implementation reveals missing intent, stop and propose a spec/AC changelist.

7. Syncing specs with code

Current source-of-truth flow:

Dolt DB <-> .coherence/specs.jsonl

For now, JSONL export is the portable repo artifact:

.coherence/specs.jsonl

Required commands:

cohb db import-jsonl .coherence/specs.jsonl
cohb db export-jsonl .coherence/specs.jsonl

There is no strict CI/CD enforcement yet.

Future integration can run:

cohb verify

from:

- GitHub Actions
- local pre-commit hooks
- workflow engines
- agent workflows

Draft vs active specs

Draft specs should not block verification.

draft = skip hard verify
active = expect evidence/test
deprecated = ignore unless referenced
archived = historical

Once a spec becomes active, it should have linked evidence.

8. Tests as materialized intent

The tests created through this process are the most important layer.

They force the human and agent to ask:

Does the system actually work the way we said it should?

This is the core of Coherence:

optimize for understanding

Minimal-context tests

Tests should be small, focused, and explain the intent.

Example AC:

slug:
  domain/model/url

intent:
  URL should contain fields id, short, original, updated_at

A good test makes clear:

1. where the model is stored
2. where the model code is
3. what fields matter
4. how the intent is verified

Example minimal-context evidence:

Spec:
  URL model

AC:
  URL contains id, short, original, updated_at

Code:
  app/models/url.rb
  db/schema.rb

Test:
  test/models/url_test.rb

Assertion:
  URL schema includes id, short, original, updated_at

The “why” belongs in the AC.

The test should focus on proving the AC.

9. Installation and packaging

Do not use install.sh.

Preferred path:

cargo install coherence-bootstrap

Expected binary:

cohb

Required smoke commands:

cohb doctor
cohb tui
cohb db import-jsonl .coherence/specs.jsonl
cohb db export-jsonl .coherence/specs.jsonl
cohb verify-spec
cohb verify-ac

Long binary may remain available:

coherence-bootstrap

But public docs and demos should prefer:

cohb

Required doctor behavior

cohb doctor should describe project state.

It must detect:

- git present/missing
- git clean/dirty
- dolt installed/missing
- dolt sql-server running/not running
- project DB exists/missing
- .coherence/specs.jsonl exists/missing
- specs imported/exported/synced/unknown
- current Coherence profile

Required init behavior

cohb init should set up a project-scoped Coherence DB inside user-scoped Dolt DB.

Failure modes to handle:

1. Dolt is not installed
2. Dolt SQL server is not running
3. Project DB does not exist
4. .coherence/ does not exist
5. .coherence/specs.jsonl exists but DB is empty
6. DB exists but JSONL is missing
7. DB and JSONL are out of sync

Do not hide failure.

Explain the state and the next command.

10. CLI cleanup

Current coherence-bootstrap help shows too many internal commands.

Default help should show only the main user/agent surface.

Default commands

cohb init
cohb doctor
cohb tui
cohb spec
cohb ac
cohb verify
cohb db import-jsonl
cohb db export-jsonl
cohb help

Extra/internal commands

Hide internal/debug/bootstrap commands by default.

Show them only with:

cohb help --all

or:

COHERENCE_DISPLAY_EXTRA_COMMANDS=1 cohb help

Internal examples:

m0-smoke
m1-spec-smoke
drop-isolated-test-db
evidence-sample
db-list-databases
db-ping

Goal:

New users and agents should not see bootstrap internals first.

11. TUI for humans

The TUI needs two primary modes and one editing plane.

normal mode
  browse existing intent graph

changelist mode
  browse proposed/selected intent diff

DSL view
  edit/review selected slice in $EDITOR

Normal mode

Default mode.

Purpose:

Browse all specs/ACs via tree view.

Actions:

- expand/collapse specs
- view spec detail
- view AC detail
- mark spec/AC as changelist candidate
- open DSL view for selected slice
- later: search graph quickly via fzf/fff-like interaction

Changelist mode

Purpose:

Review only selected/changed specs and ACs.

Actions:

- show filtered specs/ACs
- mark existing spec/AC for deletion
- add new spec
- add new AC
- remove new spec/AC from changelist
- reset changelist
- approve changelist
- export changelist

Important semantics:

A changelist is ephemeral until committed/synced.

For new items, “remove from changelist” means remove the proposed item.

For existing items, “mark for deletion” means the changelist proposes deletion.

Think of it like editing code under git:

uncommitted changes can be reset
approved changes can be committed
committed changes can be reverted later

DSL view

Purpose:

Fastest editing/review plane.

Open selected slice in $EDITOR.

Editor fallback order:

$EDITOR
micro
nvim
vim
nano

DSL view should pull only relevant context:

- relevant specs
- relevant ACs
- relevant links
- relevant code/evidence references

Do not dump the whole graph.

The point is to optimize for understanding.

A good changelist is:

small enough to review
large enough to be meaningful
local to the intent being changed

If DSL becomes huge, this is a signal:

- requirement is too broad
- product intent is low-cohesion
- feature should be split
- graph slice is too large

12. Beads task format

Use beads for task tracking where available.

The agent may translate this section into actual beads commands.

Each task must include:

type:
  epic | task

repo:
  target repository

title:
  human-readable title

description:
  what needs to happen and why

deliverables:
  concrete artifacts expected when complete

acceptance:
  how to know the task is done

13. Beads tasks

Epic 1 — Create coherence-bootstrap-demos repo

repo:

usecoherence/coherence-bootstrap-demos

type:

epic

title:

Create Coherence Bootstrap Demos onboarding repository

description:

Create a separate public repository for Coherence demos. The bootstrap repository remains engine/tooling. The demos repository becomes the onboarding surface for agents and humans.

deliverables:

- new GitHub repository usecoherence/coherence-bootstrap-demos
- README.md explaining purpose
- llms.txt compressed agent manual
- demos/ directory
- .coherence/specs.jsonl for dogfooding the demo repo itself

acceptance:

- repo exists
- README explains engine vs demo split
- .coherence/specs.jsonl exists
- at least one demo directory exists

Task 1.1 — Add repository skeleton

repo:

usecoherence/coherence-bootstrap-demos

type:

task

title:

Add initial repository skeleton

description:

Create the initial directory layout for demos, expected outputs, seed specs, and repository-level Coherence dogfooding.

deliverables:

- README.md
- llms.txt placeholder
- .coherence/specs.jsonl placeholder
- demos/xrun-probe/
- demos/url-shortener/

acceptance:

- tree matches proposed structure
- empty directories contain placeholder files where needed

Task 1.2 — Add xrun-probe demo

repo:

usecoherence/coherence-bootstrap-demos

type:

task

title:

Add ALSA XRUN Probe demo

description:

Create a real-world low-level demo showing how an agent turns vague XRUN tracking requirements into specs, ACs, and expected evidence.

deliverables:

- demos/xrun-probe/README.md
- demos/xrun-probe/AGENTS.md
- demos/xrun-probe/prompt.md
- demos/xrun-probe/expected/specs.jsonl
- demos/xrun-probe/expected/tree.txt
- demos/xrun-probe/seed/.coherence/specs.jsonl

acceptance:

- demo can be understood without reading the whole website
- expected tree includes product and foundation specs
- AGENTS.md tells agent not to code before proposing specs/ACs

Task 1.3 — Add url-shortener demo

repo:

usecoherence/coherence-bootstrap-demos

type:

task

title:

Add URL Shortener demo

description:

Create a small familiar web-app demo showing how Coherence handles product intent, model intent, validation, persistence, redirect behavior, and evidence.

deliverables:

- demos/url-shortener/README.md
- demos/url-shortener/AGENTS.md
- demos/url-shortener/prompt.md
- demos/url-shortener/expected/specs.jsonl
- demos/url-shortener/expected/tree.txt
- demos/url-shortener/seed/.coherence/specs.jsonl

acceptance:

- demo explains intended behavior clearly
- expected specs include URL model, slug generation, URL validation, redirect flow
- ACs are granular enough to materialize tests

Epic 2 — Package coherence-bootstrap for cargo install

repo:

usecoherence/coherence-bootstrap

type:

epic

title:

Publish coherence-bootstrap installable CLI

description:

Make the current bootstrap artifact installable via Cargo. No install.sh. Public demos should use cargo install and the cohb binary.

deliverables:

- cargo package metadata cleaned up
- cargo install coherence-bootstrap works
- cohb binary works
- smoke commands documented

acceptance:

- cargo install path works locally
- cohb doctor runs after install
- cohb tui runs after install

Task 2.1 — Add cohb binary alias

repo:

usecoherence/coherence-bootstrap

type:

task

title:

Add cohb binary alias

description:

Keep coherence-bootstrap as the full binary name, but expose cohb as the preferred short command for demos and docs.

deliverables:

- Cargo.toml binary alias
- docs updated to use cohb
- old coherence-bootstrap entrypoint still works

acceptance:

- cohb help works
- coherence-bootstrap help works

Task 2.2 — Implement project-aware cohb doctor

repo:

usecoherence/coherence-bootstrap

type:

task

title:

Implement project-aware doctor command

description:

cohb doctor should explain the current Coherence project state and failure modes clearly.

deliverables:

- detect git present/missing
- detect git clean/dirty
- detect Dolt installed/missing
- detect Dolt SQL server running/not running
- detect project DB exists/missing
- detect .coherence/specs.jsonl exists/missing
- detect sync state where possible

acceptance:

- doctor output is readable by humans
- doctor output is actionable for agents
- failure modes include next suggested command

Task 2.3 — Implement project init DB flow

repo:

usecoherence/coherence-bootstrap

type:

task

title:

Implement project-scoped init flow

description:

cohb init should set up project-scoped Coherence state using the user-scoped Dolt SQL server.

deliverables:

- create .coherence/ if missing
- create/import project DB if missing
- handle existing specs.jsonl
- explain Dolt missing/not running states

acceptance:

- new repo can run cohb init
- existing repo with specs.jsonl can run cohb init
- missing Dolt gives clear error
- stopped Dolt server gives clear error

Epic 3 — Simplify CLI surface

repo:

usecoherence/coherence-bootstrap

type:

epic

title:

Simplify public CLI help surface

description:

Current help exposes too many bootstrap/debug commands. Make default help show the main user/agent workflow only. Hide extra commands behind help --all or COHERENCE_DISPLAY_EXTRA_COMMANDS=1.

deliverables:

- default help is short
- internal commands hidden
- help --all shows everything
- env var can expose extra commands

acceptance:

- new user sees only core commands
- developer can still access bootstrap/debug commands

Task 3.1 — Define public command groups

repo:

usecoherence/coherence-bootstrap

type:

task

title:

Define public CLI command groups

description:

Group commands into public workflow commands and internal/debug commands.

deliverables:

- public command list
- internal command list
- help output design

acceptance:

- command grouping is documented
- current commands are classified

Task 3.2 — Implement help --all / extra commands flag

repo:

usecoherence/coherence-bootstrap

type:

task

title:

Hide internal commands by default

description:

Default help should show only core commands. Internal commands should appear only with help --all or COHERENCE_DISPLAY_EXTRA_COMMANDS=1.

deliverables:

- help --all support
- env var support
- updated help text

acceptance:

- cohb help is short
- cohb help --all shows full command list
- COHERENCE_DISPLAY_EXTRA_COMMANDS=1 cohb help shows full command list

Epic 4 — TUI human review modes

repo:

usecoherence/coherence-bootstrap

type:

epic

title:

Add TUI modes for normal browsing and changelist review

description:

The TUI should support human browsing of the full intent graph and focused review of proposed changelists. DSL view should open the selected graph slice in the user's editor.

deliverables:

- normal mode
- changelist mode
- DSL editor view
- mark spec/AC as changelist candidate
- filtered tree view for changelist

acceptance:

- user can browse full graph
- user can mark items for changelist
- user can review only changelist items
- user can open relevant DSL slice in editor

Task 4.1 — Add normal mode changelist candidate marking

repo:

usecoherence/coherence-bootstrap

type:

task

title:

Allow marking specs and ACs as changelist candidates

description:

In normal TUI mode, allow the human to browse the graph and mark relevant specs/ACs for a future changelist.

deliverables:

- keybinding to mark/unmark spec
- keybinding to mark/unmark AC
- visual marker for selected candidates

acceptance:

- user can mark multiple specs/ACs
- marks persist while TUI session is open
- detail pane shows candidate state

Task 4.2 — Add changelist mode filtered tree

repo:

usecoherence/coherence-bootstrap

type:

task

title:

Add changelist filtered tree mode

description:

Show only specs/ACs included in the current changelist candidate set.

deliverables:

- changelist mode toggle
- filtered tree rendering
- empty-state message when no candidates selected

acceptance:

- changelist mode hides unrelated specs/ACs
- normal mode still shows full graph

Task 4.3 — Add DSL editor view for selected graph slice

repo:

usecoherence/coherence-bootstrap

type:

task

title:

Open selected graph slice as DSL in editor

description:

Allow user to open the selected spec/AC slice as editable DSL in $EDITOR. This is the fastest plane for review and editing.

deliverables:

- generate DSL for selected slice
- open in $EDITOR
- fallback to micro/nvim/vim/nano
- parse edited DSL back into changelist or DB draft

acceptance:

- editor opens with relevant DSL only
- unrelated graph content is not dumped
- edited DSL can be parsed or produces useful errors

Task 4.4 — Define changelist reset/remove/delete semantics

repo:

usecoherence/coherence-bootstrap

type:

task

title:

Define changelist mutation semantics

description:

Clarify how new, changed, and existing specs/ACs behave inside an ephemeral changelist.

deliverables:

- semantics doc
- remove new item behavior
- mark existing item for deletion behavior
- reset changelist behavior

acceptance:

- user can understand difference between remove-from-changelist and mark-for-deletion
- behavior mirrors git-like uncommitted change semantics

14. Execution order

Recommended order:

1. Create coherence-bootstrap-demos repo skeleton
2. Add llms.txt compressed manual
3. Add xrun-probe demo
4. Add url-shortener demo
5. Add cohb binary alias
6. Fix cohb doctor
7. Fix cohb init DB flow
8. Simplify help output
9. Add TUI normal/changelist mode
10. Add DSL editor slice view

Do not block demo repo on perfect TUI.

The first public win is:

cargo install coherence-bootstrap
git clone coherence-bootstrap-demos
cd demos/xrun-probe
cohb doctor
cohb db import-jsonl seed/.coherence/specs.jsonl
cohb tui

That is enough to show the idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment