Context Circuit CLI 2.6.0

Context Circuit CLI 2.6.0

A minor release. The workspace schema stays at 3, and nothing is renumbered.

Upgrade notes

Nothing to do unless you use extensions: a workspace without extensions.yaml behaves as before. An extension's scripts run only after each member allows them on their own machine with extension allow --id ID, and an override changes nothing until a person allows it with extension override. (#235, #236, #238)

Run agent setup after pulling a workspace whose extensions add roles or skills, and add the new x-* skill paths from the template's .gitignore. (#237, #239)

Added

Agents now write intents, plans, approval and completion notes, and the chat around them from one new skill, cc-writing, so they open with the point, connect their ideas, and in Bahasa Indonesia compose rather than translate. Each member can pick a tone with member tone --preset colleague, casual, formal, or non-technical, and member presets lists them with the line each records. A member with no tone is written for as colleague. A tone never reaches context/ notes, the catalog, or the glossary, which stay English. Existing workspaces need no migration, and a tone you already wrote keeps working. (#228)

Type /ff to bring your local base branches up to date: the agent fast-forwards every bound repository and the workspace, or only the ones you name (/ff api, /ff workspace), and reports what moved and what it left alone and why. The workspace is skipped when it holds any uncommitted file, and the code repositories are still updated. When you tell the agent your merge or pull request was merged, it now offers in one reply to update those repositories' base branches and to mark the delivered plans completed; one yes does both, and saying "merged" alone changes nothing. In Codex, ask in words instead of typing /ff. (#231)

repo sync and workspace sync bring this machine's base branches up to date after a merge. repo sync fetches, then fast-forwards the base branch of each repository you name with --id, or of every bound one, and reports one status per repository: updated, current, ahead, diverged, blocked by uncommitted changes, checked out in another worktree, or why nothing moved: no local base branch, no remote or upstream, not bound here, or a failed fetch. It never switches the branch you have checked out, and never merges, rebases, resets, stashes, or discards. workspace sync does the same for the workspace's own repository, but only when it has no uncommitted file at all; once it moves, it says to run check and names a pinned CLI version that moved with it. (#231)

Workspaces can now use extensions: folders of instructions that add work before and after each stage — writing an intent, approval, planning, preparing a worktree, implementing, review, delivery, completion, and archiving — for the whole workspace or for chosen repositories, without changing the template. List them in extensions.yaml with extension add, from a folder in the workspace or a Git repository pinned to the commit its tag or branch names; each member can switch one off unless its author made it required. The agent runs extension hooks at the stages it carries out, record approve, worktree prepare, record complete, and record archive return the instructions for their own stage, and dispatched planners, workers, and reviewers receive theirs in their brief. Every hook that does not apply is reported with its reason, and no extension can authorize a push, a merge, or anything else that needs your say. status counts the extensions on for you and check validates them. (#235)

Extensions can now run scripts at their hook points, not only give the agent instructions. A script runs only after you ran extension allow --id ID on your machine for that exact version — the commit of a remote extension, or the contents of a folder in the workspace — and any change to it asks again; allow shows each script, what happens when it fails, and what it does beyond your machine, and runs nothing. extension list shows whether each extension is allowed, not allowed, or changed since you allowed it. Each hook declares whether a failure stops the stage or is only reported, and whether it needs your consent: standing scripts take the one action their manifest names once you have allowed them, and each-time scripts wait for your yes every time. record approve, worktree prepare, record complete, and record archive run their own stage's scripts without holding the workspace lock, and a failing before script with on_failure: stop leaves the command undone. On Windows a hook runs its run_windows command, and a hook without one is skipped there. (#236)

Extensions can now add agent roles and add to the shipped ones. A manifest's roles declare a role with its description, read-only or edit access, the stages it serves, the shipped role it is like for model and effort, its instructions, and the headings it returns. agent setup installs each role of an extension on for you beside the shipped four, as cc-x-<extension>-<role>, and agent dispatch --role x-<extension>-<role> briefs it like a shipped role, with limits no instruction lifts. role_additions add instructions and return headings to the explorer, planner, worker, or reviewer through their brief, without changing their definition or access. After an extension change, extension add, update, remove, enable, disable, sync, and status return setup_required until agent setup runs again; setup removes a definition whose extension is gone or off unless you edited it, and its result now lists the files written, removed, and kept. check reports a role or addition that is not valid, and two extensions adding the same heading to one role. (#237)

status now lists, under each of your open plans in my_work, the worktrees this machine prepared for it: the repository, the worktree's path, and its branch. A plan's branch lives in the repository the plan names, not in the workspace's own, so this tells an agent where to look for a plan's work. (#237)

An extension can now ask to change one of four core defaults, and a person can allow it for their workspace: repair-loop (implement, verify, and fix until clean or a round limit), verify-during-execution (a read-only role checks each implementation once), risk-review (the reviewer runs when the extension's instructions say a change warrants it), and delegation (a stage always goes to a named role). A manifest declares the overrides it wants under overrides, and extension override --id ID --allow NAME [--rounds N] allows one, or --revoke NAME takes it back; --rounds can lower a repair loop's limit but never raise it. An allowed override comes back from extension hooks under overrides, status lists each one and whether it is on for you, and agent dispatch --override NAME [--round N] accepts the verifier, the fixing worker, or the reviewer it needs and refuses any other use. Approving an intent, authorizing pushes and merges, starting planning and execution, leaving the plan record alone, no attribution, no secrets, and read-only borrowed knowledge stay fixed: a manifest naming any of them is invalid. check reports an allowance the manifest does not declare, rounds out of range, a verifier that is not read-only, and two extensions delegating one stage to different roles. .context-circuit/docs/customization.md describes the overrides and the repair loop. (#238)

Extensions can now ship skills. A manifest's skills names each skill's folder, which holds a SKILL.md with name and description, and agent setup installs each skill of an extension on for you as x-<extension>-<skill>: a copy under .agents/skills/, which Codex reads, and a one-line wrapper under .claude/skills/ and .cursor/skills/. These are gitignored and regenerated on each machine, never replace a shipped skill, and are never touched by a template update; setup keeps a copy you edited and removes one whose extension is gone or off. A skill runs on your request, or when a core hook instruction names it, never on its own. A skill may declare a named stage, which other extensions hook as before|after <extension>/<stage> and the skill runs with extension hooks --stage <extension>/<stage>; a stage whose extension is not listed or is off for you is skipped with that reason, and named stages never join the core lifecycle. status lists extension_skills and named_stages, extension list names each extension's skills and stages, and check reports a skill that is not valid and a hook at a named stage no listed extension declares. (#239)

Changed

An approval or completion note is now written in the record's language, English unless the author's member entry says otherwise, and states the decision: what was approved, the answers to open questions, conditions, and extra asks. It no longer pastes the person's reply, which may be in the language of the conversation. The conversation itself is unchanged: replies, approval confirmations, and summaries stay in the language the person is using. (#226)

Contributors

@hallode, @kaotypr

---

Built at commit 1720ba41f54f9993db50e90d0df3d7bd83e41b86.

Apache-2.0; the archive carries the license. The workspace template is 0BSD.

Context Circuit CLI 2.5.0

Context Circuit CLI 2.5.0

A minor release. The workspace schema stays at 3, and nothing is renumbered.

Upgrade notes

A workspace on schema 2 is refused changes by a 2.5.0 CLI unless it runs the pinned CLI. Upgrade the template first, then let the pinned CLI make the split; one person on a team makes the split, commits and pushes it, and everyone else pulls before changing anything. (#179)

Every member installs CLI 2.5.0 before pulling a workspace whose archive/ was renamed to _archive/, because a 2.4.x CLI does not read _archive/. One person runs the first changing command, commits and pushes the moved records, and everyone else pulls before changing anything. (#209)

Scripts that relied on record list listing every record pass --all. (#209)

Added

scripts/release-version.sh <cli|template> prints the version a product builds and publishes as, and every release script now asks it. A public checkout prints CLI_VERSION or VERSION unchanged; a downstream builder sets a label in CC_VERSION_SUFFIX and a counter in release/variant.env and gets <base>-<label>.<counter>. (#172)

A stable version installs as context-circuit-cli, as before. A variant version, X.Y.Z-<label>.<N>, installs as <label>-context-circuit-cli, so it never shares a command with the public one; both keep their versions in the same store. Both installers take CONTEXT_CIRCUIT_BIN_DIR as their default command directory, and the launcher reads it too, so set it when installing with --bin-dir. (#176)

A workspace runs its CLI through its launcher, .context-circuit/cli, or .context-circuit/cli.ps1 in Windows PowerShell or cmd, which the 2.5.0 template carries. The launcher runs exactly the version .context-circuit/CLI_VERSION pins from the installers' version store, and refuses, naming the install step, when that version is not installed. When a missing subagent definition needs agent setup, agent dispatch names that command through the launcher in a workspace that carries one, and otherwise under the running CLI's own command name. (#177)

A CLI that is not the pinned version now hands off to it. When the pin is installed in the same version store as the running binary, the CLI prints one note on stderr and runs the pinned binary with the same arguments, setting CC_CLI_SWITCHED_FROM to the version that handed off, so the pinned CLI never hands off again. CC_CLI_VERSION=local keeps the running CLI for one command; any other value is refused and nothing is run. A source build, or a binary outside the version store, never hands off. (#179)

agent setup, and init through it, now turns Claude Code's commit and pull request attribution off for the workspace: it adds "attribution": {"commit": "", "pr": ""} to the gitignored .claude/settings.local.json only when the key is absent, keeps every other key, the file's formatting and any value a person set, and refuses a file that is not one JSON object. Cursor accepts this setting only in a person's own or a team admin's configuration, and Codex has none, so neither gets a file. (#208)

record archive is new. Without --id it moves the active member's finished records, a completed plan or an approved intent whose plans are all completed, under the _archive/ beside them; with repeatable --id it moves exactly the named records, whoever wrote them, and marks any unfinished one. IDs stay reserved, lookup by ID keeps working, inline relative links into and out of the moved records are rewritten, and any other broken link is reported. It returns commit_recommended like approval and completion. record complete returns archive_offer while the active member has finished records not archived. (#209)

Records may sit in one level of group folder under intent/ or plans/, such as plans/alex/<plan folder>/, with _archive/ above or below that group, and every command that reads records finds them there. A group is ordinary file organization and says nothing about who owns a record. Folder names starting with _ are kept for the CLI, and _archive/ is the only one it gives meaning to. check reports a reserved folder name, a folder named like a record holds records, a record file outside the folders records are read from, and a legacy archive folder awaits its rename to _archive/. (#209)

Fixed

check and record dependencies walk each plan's dependencies once, so plans that share ancestors no longer make them exponentially slow. agent dispatch --role worker with neither --plan nor --task is refused rather than launching a worker with nothing to implement, and so is --repo without --plan. init stops before writing anything when README.md is something it cannot read, such as a symlink or a directory. member language, member tone, member roles, and member band change only their own field, so the rest of the entry keeps its comments in members.yaml; clearing a tone or the roles still rewrites the entry. repo remote, workspace remote, and knowledge remote check the URL and the default branch before writing either, so a refused change writes nothing. worktree prepare skips and reports an environment entry that cannot be reused by design, such as node_modules holding an npm link, instead of failing, under --copy-mode auto or copy; required still fails on it, off reuses nothing, and any other copy failure still stops preparation. knowledge sync reports unreachable, not diverged, when origin no longer has the default branch. record create --kind intent refuses --intent, --repo, and --depends-on instead of dropping them. (#169)

record order is read-only: it writes nothing and takes no lock. repo fetch changes only Git refs in a bound checkout, so it no longer makes the ID split on a workspace still at schema 2. (#171)

Changed

check, record order, record create, and record dependencies read the records once per command rather than once per lookup, so they do less work in a workspace with many records. Their output is unchanged. (#170)

When no hand-off happens, because the pin is not installed beside the running CLI or the hand-off was skipped, a change is refused, with nothing changed, if it would move the workspace to schema 3, init included, or if the running CLI and the pin are on different release lines. There is no override: CC_CLI_VERSION=local never lifts a refusal. The refusal and the warning name the workspace's launcher when it has one, and either where the pinned CLI is installed or the installer call that installs it, from the registry cli_registry records; a token is named, never printed. Read-only commands, previews such as record delete without --confirm, and other changes on the same release line only warn, as before. (#179)

The archive folder is now _archive/. The first changing command renames an existing top-level intent/archive/ and plans/archive/ to _archive/, keeps every record in it archived and every ID reserved, and reports the move as a notice: on stderr. The schema stays at 3, so a top-level archive/ is a reserved legacy name: it reads as archived and cannot be a group, while an archive/ inside a group is an ordinary folder. (#209)

The commit_recommended note now tells the agent to ask the person whether to commit and push the listed files, or commit only, and carries what to do when that push is refused: pull with rebase, resolve only an ID file conflict by keeping both sides' entries, stop with the rebase in progress for any other conflict, even one where both sides could be kept, and never force-push. It still says nothing was staged, committed or pushed; the CLI never stages, commits, or pushes. (#209)

record list now lists the active member's own records. --member ID lists another member's, and --all every record, including records with no author. With no member selected it lists everything and says so on stderr. status opens with my_work: the active member's intents awaiting approval, approved intents without plans, plans not completed, and unarchived_finished, the count of their finished records not archived. (#209)

Every path the CLI computes for an intent or a plan now goes through one placement unit, internal/workspace/placement.go, with no change in where records go. A downstream build that wants another layout, such as new records under a folder per member, changes that one file rather than path handling across the package. (#209)

Contributors

@kaotypr, @hallode

---

Built at commit d321e06160c8db46f5b923bf8bf15bbe3e06ccca.

Apache-2.0; the archive carries the license. The workspace template is 0BSD.

Context Circuit CLI 2.5.0-rc.1

Context Circuit CLI 2.5.0-rc.1

The first release candidate for 2.5.0, a minor release. The workspace schema
stays at 3, and nothing is renumbered.

Upgrade notes

A workspace on schema 2 is refused changes by a 2.5.0 CLI unless it runs the pinned CLI. Upgrade the template first, then let the pinned CLI make the split; one person on a team makes the split, commits and pushes it, and everyone else pulls before changing anything. (#179)

Every member installs CLI 2.5.0 before pulling a workspace whose archive/ was renamed to _archive/, because a 2.4.x CLI does not read _archive/. One person runs the first changing command, commits and pushes the moved records, and everyone else pulls before changing anything. (#209)

Scripts that relied on record list listing every record pass --all. (#209)

Added

scripts/release-version.sh <cli|template> prints the version a product builds and publishes as, and every release script now asks it. A public checkout prints CLI_VERSION or VERSION unchanged; a downstream builder sets a label in CC_VERSION_SUFFIX and a counter in release/variant.env and gets <base>-<label>.<counter>. (#172)

A stable version installs as context-circuit-cli, as before. A variant version, X.Y.Z-<label>.<N>, installs as <label>-context-circuit-cli, so it never shares a command with the public one; both keep their versions in the same store. Both installers take CONTEXT_CIRCUIT_BIN_DIR as their default command directory, and the launcher reads it too, so set it when installing with --bin-dir. (#176)

A workspace runs its CLI through its launcher, .context-circuit/cli, or .context-circuit/cli.ps1 in Windows PowerShell or cmd, which the 2.5.0 template carries. The launcher runs exactly the version .context-circuit/CLI_VERSION pins from the installers' version store, and refuses, naming the install step, when that version is not installed. When a missing subagent definition needs agent setup, agent dispatch names that command through the launcher in a workspace that carries one, and otherwise under the running CLI's own command name. (#177)

A CLI that is not the pinned version now hands off to it. When the pin is installed in the same version store as the running binary, the CLI prints one note on stderr and runs the pinned binary with the same arguments, setting CC_CLI_SWITCHED_FROM to the version that handed off, so the pinned CLI never hands off again. CC_CLI_VERSION=local keeps the running CLI for one command; any other value is refused and nothing is run. A source build, or a binary outside the version store, never hands off. (#179)

agent setup, and init through it, now turns Claude Code's commit and pull request attribution off for the workspace: it adds "attribution": {"commit": "", "pr": ""} to the gitignored .claude/settings.local.json only when the key is absent, keeps every other key, the file's formatting and any value a person set, and refuses a file that is not one JSON object. Cursor accepts this setting only in a person's own or a team admin's configuration, and Codex has none, so neither gets a file. (#208)

record archive is new. Without --id it moves the active member's finished records, a completed plan or an approved intent whose plans are all completed, under the _archive/ beside them; with repeatable --id it moves exactly the named records, whoever wrote them, and marks any unfinished one. IDs stay reserved, lookup by ID keeps working, inline relative links into and out of the moved records are rewritten, and any other broken link is reported. It returns commit_recommended like approval and completion. record complete returns archive_offer while the active member has finished records not archived. (#209)

Records may sit in one level of group folder under intent/ or plans/, such as plans/alex/<plan folder>/, with _archive/ above or below that group, and every command that reads records finds them there. A group is ordinary file organization and says nothing about who owns a record. Folder names starting with _ are kept for the CLI, and _archive/ is the only one it gives meaning to. check reports a reserved folder name, a folder named like a record holds records, a record file outside the folders records are read from, and a legacy archive folder awaits its rename to _archive/. (#209)

Fixed

check and record dependencies walk each plan's dependencies once, so plans that share ancestors no longer make them exponentially slow. agent dispatch --role worker with neither --plan nor --task is refused rather than launching a worker with nothing to implement, and so is --repo without --plan. init stops before writing anything when README.md is something it cannot read, such as a symlink or a directory. member language, member tone, member roles, and member band change only their own field, so the rest of the entry keeps its comments in members.yaml; clearing a tone or the roles still rewrites the entry. repo remote, workspace remote, and knowledge remote check the URL and the default branch before writing either, so a refused change writes nothing. worktree prepare skips and reports an environment entry that cannot be reused by design, such as node_modules holding an npm link, instead of failing, under --copy-mode auto or copy; required still fails on it, off reuses nothing, and any other copy failure still stops preparation. knowledge sync reports unreachable, not diverged, when origin no longer has the default branch. record create --kind intent refuses --intent, --repo, and --depends-on instead of dropping them. (#169)

record order is read-only: it writes nothing and takes no lock. repo fetch changes only Git refs in a bound checkout, so it no longer makes the ID split on a workspace still at schema 2. (#171)

Changed

check, record order, record create, and record dependencies read the records once per command rather than once per lookup, so they do less work in a workspace with many records. Their output is unchanged. (#170)

When no hand-off happens, because the pin is not installed beside the running CLI or the hand-off was skipped, a change is refused, with nothing changed, if it would move the workspace to schema 3, init included, or if the running CLI and the pin are on different release lines. There is no override: CC_CLI_VERSION=local never lifts a refusal. The refusal and the warning name the workspace's launcher when it has one, and either where the pinned CLI is installed or the installer call that installs it, from the registry cli_registry records; a token is named, never printed. Read-only commands, previews such as record delete without --confirm, and other changes on the same release line only warn, as before. (#179)

The archive folder is now _archive/. The first changing command renames an existing top-level intent/archive/ and plans/archive/ to _archive/, keeps every record in it archived and every ID reserved, and reports the move as a notice: on stderr. The schema stays at 3, so a top-level archive/ is a reserved legacy name: it reads as archived and cannot be a group, while an archive/ inside a group is an ordinary folder. (#209)

The commit_recommended note now tells the agent to ask the person whether to commit and push the listed files, or commit only, and carries what to do when that push is refused: pull with rebase, resolve only an ID file conflict by keeping both sides' entries, stop with the rebase in progress for any other conflict, even one where both sides could be kept, and never force-push. It still says nothing was staged, committed or pushed; the CLI never stages, commits, or pushes. (#209)

record list now lists the active member's own records. --member ID lists another member's, and --all every record, including records with no author. With no member selected it lists everything and says so on stderr. status opens with my_work: the active member's intents awaiting approval, approved intents without plans, plans not completed, and unarchived_finished, the count of their finished records not archived. (#209)

Every path the CLI computes for an intent or a plan now goes through one placement unit, internal/workspace/placement.go, with no change in where records go. A downstream build that wants another layout, such as new records under a folder per member, changes that one file rather than path handling across the package. (#209)

Contributors

@kaotypr, @hallode

---

Built at commit c1f10ae01053a9fda5ba2e4d3fd040e48423c2d3.

Apache-2.0; the archive carries the license. The workspace template is 0BSD.

Context Circuit CLI 2.4.1

Context Circuit CLI 2.4.1

A patch for 2.4.0. The workspace schema stays at 3 and nothing is renumbered;
2.4.0 and 2.4.1 work in the same workspace.

The setup step that completes setup now makes the ID split itself. On a
workspace still at schema 2, the member band that gives the last member a
band, the member add --band that adds the last member, or the member use
that selects one, splits .context-circuit/ids.yaml into per-member files and
prints the split notice right after it succeeds. In 2.4.0 the split waited for
the next changing command and happened there without being asked for. A split
that setup step cannot make, such as one stopped by a member ID that is a
Windows device name, is a warning rather than a failure of the step, and the
next changing command refuses with the reason. The split is still idempotent,
and the one-person-first upgrade from 2.4.0 still holds: that person commits and
pushes the split, everyone else pulls before changing anything, and a conflict
in .context-circuit/ids/*.yaml from teammates who upgraded at the same time is
theirs to resolve by keeping the union of both sides.

The split notice names every shared file the command changed, worked out from
what actually changed: workspace.yaml, each ID file written or removed, and
members.yaml when the command changed it, which member band does. In 2.4.0
it always said workspace.yaml and .context-circuit/, leaving out the roster.

A refused record delete now shows its preview, with --confirm or without,
in YAML and --json: the records asked for with their author, path, and
status; blocked_by, each record outside the selection that still points at one
of them, with its author, path, status, and link, such as
belongs to intent i017; refused, the reason; and, for --id, add_ids, the
IDs to add. The reason is also printed on stderr, nothing is deleted or
released, and the exit status stays 1 so a script still sees the refusal. In
2.4.0 the refusal was an error alone, and a person had to run the command again
to see anything.

--workspace PATH and --json are accepted after the full command as well as
before it, for every command, so status --workspace PATH --json works like
--workspace PATH --json status, and member list --json works too. They still
do not go between a group and its subcommand. No command defines a flag of
either name. A
flag a command does not take is still named, and is now followed by that
command's signature, a line saying where the global flags may go, and the
help topic to read, with exit status 2, instead of an empty Usage of status:
block. --help after a command prints that command's help topic.

worktree prepare reports start, what the worktree actually started from:
--start as given, the base branch or origin/<base> it fell back to, or the
existing branch it checked out or resumed. base_branch keeps meaning this machine's base,
where the work is delivered, which a worktree started elsewhere need not share.
An explicit --start naming a local branch that is behind its remote-tracking
branch, or has diverged from it, is still used as asked, and sync_required
now says how many commits it is behind, and how many ahead when it has
diverged, says to remove the worktree and prepare again with
--start origin/<branch> or to bring the local branch up to date and rebase
the plan branch onto it, and names repo fetch. Preparation still never fetches, so the comparison is only as
recent as the last fetch, the way a stale derived base was already reported.

---

Built at commit 5b1530817a2deb1319745a95e2ea57dd1afcb609.

Apache-2.0; the archive carries the license. The workspace template is 0BSD.

Context Circuit CLI 2.4.0

Context Circuit CLI 2.4.0

Every member of a workspace needs 2.4.0, and one of them goes first. The first
changing command 2.4.0 runs in an existing workspace, once setup is complete,
splits the shared .context-circuit/ids.yaml into one file per member,
.context-circuit/ids/<member>.yaml, and moves workspace.yaml from schema 2 to
schema 3. Each reservation goes to the file of its record's author; one with no
author goes to the member selected on that machine. The split is reported as a
notice and changes no command's result. Older CLIs refuse a schema 3 workspace
with "workspace schema 3 requires a newer CLI; this CLI supports schema 2", so
every member needs 2.4.0 before they pull the split.

Because the split writes every author's file, only one person on a team
upgrades first. That person makes the first changing command, commits the split,
and pushes it. Everyone else pulls before making any change. Teammates who
upgrade at the same time each write the same member files differently, and Git
reports a conflict in .context-circuit/ids/*.yaml. That conflict is theirs to
resolve by hand: keep the union of both sides' entries in each member file, then
run check, which reports any number reserved twice. A command that refuses its
own arguments, such as member add without --band, no longer splits on its way
to the refusal.

A shared ids.yaml that comes back after the split, for example merged in from
a teammate's 2.3.0 clone, is split again by the next changing command, which
adds only the reservations the member files do not already hold. check reports
a number reserved in two member files for a person to fix. Member IDs that are
Windows device names, such as con or nul, are refused, because no clone on
Windows could check out the ID file they name. A 2.3.0 roster may already hold
one: status and check report it, and the split refuses, naming the member or
the author and their records. No command renames a member, so rename it by hand
in members.yaml, every record's created_by, and each machine's
member.local.yaml. A 2.4.0 init starts at schema 3 with the first member's
own ID file.

Every workspace now has a roster, and every member a band. init requires a
member and suggests band 1; the solo workspace with no roster is gone. Band 0 is
a band like any other, i001-i099 and p0001-p0999. Until the roster lists
a member, every member holds a band, and this machine has selected one, every
changing command is refused with a message naming the missing step; init,
member add, member use, member band, and the reading commands still run.
status reports band_required with a suggested band for each member who has
none, and next_band for the next member added. A member whose band 2.3.0
stored as 0 counts as unbanded and is asked to pick one; picking 0 keeps their
old numbering. A 2.3.0 roster hand-edited to give two members band: 0 was
valid there and is now a roster error, because band 0 is a real band and bands
are distinct: status and check report it, and changing commands are refused
until a person moves one of them to another band in members.yaml by hand.

member add now requires --band, and without it the error names the next free
band. member band --band 0 sets band 0 rather than clearing the member's band,
and a band can no longer be cleared. record delete --all works only while the
roster lists exactly one member; otherwise name whose records go with
--member, or which records go with --id. A roster two clones broke is reported by status and check for a
person to fix, and changing commands are refused until it is: a members.yaml
that no longer reads, such as one left with conflict markers, two members on one
band, or a member given two bands.

record delete --id ID deletes the records a person names, and --id is
repeatable. It reaches any intent or plan, active or archived, approved or
completed, written by any member or with no author, and a reserved ID no record
file holds, shown as reservation only; it cannot be combined with --member
or --all, and an ID matching nothing is refused. The preview now shows each
record's status beside its author and path, in every mode. Links between the
named records do not block, and a deleted plan is taken out of its own intent's
plans: list and reported as unlinked; any other link from outside the
selection refuses, and the refusal names the --id values to add. A plan its
intent still lists that no record file holds any more is unlinked the same way.
Leftover local and remote-tracking cc/pNNNN/* branches, worktrees on them, and
a .worktrees/pNNNN directory for a deleted plan number are listed as
warnings in every mode and left alone; a worktree this machine prepared for
the plan still refuses. Released numbers are handed out again, lowest first in
the author's band. The workspace schema does not change; 2.3.0 rejects --id
and deletes nothing.

A confirmed record delete now removes the record files before it releases any
ID: plans before intents, and each plan.md after the rest of its folder.
Stopped part-way, every selected number is still reserved and every partly
removed plan is still a record, and the error names the path and the
record delete --id ... --confirm call, with exactly the IDs still reserved,
that finishes it; after --all it names record delete --all --confirm
instead. A plan folder that has already lost its plan.md is no longer a record,
so the error names it for removal by hand, and check reports it as an empty
plan folder to remove. Stopped while rewriting the ID files, after every record
file is gone, the error names the IDs still reserved and the same call, or says
nothing is left when none is. sync_required also tells every other machine to
pull the deletion, run check, and remove or prune the worktrees it names
before creating plans.

Commands that change one frontmatter field of an existing record now keep a
record written with CRLF line endings in CRLF: record delete taking a plan out
of its intent's plans: list, creating a plan, which adds it to its intent's
list, and record dependencies. record approve and record complete still
rewrite the record they stamp with LF line endings.

worktree prepare no longer resumes a worktree left from an earlier plan that
held the same number. The local association now records the plan's
created_at, and a worktree or branch whose association names a different one,
or, for an association written before 2.4.0 or a bare branch, holds commits made
before the plan record was created, is refused without --reuse; the refusal
names how to remove it. A bare branch is dated from the base branch, or from
origin/<base> when the clone has no local one. A worktree whose association was
written before 2.4.0 and whose branch holds no commit past its start is resumed
only when it has no uncommitted changes and sits at the tip of the base branch,
where a fresh prepare would start, and is refused the same way otherwise.
Preparing again for the plan a worktree was made for resumes it as before.
check names a worktree whose association records a different created_at from
its plan's, and says to remove it and its branch, or to run worktree prune if
Git no longer lists it.

record approve returns planning_recommended instead of planning_required:
approval records a decision, and planning follows a request for it, which may
arrive with the approval.

After it succeeds, record approve checks the intent's file, and
record complete the plan's files and its intent's file, wherever they live,
plus every ID file: the shared .context-circuit/ids.yaml and each per-member
file. When Git reports any of them uncommitted, the result carries
commit_recommended with files, each a path relative to the workspace root
with / separators on every OS and a change of new, modified, or
deleted, and a note saying committing needs the person's authorization. A
renamed record is its new path new and its old path deleted; other
uncommitted records are not listed. Both commands rewrite the record they touch,
so in a Git workspace that record is always listed. When Git is not installed or
the workspace is not in a Git repository, the result carries commit_unchecked
with the reason instead. The check only adds keys: it never blocks or undoes the
command, and the CLI never stages or commits. A workspace inside another
repository is reported relative to its own root. The Git status reader behind
status and repo inspect now reads renames, so changes lists a renamed file
once, as R new/path, rather than also listing its old path with no code.
This implements #144, reported via #141.

A member may carry an optional roles list of free text, set with
member add --role, init --member-role, or member roles, and cleared with
member roles --clear. Each role is one nonempty line, like a member's name,
and a role given twice is kept once. Roles are shown by member list and status and decide
nothing. They are written only at schema 3. A 2.3.0 member list on a roster
with roles fails on the unknown roles field rather than asking for an upgrade,
and check reports roles found in a schema 2 roster.

worktree prune --repo ID drops the plan-to-worktree associations of worktrees
Git no longer lists, and reports them as dropped. It touches no worktree,
branch, or file. When worktree prepare finds a plan's branch checked out in
another working copy, it now names the branch, where it is checked out, whether
that is a known worktree for the plan, and the safe next steps, and changes
nothing. check now points at worktree prune rather than worktree repair
when Git no longer lists a worktree a plan is associated with, and keeps the
repair advice for a checkout that only moved. The record delete refusal for a
plan's worktree names worktree prune too, and so does `...

Context Circuit CLI 2.3.0

Context Circuit CLI 2.3.0

init no longer requires a member. Without --member it creates a solo
workspace with an empty roster: no member is selected on any machine, and
records carry no created_by. Adding the first member makes it a team
workspace, and records written before that stay valid.

In a workspace that lists members, status now reports identity_required
when this machine has selected no member, or names one the roster does not
carry, and record create says how to settle it. Selection is taken as given;
nothing verifies who a person is.

record delete --member ID removes every intent and plan one member created,
active and archived, and releases their IDs so allocation hands those numbers
out again. record delete --all does the same for every record in a solo
workspace and resets the ledger. Without --confirm it previews and deletes
nothing. It refuses while another member's record would be left pointing at a
deleted one, or while a worktree on this machine was prepared for a deleted
plan.

---

Built at commit 71a5fa3ea9c0d852af1956cf2fdb3ece345a6ebf.

Apache-2.0; the archive carries the license. The workspace template is 0BSD.

Context Circuit CLI 2.2.0

Context Circuit CLI 2.2.0

New plans are created as plans/pNNNN-slug/plan.md, with optional supporting
files assigned through required_files. The CLI accepts plans without an intent,
selects exact runs with repeatable record order --plan ID, and briefs workers
with only the details assigned to their repository. Diagnostics report missing,
unsafe, unlinked, and unassigned supporting files. Existing single-file plans
remain readable and editable without migration.

---

Built at commit 43de54779acaca8a66b022160a51858c8343d7da.

Apache-2.0; the archive carries the license. The workspace template is 0BSD.

Context Circuit CLI 2.1.0

Context Circuit CLI 2.1.0

A workspace can now be published from, and install its CLI from, somewhere other
than the public repository.

Install from a chosen registry

The bundled installers accept --source github|gitlab with --repo and
--api (-Source, -Repo, -Api on Windows), or the environment variables
CONTEXT_CIRCUIT_SOURCE, CONTEXT_CIRCUIT_REPO and CONTEXT_CIRCUIT_API.
Passing none of them resolves the public GitHub release exactly as before.

A gitlab registry reads the release through the GitLab API and downloads each
asset from the generic package registry, authenticating with a personal or
project access token. It requires a token: unlike a public GitHub release there
is no anonymous download path to fall back to, so the installer says that
plainly instead of failing later against a 404.

Workspaces record the registry they came from

workspace.yaml accepts an optional cli_registry naming the source,
repository and api a workspace installs from:

cli_registry:
  source: gitlab
  repository: acme/context-circuit-source
  api: https://gitlab.example.com/api/v4

A publishing pipeline is told its own address by the forge running it, and that
knowledge reaches a developer's machine only if it is written down. The cc-cli
skill reads this key before installing and passes the three values through;
a workspace without the key installs from the default registry.

The key is validated when the workspace is read — an unknown source, a gitlab
source without an api, or an api the installer would refuse for not being
HTTPS are all reported rather than carried. Initialization preserves it: where
a workspace came from is not part of the seed data that initializing replaces.

---

Built at commit 6c0e801e964c271f40a2f1c5f6dcc35a5d565e4c.

Apache-2.0; the archive carries the license. The workspace template is 0BSD.

Context Circuit CLI 2.0.0

Context Circuit CLI 2.0.0

The native executable behind a Context Circuit workspace. It allocates stable
IDs, edits structured records, records approvals and completion, prepares
isolated Git working copies, derives execution order, and produces deterministic
diagnostics.

What it does not do is decide anything. It holds no model credentials and never
calls a model API, so a capability that needs judgment is a skill or an
instruction change rather than a command. Human authorization sits outside both
and is never inferred by either.

This binary is new in v2. There is no 1.x and no 0.x to upgrade from: v1 ran
as a shell runtime with no compiled component, and it is not migrated. The
version starts at 2.0.0 because the CLI was introduced alongside the 2.0.0
workspace template, and a first release numbered 1.0.0 would sit under the
template it shipped with and imply a history it does not have.

The two version lines are independent from here. They change for different
reasons and at different rates — a wording fix in the shared instruction should
not force a reinstall, and a filesystem-cloning fix should not force a workspace
to adopt new instructions — so the numbers will diverge, and a matching pair
after this release is coincidence rather than a guarantee.

Installing

Ask the workspace's cc-cli skill, which selects the platform, verifies the
download against its checksum, and installs without administrator access.
Binaries are published for macOS, Linux, and Windows on amd64 and arm64.

A workspace pins its expected version in .context-circuit/CLI_VERSION, and
installed versions coexist side by side under a version store, so two workspaces
on one machine may expect different releases.

The command surface

• init, status, check — create a workspace, inspect it, and diagnose it.
  Every check finding names what discharges it.
• member — add members, set allocation bands, and record the language and
  register a member writes in.
• repo — connect, clone, or initialize a repository; set this machine's base
  branch and the shared remote separately; relate repositories to one another.
• workspace — bind the Git repository that carries the workspace itself.
• knowledge — mount, clone, sync, and list read-only knowledge repositories a
  workspace reads but does not own.
• record — create intents and plans with reserved IDs, approve, complete,
  declare dependencies, and derive execution order with record order.
• context find — search the optional knowledge index, this workspace's and
  any mounted one, marking which side each match came from.
• worktree — prepare, inspect, move, repair, and remove isolated working
  copies, reusing ignored runtime files through copy-on-write where the
  filesystem supports it.
• agent — inspect and configure per-host subagent model and effort settings,
  write role definitions, and produce a dispatch specification the host launches
  unmodified.
• template export — write the blank workspace seed this binary carries.

Every command answers in human text or, with --json, in a stable structured
form.

Approval, completion, fetch, and removal are explicit operations whose caller
must hold the user's authorization. No command executes a plan, starts a review,
commits, pushes, merges, deploys, or removes a completed worktree on its own.

Compatibility

Records written by 2.0.0-rc.4 and later are read unchanged, and 2.0.0 changes
no record format, no schema, and no command surface against 2.0.0-rc.14.

Unknown fields in structured records are errors, which is why a workspace pins
its CLI version: an older CLI cannot read a workspace using a field introduced
after it. Nothing is removed from a workspace on upgrade.

The embedded workspace seed is a convenience for init and template export.
It does not make the two products one release — the workspace template has its
own version line and its own tags.

Licensing

Apache-2.0. Every release archive carries that license beside the binary, with
third-party notices for its dependencies and the Go runtime. The workspace
template is a separate product under 0BSD.

---

Built at commit 3abfa12e16c720823945baac5efb74d502a27f1d.

Apache-2.0; the archive carries the license. The workspace template is 0BSD.

Context Circuit CLI 2.0.0-rc.14

Context Circuit CLI 2.0.0-rc.14

The seed this binary carries is the workspace and nothing else. What the
published template repository shows a visitor is that repository's business, and
it is no longer embedded here.

Changed

template export writes four files fewer. README.md, the license under
.context-circuit/, and the two images beside it are gone from the manifest,
so an exported seed is the workspace a project keeps and nothing about the
product that produced it.

init writes README.md itself, from a seed of its own that is not part of the
export. It renders three generated spans between markers:

• the title, as Context Circuit - <workspace name>
• the version badges, read from the two stamps this workspace holds rather than
  from whatever was published since
• the purpose, from --purpose

The rest of the file is prose about what the workspace is, what Context Circuit
is, and where to look — written to be edited or thrown away by the project that
now owns it.

init no longer refuses when a README.md is present. It is not template
material any more, so a project that already has a front page is not a project
that failed a precondition. An existing file with the markers has those spans
refreshed; without them it is untouched. Neither case overwrites prose.

Compatibility

Records written by 2.0.0-rc.4 and later are read unchanged, and this release
changes no record format, no schema, and no command surface. A workspace
initialized by an earlier CLI keeps every file it already has: nothing is
removed from a workspace on upgrade, by this CLI or by anything else.

The only behavior an existing workspace will notice is that re-running init is
no longer refused by the presence of a README — and it still refuses for every
reason it did before, including existing workspace data, existing members, and
any other seed file that differs from what it would write.

Licensed Apache-2.0. Every release archive carries that license beside the
binary, with third-party notices for its dependencies and the Go runtime. The
workspace template is a separate product under 0BSD.

---

Built at commit 5877caaf1ac1ac2872679a012265884c9b4f4449.

Apache-2.0; the archive carries the license. The workspace template is 0BSD.