writing-workbench/docs/operating-playbook.md

# 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`
- `intake/`
- `outline/`

Store Owner-provided background, source material, and ad hoc instructions under `intake/`. Store formal outline versions under `outline/`. Do not treat a participant's returned output as a formal outline until the Owner extracts or approves it into `outline/`.

## 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.

Participant shorthand is resolved through `ccpe/agent-registry.yaml`. In ordinary user instructions, `巨人` means `giant-cognition`, and `显影` means `cognitive-imaging`.

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.

Default reviewer dispatch should stay minimal and must not over-specify the review method. For a fresh reviewer thread, send only the required context, the outline under review, and the instruction `评审提纲`. For a continued reviewer thread, send the required context, the new outline under review, and the instruction `重新评审提纲`. Do not add controller-authored review focuses, output schemas, severity categories, or prohibitions unless the user explicitly supplies them for that reviewer.

Owner feedback files under `intake/` are not automatically sent to reviewers. They are sent to a reviewer only when the user explicitly says that the feedback is for that reviewer or should be included in that review. Otherwise, Owner feedback is held for lead-writer/editor work such as 韩愈 synthesis or repair.

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`.

When continuing a reviewer session, do not mechanically resend large context files already supplied in the previous round. Send the new object under review, provide the reviewer's prior `returned-output.md` for continuity, and list large prior context such as `intake/背景资料.md` as available on demand for fact-boundary checks. Resend full context only when the user requests it, the participant lacks continuity, or the new task materially depends on rereading it.

`outline-review/` may hold shared review briefs, synthesis notes, and user-facing summaries. It is not the authoritative location for individual reviewer returned outputs. `editor/` is the authoritative location for lead-writer run evidence, not for Owner-approved formal outlines.

When several reviewer outputs return, do not write a controller-session synthesis by default. Save the raw returned outputs, report the run paths and real-carrier evidence, and wait for an explicit user request before producing a main-session summary.

## 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.

Formal lead-writer output is stored under a project-root `editor/` folder. Each lead writer owns an independent session and round sequence:

```text
editor/
  editor-log.md
  <lead-writer-display-name>/
    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
```

The `rS.R` sequence is local to each participant. 韩愈's `r1.2`, 张辽's `r1.2`, 显影's `r1.2`, and 巨人的 `r1.2` are independent and do not imply the same project-wide round.

Lead-writer returned output can be a discussion, direction proposal, outline candidate, chapter draft, or section draft depending on the user's instruction. Preserve it as raw `returned-output.md`; the Owner extracts formal outline versions into `outline/` and formal draft material into the relevant draft path.

Versioning:

- Web initial outline is usually `1.0`.
- Major later revisions use `2.0`, `3.0`, `4.0`, and so on.
- Small local adjustments use `1.1`, `3.1`, `3.2`, and so on.
- The Owner decides whether a change is a major or minor version.

Review reports do not create outline versions by themselves.

## 7. Phase Closeout And Handoff

When the user declares a major phase complete, record the phase transition in project files before starting the next phase or opening a fresh session.

For outline-review completion, the required closeout record is a short project-local handoff under `handoff/`. It should include:

- the Owner-confirmed formal outline path and version;
- the latest state and intended next stage;
- the review and lead-writer run paths that produced raw evidence;
- any rules learned during the phase;
- explicit next-session entry instructions.

Do not turn this handoff into a main-session synthesis of reviewer judgments unless the user asks for that. The handoff is a navigation artifact: it tells the next session where the authoritative files are and what the Owner has decided.

Update `status.md` when it exists, or create it when the project is moving into a new major phase and no status file exists.

## 8. 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.

## 9. 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`.