143 lines
5.4 KiB
Markdown
143 lines
5.4 KiB
Markdown
# Operating Playbook
|
|
|
|
## 1. Start A Project
|
|
|
|
Start a project only when the user has a Web-generated initial outline.
|
|
|
|
Minimum inputs:
|
|
|
|
- lead writer identity;
|
|
- initial outline path or pasted outline;
|
|
- source material paths;
|
|
- working slug;
|
|
- the user's instruction to create the project.
|
|
|
|
If the user only has source materials or open discussion, stop and keep the work in `knowledge-vault`.
|
|
|
|
## 2. Create The Folder
|
|
|
|
Use the user-specified project directory when the user gives one. Otherwise use:
|
|
|
|
```text
|
|
projects/YYYY-MM-DD-short-slug/
|
|
```
|
|
|
|
Copy or create the project files from `templates/article-project/PROJECT_STRUCTURE.md`.
|
|
|
|
Fill these first:
|
|
|
|
- `project.md`
|
|
- `source-map.md`
|
|
- `status.md`
|
|
- `decision-log.md`
|
|
- `00-intake/initial-outline-v1.0.md`
|
|
|
|
## 3. Prepare For Outline Review
|
|
|
|
The first operational stage is `outline-review-prep`.
|
|
|
|
Material processing is a subtask of outline review preparation. It exists because context windows are limited, not because the article has not entered writing.
|
|
|
|
For each source, decide the processing method from the source type:
|
|
|
|
- `思想考古报告` or already coherent report: preserve mostly intact or lightly annotate.
|
|
- long discussion: compress around article-relevant claims while preserving unused possibilities.
|
|
- past article: extract relevant arguments, examples, concepts, and style constraints.
|
|
- metadata or writing protocol: preserve as direct constraints.
|
|
|
|
Always keep source paths in `source-map.md`.
|
|
|
|
## 4. Reviewer Audit Runs
|
|
|
|
A review round starts only when the user names the reviewer or reviewers.
|
|
|
|
Before launching any CCPE reviewer, read the external CCPE interface:
|
|
|
|
1. `C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md`
|
|
|
|
Follow the interface to the consumer setup contract, then read any protocol, Runtime, Agent, Lite, or Skill files required for this task.
|
|
|
|
Then resolve the reviewer through root-level `ccpe/agent-registry.yaml`. Do not launch from the display name alone.
|
|
|
|
Formal reviewer output is stored under a project-root `audit/` folder. Each reviewer owns its own round sequence:
|
|
|
|
```text
|
|
audit/
|
|
audit-log.md
|
|
<reviewer-id>/
|
|
r1.1/
|
|
agent-invocation-packet.md
|
|
run-metadata.json
|
|
prompt-to-send.md
|
|
returned-output.md
|
|
r1.2/
|
|
agent-invocation-packet.md
|
|
run-metadata.json
|
|
prompt-to-send.md
|
|
returned-output.md
|
|
r2.1/
|
|
agent-invocation-packet.md
|
|
run-metadata.json
|
|
prompt-to-send.md
|
|
returned-output.md
|
|
```
|
|
|
|
Each run ID is local to each reviewer and uses `rS.R`: `S` is the reviewer-session number, and `R` is that session's round number. For example, `audit/张辽/r1.2/` is 张辽's second round in the first thread; `audit/张辽/r2.1/` is 张辽's first round in a newly started thread.
|
|
|
|
The user chooses:
|
|
|
|
- the reviewers to invoke;
|
|
- whether the prompt is a bare outline review or a full-context review;
|
|
- whether to continue the prior reviewer thread or start a fresh review thread.
|
|
|
|
The controller session may prepare context and launch or coordinate sub-sessions. It must write `agent-invocation-packet.md` before `prompt-to-send.md`, and the prompt sent to the child thread must force the reviewer to load the canonical artifact before reading task context. It must record the child thread ID in `run-metadata.json` and `audit/audit-log.md`. The formal returned output must come from the real reviewer sub-session and be preserved as `returned-output.md`.
|
|
|
|
If the reviewer cannot load the canonical artifact, stop with `blocked_missing_canonical_artifact`. If the reviewer cannot be truly invoked, stop with `blocked_waiting_for_participant_output`. Do not write a formal reviewer report in the controller session.
|
|
|
|
If a reviewer continues a prior review, send the new prompt to that same child thread and write the result to the next same-session round directory. If the user asks for a restart, create a new thread, start a new session directory such as `r2.1`, and record `continuation: false`.
|
|
|
|
`02-outline-review/` may still hold shared review briefs, synthesis notes, and user-facing summaries. It is not the authoritative location for individual reviewer returned outputs.
|
|
|
|
## 5. User Decision Gate
|
|
|
|
After review, stop and wait for the user.
|
|
|
|
The user may provide:
|
|
|
|
- reflection;
|
|
- accepted and rejected review points;
|
|
- direction for lead writer repair;
|
|
- instruction to continue or restart a reviewer audit;
|
|
- instruction to draft a specific part.
|
|
|
|
Record these in `decision-log.md` and the relevant stage folder.
|
|
|
|
## 6. Outline Repair
|
|
|
|
Lead writer repair starts only after the user gives a repair instruction.
|
|
|
|
Versioning:
|
|
|
|
- Web initial outline is `1.0`.
|
|
- First repaired outline starts at `2.0`.
|
|
- Major later revisions use `3.0`, `4.0`, and so on.
|
|
- Small local adjustments use `3.1`, `3.2`, and so on.
|
|
|
|
Review reports do not create outline versions by themselves.
|
|
|
|
## 7. Drafting
|
|
|
|
Do not generate a full article unless the user explicitly asks for that exact action.
|
|
|
|
Default drafting is section-level or chapter-level. Preserve the complete writer session and the resulting draft.
|
|
|
|
If the writer introduces new cases outside source materials, mark them in `draft-notes.md` or the session record.
|
|
|
|
## 8. Publication Boundary
|
|
|
|
Writing Workbench may keep a local full draft for revision.
|
|
|
|
The publication copy and release metadata are maintained by the user in `knowledge-vault`, normally under `sayings/`.
|
|
|
|
Record the intended or final `knowledge-vault` target path in `publish/knowledge-vault-target.md`.
|