docs(rebrand): rename & rebrand CI → CIAgent across all documentation, templates, and scripts

- README.md: title, project name, CLI commands, .ci/ → .ciagent/, ci-files → ciagent-files, CI Modification → CIAgent Modification
- AGENTS.md: title, project name, architecture tree, agent count (18→19), test count (25→31 suites, 218→370 tests), version (0.4.0→0.6.0), ci-files → ciagent-files, CIConfig → CIAgentConfig, CiMetadata → CIAgentMetadata, .ci/ → .ciagent/
- templates/DECISIONS.md: .ci/audit/ → .ciagent/audit/, ci audit → ciagent audit
- scripts/postinstall.js: CI postinstall → CIAgent postinstall
- scripts/install.sh: CI → CIAgent, ci-init → ciagent-init, INSTALL COMPLETE banner
- opencode/ci/workflows/*.md (11 files): .ci/ → .ciagent/, CI → CIAgent project name, ci-command → ciagent-command usage lines
- opencode/ci/references/*.md (5 files): .ci/ → .ciagent/, CI → CIAgent project name, ci-files → ciagent-files references
- opencode/ci/contexts/*.md (3 files): .ci/ → .ciagent/, CI → CIAgent project name
- opencode/agents/ci-*.md (18 files): .ci/ → .ciagent/, CI → CIAgent project name
- opencode/command/ci-*.md (11 files): CI → CIAgent project name

Preserved: ---ci---/---/ci--- markers, opencode/ci/ dir paths, ci-*.md filenames, ci listProjects()/ci setActiveProject() API names, repo URLs

---ci---
phase: 1
milestone: v0.6
plan: 01-01
task: 01-01-01
status: execute
---/ci---
This commit is contained in:
Jon Chery
2026-05-29 17:58:48 +00:00
parent ab6af144b7
commit e31afe3b59
53 changed files with 429 additions and 429 deletions
+2 -2
View File
@@ -1,6 +1,6 @@
<branch_strategy>
Canonical branch naming and lifecycle conventions for CI. Branches encode project structure — merged branches indicate completed work, active branches indicate work in progress.
Canonical branch naming and lifecycle conventions for CIAgent. Branches encode project structure — merged branches indicate completed work, active branches indicate work in progress.
---
@@ -182,7 +182,7 @@ Before creating any tag:
## Multi-Project Branch Naming
When operating in multi-project mode (`.ci/config.json` has `projects[]` with length > 0):
When operating in multi-project mode (`.ciagent/config.json` has `projects[]` with length > 0):
| Branch Type | Format | Example |
|-------------|--------|---------|
+21 -21
View File
@@ -1,15 +1,15 @@
<ci_files_discipline>
How CI manages the `.ci/` directory — long-lived reference documents only. Dynamic state lives in the git log via `---ci---` YAML blocks, not in files.
How CIAgent manages the `.ciagent/` directory — long-lived reference documents only. Dynamic state lives in the git log via `---ci---` YAML blocks, not in files.
---
## Multi-Project Directory Structure
In multi-project mode, `.ci/` uses subdirectories per project:
In multi-project mode, `.ciagent/` uses subdirectories per project:
```
.ci/
.ciagent/
config.json # Registry with projects[] and active_project
<project-slug>/
PROJECT.md
@@ -18,11 +18,11 @@ In multi-project mode, `.ci/` uses subdirectories per project:
REQUIREMENTS.md
```
`.ci/config.json` serves as the registry with `projects[]` (array of project entries) and `active_project` (slug of the currently active project).
`.ciagent/config.json` serves as the registry with `projects[]` (array of project entries) and `active_project` (slug of the currently active project).
**Backward compatibility:** if `.ci/` has flat files (PROJECT.md, ARCHITECTURE.md, etc.) and no project subdirectories, auto-migrate by creating `<default-slug>/` and moving files into it, then updating `config.json` with a single `projects[]` entry.
**Backward compatibility:** if `.ciagent/` has flat files (PROJECT.md, ARCHITECTURE.md, etc.) and no project subdirectories, auto-migrate by creating `<default-slug>/` and moving files into it, then updating `config.json` with a single `projects[]` entry.
## What Lives in `.ci/`
## What Lives in `.ciagent/`
| File | Purpose | Update Frequency |
|------|---------|-------------------|
@@ -32,23 +32,23 @@ In multi-project mode, `.ci/` uses subdirectories per project:
| `<slug>/ROADMAP.md` | Phase breakdown, milestone mapping, success criteria per project | Low (phase transitions) |
| `<slug>/REQUIREMENTS.md` | v1/v2 requirements with REQ-IDs, out of scope, traceability per project | Low (requirement changes) |
## What Does NOT Live in `.ci/`
## What Does NOT Live in `.ciagent/`
These were removed in v0.2.0 and now live in the git log:
| Previous Location | Now In | Access Method |
|-------------------|--------|---------------|
| `.ci/audit/decisions.json` | `---ci---` decisions block | `GitContext.getDecisions()` |
| `.ci/audit/escalations.json` | `---ci---` escalations block | `GitContext.getEscalations()` |
| `.ci/audit/lessons.json` | `---ci---` lessons block | `GitContext.getLessons()` |
| `.ciagent/audit/decisions.json` | `---ci---` decisions block | `GitContext.getDecisions()` |
| `.ciagent/audit/escalations.json` | `---ci---` escalations block | `GitContext.getEscalations()` |
| `.ciagent/audit/lessons.json` | `---ci---` lessons block | `GitContext.getLessons()` |
| `.planning/` directory (removed) | Git log + branches | `GitContext.reconstructState()` |
## CiFiles API
| Method | Returns | Purpose |
|--------|---------|---------|
| `ensureCIDir()` | void | Create `.ci/` if it doesn't exist |
| `isInitialized()` | boolean | Check if `.ci/config.json` exists |
| `ensureCIDir()` | void | Create `.ciagent/` if it doesn't exist |
| `isInitialized()` | boolean | Check if `.ciagent/config.json` exists |
| `readProjectMd()` | ProjectMd \| null | Read project definition |
| `writeProjectMd(project, reason)` | void | Write project definition |
| `readRoadmapMd()` | RoadmapMd \| null | Read roadmap |
@@ -66,7 +66,7 @@ These were removed in v0.2.0 and now live in the git log:
2. **Phase boundaries** — Major updates happen at phase transitions, not during task execution.
3. **Requirements status** — Use `updateRequirementStatus()` for single-status changes, not full rewrites.
4. **Phase status** — Use `updatePhaseStatus()` for phase transitions, not full roadmap rewrites.
5. **Commit after write** — Every `.ci/` file change should be committed immediately with a `---ci---` block.
5. **Commit after write** — Every `.ciagent/` file change should be committed immediately with a `---ci---` block.
## Update Triggers
@@ -157,21 +157,21 @@ interface ArchitectureMd {
## Research and .ci/ File Updates
Research is intermediate work product. Conclusions from research update `.ci/` static files:
Research is intermediate work product. Conclusions from research update `.ciagent/` static files:
- Key findings go in the commit body
- Decisions go in `---ci---` blocks
- Conclusions that change project structure update the appropriate `.ci/<slug>/` files (ARCHITECTURE.md, PROJECT.md, etc.)
- Conclusions that change project structure update the appropriate `.ciagent/<slug>/` files (ARCHITECTURE.md, PROJECT.md, etc.)
Research commits are not final artifacts — they feed into planning and roadmap updates.
## Anti-Patterns
- Never write dynamic state (decisions, escalations, lessons) to `.ci/` files
- Never update `.ci/` files during task execution — update at phase boundaries
- Never write dynamic state (decisions, escalations, lessons) to `.ciagent/` files
- Never update `.ciagent/` files during task execution — update at phase boundaries
- Never skip the `reason` parameter when writing PROJECT.md
- Never commit `.ci/` changes without a `---ci---` block
- Never create new files in `.ci/` without updating this reference document
- Never store counters, timestamps, or session state in `.ci/` files
- Never store research conclusions only in commits — update `.ci/<slug>/` static files with findings
- Never commit `.ciagent/` changes without a `---ci---` block
- Never create new files in `.ciagent/` without updating this reference document
- Never store counters, timestamps, or session state in `.ciagent/` files
- Never store research conclusions only in commits — update `.ciagent/<slug>/` static files with findings
</ci_files_discipline>
+5 -5
View File
@@ -1,6 +1,6 @@
<commit_schema>
Canonical `---ci---` YAML block schema for CI commits. Every CI-generated commit contains a structured YAML block that enables full project state reconstruction from the git log alone.
Canonical `---ci---` YAML block schema for CIAgent commits. Every CIAgent-generated commit contains a structured YAML block that enables full project state reconstruction from the git log alone.
---
@@ -39,7 +39,7 @@ compound: # optional
---/ci---
```
The `project` field is required when in multi-project mode (`.ci/config.json` has `projects[]` with length > 0). In single-project mode, it is optional.
The `project` field is required when in multi-project mode (`.ciagent/config.json` has `projects[]` with length > 0). In single-project mode, it is optional.
Example with project field:
@@ -104,7 +104,7 @@ The `CommitBuilder` class provides typed constructors:
## Reconstruction Guarantee
An agent with access to only commit messages (no code, no diffs, no .ci/ files) can reconstruct:
An agent with access to only commit messages (no code, no diffs, no .ciagent/ files) can reconstruct:
1. **Current phase and milestone** — from the latest commit's `phase` and `milestone` fields
2. **Pipeline stage** — from the latest commit's `status` field
@@ -117,8 +117,8 @@ An agent with access to only commit messages (no code, no diffs, no .ci/ files)
## Anti-Patterns
- Never put CI metadata in code comments — it belongs in commit messages
- Never omit the `---ci---` block from a CI-generated commit
- Never put CIAgent metadata in code comments — it belongs in commit messages
- Never omit the `---ci---` block from a CIAgent-generated commit
- Never store decisions, escalations, or lessons in files — commit them
- Never use a non-standard commit type — use the 14 types above
- Never put freeform text inside the YAML block — use the structured fields
+2 -2
View File
@@ -1,6 +1,6 @@
<decision_engine>
How CI makes decisions and commits them as git artifacts. The DecisionEngine uses bounded rationality with confidence thresholds to auto-decide or escalate.
How CIAgent makes decisions and commits them as git artifacts. The DecisionEngine uses bounded rationality with confidence thresholds to auto-decide or escalate.
---
@@ -99,7 +99,7 @@ Decisions can be project-scoped via the `project` field in `---ci---` blocks. Wh
## Anti-Patterns
- Never write decisions to a `.ci/audit/` file — commit them
- Never write decisions to a `.ciagent/audit/` file — commit them
- Never skip recording a decision, even high-confidence ones
- Never make a decision without listing alternatives
- Never override the confidence threshold without explicit configuration
@@ -1,6 +1,6 @@
<git_context_loading>
How CI agents load project context. The git log IS the project memory — a CI agent's first impulse to gather context is `git log` + `git branch`, not file reads.
How CIAgent agents load project context. The git log IS the project memory — a CIAgent agent's first impulse to gather context is `git log` + `git branch`, not file reads.
---
@@ -8,7 +8,7 @@ How CI agents load project context. The git log IS the project memory — a CI a
**Read the log first, files second.**
The git log contains every decision, escalation, lesson, and compound learning through structured `---ci---` YAML blocks. Files in `.ci/` are long-lived reference documents (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md, config.json) that change infrequently.
The git log contains every decision, escalation, lesson, and compound learning through structured `---ci---` YAML blocks. Files in `.ciagent/` are long-lived reference documents (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md, config.json) that change infrequently.
## Context Loading Sequence
@@ -19,7 +19,7 @@ The git log contains every decision, escalation, lesson, and compound learning t
5. **Requirements coverage**`GitContext.getRequirementsCoverage()` for covered/partial
6. **Lessons scan**`GitContext.getLessons()` for all learned lessons
7. **Compound learnings**`GitContext.getCompounds()` for cross-phase patterns
8. **File reads** — Only now read `.ci/` files (PROJECT.md, ARCHITECTURE.md, etc.)
8. **File reads** — Only now read `.ciagent/` files (PROJECT.md, ARCHITECTURE.md, etc.)
## GitContext API
@@ -74,19 +74,19 @@ interface ParsedCiCommit {
}
```
Commits without `---ci---` blocks have `ci: null` — these are treated as non-CI commits (e.g., manual edits by the developer).
Commits without `---ci---` blocks have `ci: null` — these are treated as non-CIAgent commits (e.g., manual edits by the developer).
## Phase Context Reset
Between phases, all state is committed to git, then the next phase starts with fresh context from git log — not accumulated conversation history.
**On opencode (subagent support):** spawn a fresh agent for the next phase. The new agent loads context from git log and `.ci/` files only.
**On opencode (subagent support):** spawn a fresh agent for the next phase. The new agent loads context from git log and `.ciagent/` files only.
**On platforms without subagents:** simulated reset — re-read git context from scratch, ignore prior conversation history. Treat the phase boundary as a hard context boundary.
**Checkpoint sequence:**
1. Commit all work from the current phase
2. Update `.ci/` files (ROADMAP.md phase status, REQUIREMENTS.md requirement statuses)
2. Update `.ciagent/` files (ROADMAP.md phase status, REQUIREMENTS.md requirement statuses)
3. Verify `GitContext.reconstructState()` matches expected state
4. Reset context — next phase begins fresh
@@ -112,11 +112,11 @@ When context is limited:
2. `getDecisions(currentPhase)` — current phase decisions only
3. `getRequirementsCoverage()` — aggregate view
4. Skip lessons/compounds unless specifically needed
5. Read `.ci/ROADMAP.md` instead of scanning all phase branches
5. Read `.ciagent/ROADMAP.md` instead of scanning all phase branches
## What NOT to Do
- Never read `.ci/` files before checking the git log
- Never read `.ciagent/` files before checking the git log
- Never parse commit messages manually — use `CommitParser.parseCommitMessage()`
- Never assume the latest commit reflects the current state — check branches
- Never reconstruct state from files when git data is available