# Writing Workbench Operating Playbook

This playbook explains how to run an article project inside Writing Workbench.

It is the operational layer between the workspace principles in `WORKBENCH.md` and the concrete project files under `projects/active/`.

## 1. When To Start A Project

Start a Writing Workbench project only after the user has decided that an idea should enter article production.

Do not use this workspace for:

- raw diary capture
- open-ended viewpoint exploration
- generic source archiving
- canonical CCPE asset creation
- video production planning

Those belong in Knowledge Vault, CCPE System, or the future Video Workbench.

## 2. Project ID

Use this folder pattern:

```text
projects/active/YYYY-MM-DD-aNNN-temp-slug/
```

Rules:

- `YYYY-MM-DD` is the project creation date.
- `aNNN` is a local article counter for that day.
- `temp-slug` is a stable working slug, not the final title.
- Do not rename the folder when the article title changes.
- Store title changes in `project.md`.

## 3. Creating A New Project

1. Copy the skeleton:

```powershell
Copy-Item -Recurse templates\article-project\skeleton projects\active\YYYY-MM-DD-aNNN-temp-slug
```

2. Fill these files first:

- `project.md`
- `source-map.md`
- `status.md`
- `00-creation-plan/creative-brief.md`

3. Update `indexes/active-projects.md`.

4. If CCPE assets are used, update:

- `indexes/ccpe-consumption-map.md`
- `ccpe-consumption/runtime-links.md` when a new reusable asset relationship is discovered

## 4. Minimum Viable Project State

A project is ready for article work when these files are no longer blank:

- `project.md`: identity, intent, target article type, decision gates
- `source-map.md`: source locations and source policy
- `status.md`: current phase, open decisions, next actions
- `00-creation-plan/context-pack.md`: the smallest useful pack for the first writer or reviewer

Do not dispatch writer or reviewer sessions before these files exist.

## 5. Phase Flow

Use this default sequence:

```text
00-creation-plan
01-positioning
02-outline
03-drafting
04-draft-review
05-appendix
06-metadata
07-tribunal
08-model-writing
publish
```

The user may skip optional stages, but record the decision in `status.md`.

Required before drafting:

- positioning is stable enough to write
- outline has passed review or the user has explicitly accepted the risk
- required sources are listed in `source-map.md`
- the active context pack is available

Required before publish:

- final article exists in `publish/final.md`
- unresolved review issues are either fixed or explicitly waived
- metadata is complete when needed
- archive destinations are recorded

## 6. Context Packs

Use the smallest pack that can support the task.

- `lite`: article goal, current artifact, core claims, constraints
- `standard`: lite pack plus source summaries and selected evidence
- `deep`: standard pack plus long excerpts, historical essays, or research material

Do not paste every source file into a context pack. Reference source paths unless selected excerpts are necessary.

## 7. Sessions And Reports

For each writer, reviewer, tribunal member, or modeling session, preserve both:

- `session.md`: process record
- `report.md`: final result or decision-ready output

The orchestrator should read reports, syntheses, and repair requests before reading full session records.

Use full sessions only when:

- the report is ambiguous
- a decision depends on reasoning history
- the user asks to inspect the process
- the next agent needs exact prior discussion details

## 8. Review Rounds

Each review round should preserve:

- `review-brief.md`
- one folder per reviewer
- each reviewer folder with `session.md` and `report.md`
- `synthesis.md`
- `repair-request.md`

The repair request should be addressed to the next writer or reviser. It should not be a generic list of review comments.

## 9. Index Synchronization

Update indexes as project state changes.

Use `indexes/active-projects.md` when:

- a project is created
- current phase changes
- next action changes
- lead writer or project status changes

Use `indexes/completed-projects.md` when:

- a project moves to `projects/completed/`
- final archive paths are known
- extracted model documents or CCPE improvement requests are known

Use `indexes/ccpe-consumption-map.md` when:

- a CCPE asset is used in a project
- an asset produces an output
- an issue or improvement request should be sent back to CCPE System

Use `indexes/extracted-models.md` when:

- the article produces a human-facing model document
- the model should be archived in Knowledge Vault
- the model has possible AI-facing Model Card potential

## 10. CCPE Boundary

Writing Workbench consumes CCPE assets. It does not redefine them.

Allowed here:

- canonical path references
- task-specific usage notes
- context packs for using an asset
- reports about asset issues
- improvement requests for CCPE System

Not allowed here:

- copied canonical Agent Specs
- copied canonical Model Cards
- copied canonical Skill definitions
- permanent forks of CCPE runtime protocols

Trial article runs should wait until the required CCPE agents or Lite prompts are available in CCPE System, unless the user explicitly chooses a manual placeholder workflow.

## 11. Completion And Archiving

When an article is complete:

1. Move the project folder from `projects/active/` to `projects/completed/`.
2. Keep all process records inside the completed project folder.
3. Archive the final essay to Knowledge Vault `sayings/`.
4. Archive human-facing model documents to Knowledge Vault `rules/`.
5. Promote AI-facing model assets only through CCPE System.
6. Update all relevant indexes.

When a project is abandoned:

1. Record the reason in `status.md`.
2. Move the project folder to `projects/abandoned/`.
3. Keep the process trail unless the user explicitly asks to remove it.