writing-workbench/docs/operating-playbook.md

5.4 KiB

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:

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:

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.