5.2 KiB

Raw Permalink Blame History

WORKBENCH.md

1. Identity

Writing Workbench is the user's local writing operations room.

The user remains the director. The workspace records and assists the process, but it does not decide which reviewer to call, whether a review round is enough, whether a writer should revise, or whether drafting should begin.

2. Default Workflow

Web source discussion
  -> Web initial outline v1.0
  -> Writing Workbench project
  -> outline review preparation
  -> user-named reviewer audit sessions
  -> user reflection and decision
  -> user-directed lead writer repair
  -> outline v2.0 / v3.0 / ...
  -> user-directed drafting by section or chapter
  -> local draft preservation
  -> user-maintained publication in knowledge-vault

3. Project Folders

Projects live directly under projects/.

Do not split projects into active, completed, or abandoned folders by default. Writing projects are not software tickets; state belongs in status.md, decision-log.md, and stage folders.

Use stable folder names:

projects/YYYY-MM-DD-short-slug/

4. Two Modes

Execution Mode

Use existing agents, skills, and files to complete work for the current article project.

Execution mode may:

prepare source digests;
create review briefs;
invoke user-named reviewers or writers through real sub-sessions;
maintain the root-level CCPE registry and invocation policy under ccpe/;
record reviewer audit runs under audit/<reviewer-id>/rS.R/;
preserve returned outputs, prompts, and thread IDs;
prepare synthesis files for the user;
update status and decision logs.

Execution mode must not invent missing expert output.

Capability-Request Mode

When an agent, skill, or runtime is missing, create a supplier ticket and pause the current project.

Tickets go to:

requirements/ccpe/
requirements/skills-vault/

CCPE supplies expert agents, runtime rules, model cards, and governed cognitive assets.

Skills-vault supplies deterministic automation tools, scripts, and installable skills.

5. Source Policy

Original discussions, reports, past articles, and finished public essays remain in knowledge-vault.

Writing Workbench stores article-facing derived materials inside the project, but source-map.md must point back to the authoritative originals.

Derived material files are working aids, not source of truth.

6. Invocation Policy

Formal reviewer and writer outputs require real invocation.

Before invoking a CCPE participant, the controller session must read the external CCPE interface at C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md. Follow that interface to the consumer setup contract and then to any task-required protocol, Runtime, Agent, Lite, or Skill files. After that, resolve the participant through the root-level ccpe/agent-registry.yaml, and write agent-invocation-packet.md for the run.

The controller session may prepare context, launch or coordinate sub-sessions, summarize returned outputs, and ask the user for decisions. It may not role-play a reviewer or writer and label that result formal. It must not treat agent-invocation-packet.md or prompt-to-send.md as executed output.

Reviewer audit outputs live in the project under audit/<reviewer-id>/rS.R/, where S is the reviewer-session number and R is that session's round number. A continued review uses the same reviewer thread and increments the round part, such as r1.1 to r1.2; a restarted review creates a new thread, increments the session part, and starts at .1, such as r2.1.

7. Drafting Policy

Full-article generation is prohibited by default.

Drafting happens only when the user gives an explicit instruction. The unit of drafting is determined by the user and the lead writer's established prompt behavior, usually section or chapter level.

Drafting is a writing pipeline, not an audit system. After the user authorizes drafting, default to a lightweight trace:

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

Use drafting/drafting.md as the unit map and progress tracker. Use one prompt/returned pair per unit attempt. Increment the attempt suffix when rerunning a unit; never overwrite prior attempts.

The lead writer should write directly to the contracted *.returned-N.md path. The controller session should not maintain draft-v1.md, draft-notes.md, proofread logs, or per-section agent-invocation-packet.md / run-metadata.json files unless the user explicitly asks for that heavier record.

For a single-lead-writer project, do not add an extra lead-writer directory under drafting/sessions/. The lead writer identity is already recorded in project metadata, outline history, or the drafting tracker. Add a writer layer only when the user deliberately runs multiple lead writers in the same drafting phase.

User feedback during drafting should go into the next prompt. Do not create a separate issue log by default. Simulated outside-reader review belongs to revision or polish, not first-draft generation.

Writer sessions may introduce new examples or cases beyond the source materials when the task calls for it. If that matters for later review, record the constraint in the next prompt or in drafting/drafting.md.

5.2 KiB Raw Permalink Blame History