11 KiB

Raw Blame History

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
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:

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.

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:

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. Deep-dive projects usually draft one outline unit per returned file; the user may explicitly authorize a larger unattended batch while preserving unit boundaries.

Drafting uses lightweight trace by default:

drafting/
  drafting.md
  sessions/
    <unit>.prompt-1.md
    <unit>.returned-1.md
    <unit>.prompt-2.md
    <unit>.returned-2.md

drafting/drafting.md records the unit map, lead writer, authoritative outline, accepted attempt for each unit, and current state. A unit attempt is preserved as one prompt file and one returned file. If a unit is rerun, increment the attempt suffix and keep the old attempt.

The writer should write directly to the contracted *.returned-N.md path. Do not maintain a controller-side draft-v1.md aggregate by default; long projects would waste context and duplicate the returned files. Create an aggregate draft only when the user asks for a review, polish, export, or publication preparation pass.

Do not create per-unit packet, metadata, extraction, issue, or proofread files by default. Drafting problems discovered by the user go into the next prompt. Outside-reader simulation and proofreading belong to revision/polish after first-draft completion.

If the writer introduces new cases outside source materials, record that instruction or constraint in the prompt for the relevant unit or in drafting/drafting.md.

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.

11 KiB Raw Blame History