rebuild: initialize writing workbench

This commit is contained in:
wantsong 2026-06-15 12:02:21 +08:00
parent 26dd1a6e96
commit 0721f81127
82 changed files with 516 additions and 1244 deletions

View File

@ -1,62 +1,59 @@
# Writing Workbench # Writing Workbench
Writing Workbench is the production workspace for deep article creation and human-facing model writing. Writing Workbench is the local tool-calling and process-record workspace for article writing after a Web-generated initial outline already exists.
It is not the long-term knowledge archive and it is not the CCPE asset factory. It is not the idea base, not the long-context material discussion space, and not an autonomous article production runtime.
## Position ## Current Position
```text ```text
Knowledge Vault = source archive, formal essays, human model documents, historical discussions knowledge-vault = upstream discussions, source materials, published essays, public-facing archive
Writing Workbench = active article production site and process record writing-workbench = local project workspace for outline review, agent invocation, records, drafts
CCPE System = AI cognitive asset engineering workspace ccpe-system = expert agents, runtime protocols, model cards, governed cognitive assets
Delivery Systems = deployable external agentic products skills-vault = reusable automation skills and deterministic tools
Video Workbench = dimensional video output workspace, planned separately
``` ```
## Entry Rule
A project starts here only when the user provides:
- a Web-generated initial outline, normally version `1.0`;
- source paths for the article materials;
- the lead writer identity, such as `韩愈` or `蒙田`;
- an explicit instruction to create or continue the project.
If there is no initial outline, do not create a Writing Workbench project. Continue discussion and material development in `knowledge-vault`.
## Mission ## Mission
This workspace manages articles after the user has decided that an idea should enter production. This workspace helps the user save effort after the article has entered writing:
It preserves both final outputs and process records: - register source paths in `source-map.md`;
- preserve the initial outline;
- prepare outline-review context under current context-window limits;
- compress or organize source materials without replacing the original sources;
- invoke real reviewer and writer sessions when the user explicitly names them;
- preserve complete `session.md` and final `report.md` records;
- preserve user decisions, reflections, outline versions, and draft sessions;
- create capability request tickets when required agents or skills are missing.
- creation plan ## Hard Rules
- source map
- context packs
- writer sessions
- outline versions
- review sessions and reports
- synthesis and repair requests
- draft chapters
- revised drafts
- appendix drafts
- metadata generation
- human-facing model writing
- publish-ready final article
## Boundaries 1. No initial outline, no project.
2. No user-named reviewer, no reviewer invocation.
3. No real sub-session, no formal reviewer or writer output.
4. No user decision, no stage advancement.
5. No full-article generation by default.
6. Missing capability creates a supplier ticket and pauses the project.
- New ideas and daily captures stay in `knowledge-vault/diary`. ## Directory Overview
- Viewpoint exploration and non-article discussions stay in `knowledge-vault/discussions`.
- Formal published essays are archived in `knowledge-vault/sayings`.
- Human-facing model documents are archived in `knowledge-vault/rules`.
- AI-facing Model Cards, Agent Specs, Skills, and Runtimes are maintained in `ccpe-system`.
- Writing Workbench consumes CCPE assets but does not redefine them.
## Starting A New Session ```text
docs/ Operating rules for this workspace
In a new Codex session opened on this project, use: projects/ Article project workspaces, one folder per article
requirements/ccpe/ Supplier tickets for CCPE agents/runtimes/model assets
```md requirements/skills-vault/ Supplier tickets for automation skills
Please read README.md, WORKBENCH.md, and docs/context-handoff.md first, then continue work on Writing Workbench according to those conventions. templates/ Project and requirement templates
``` ```
## Operating A Project Old pre-rebuild scaffold assumptions were discarded on 2026-06-15. The current model is: the user brings a Web outline and source paths; Codex helps compress, invoke, record, and organize, but does not decide how the article proceeds.
Use `docs/operating-playbook.md` for the practical project workflow:
- when to start a project
- how to create a project folder
- which files must be filled first
- how to manage context packs, sessions, review rounds, and indexes
- how to keep CCPE System as the canonical asset source

View File

@ -1,134 +1,89 @@
# WORKBENCH.md # WORKBENCH.md
## 1. Workspace Identity ## 1. Identity
This project is the article production workspace. Writing Workbench is the user's local writing operations room.
It is a stage and process black box for deep writing. It records how an article moves from selected idea to final published text, while keeping the original knowledge archive and CCPE asset factory separate. 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. Operating Principle ## 2. Default Workflow
Preserve process as a first-class artifact.
The user values not only final drafts but also the discussion, review, synthesis, repair, and decision trail that produced them. Do not collapse multi-round writing or review work into a single final file unless explicitly asked.
## 3. Project Lifecycle
Ideas normally begin outside this workspace:
```text ```text
knowledge-vault/diary Web source discussion
knowledge-vault/discussions -> Web initial outline v1.0
knowledge-vault/sources -> Writing Workbench project
knowledge-vault/sayings -> outline review preparation
knowledge-vault/rules -> user-named reviewer 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
``` ```
A project enters Writing Workbench only after the user decides to write. ## 3. Project Folders
Each active article should use a stable project id: 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:
```text ```text
projects/active/YYYY-MM-DD-aNNN-temp-slug/ projects/YYYY-MM-DD-short-slug/
``` ```
Do not rename the project folder every time the article title changes. Store title changes in `project.md` and final title metadata in `publish/final.md`. ## 4. Two Modes
## 4. Canonical Article Project Structure ### Execution Mode
Use `templates/article-project/PROJECT_STRUCTURE.md` as the expansion guide when creating a full project. Use existing agents, skills, and files to complete work for the current article project.
For a copyable starting point, use: Execution mode may:
- prepare source digests;
- create review briefs;
- invoke user-named reviewers or writers through real sub-sessions;
- record sessions and reports;
- 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:
```text ```text
templates/article-project/skeleton/ requirements/ccpe/
requirements/skills-vault/
``` ```
Top-level project files: CCPE supplies expert agents, runtime rules, model cards, and governed cognitive assets.
- `project.md`: stable project identity, temporary title, final title when known, phase, status Skills-vault supplies deterministic automation tools, scripts, and installable skills.
- `source-map.md`: source files from Knowledge Vault and other repositories
- `status.md`: current phase, open decisions, next actions
Main stages: ## 5. Source Policy
- `00-creation-plan/` Original discussions, reports, past articles, and finished public essays remain in `knowledge-vault`.
- `01-positioning/`
- `02-outline/`
- `03-drafting/`
- `04-draft-review/`
- `05-appendix/`
- `06-metadata/`
- `07-tribunal/`
- `08-model-writing/`
- `publish/`
## 5. Session And Thread Policy Writing Workbench stores article-facing derived materials inside the project, but `source-map.md` must point back to the authoritative originals.
Use files as shared state. Derived material files are working aids, not source of truth.
Separate Codex sessions or background threads may be used for writers and reviewers, but their long conversation history should not be copied wholesale back into the orchestrator session. ## 6. Invocation Policy
Preferred flow: Formal reviewer and writer outputs require real invocation.
```text 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.
orchestrator session
prepares context-pack
dispatches writer or reviewer session
receives session.md and report.md
reads only the necessary report/synthesis
asks the user for decision when needed
```
For each review role, preserve: ## 7. Drafting Policy
- `session.md`: discussion/process record Full-article generation is prohibited by default.
- `report.md`: final review result
The orchestrator should consume reports and synthesis files, not every full session transcript. 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.
## 6. Context Pack Policy Writer sessions may introduce new examples or cases beyond the source materials when the task calls for it, but such additions should be marked in the session or draft notes.
Do not feed every source file by default.
Prepare task-specific context packs:
- `context-pack-lite.md`: article goal, current outline/draft, core claims
- `context-pack-standard.md`: lite pack plus selected material summaries and key source links
- `context-pack-deep.md`: standard pack plus long source excerpts, historical essays, or Deep Research
Use the smallest pack that lets the role do useful work.
## 7. CCPE Consumption
Writing Workbench consumes CCPE assets from:
```text
C:\Users\wangq\Documents\Codex\ccpe-system
```
Examples:
- main writer agents
- Zhang Liao red-team agent
- Cognitive Imaging
- Giant Cognition
- metadata agent
- context-pack builder skill
- review synthesis skill
- repair request builder skill
- Article Production Orchestrator
- Outline Review Runtime
Do not duplicate the full canonical CCPE asset inside this workspace. Add thin notes in `ccpe-consumption/` that point to the canonical source and explain how this workspace uses it.
## 8. Archive Policy
When an article is completed:
- keep full process records in `projects/completed/`
- archive final essay in `knowledge-vault/sayings`
- archive human model documents in `knowledge-vault/rules`
- promote AI-facing model cards or runtime assets through `ccpe-system` only when mature enough
When a project is abandoned, move it to `projects/abandoned/` and preserve the reason in `status.md`.

View File

@ -1,27 +0,0 @@
# CCPE Runtime Links
This file records how Writing Workbench consumes CCPE System assets.
Canonical CCPE workspace:
```text
C:\Users\wangq\Documents\Codex\ccpe-system
```
## Planned Assets
| Asset | Type | Status | Notes |
| --- | --- | --- | --- |
| Article Production Orchestrator | Agent Spec | planned | Total writing process coordinator |
| Outline Review Runtime | Runtime | planned | First runtime to build and validate |
| Context Pack Builder | Skill | planned | Builds role-specific context packs |
| Review Synthesis | Skill | planned | Synthesizes multiple review reports |
| Repair Request Builder | Skill | planned | Turns review synthesis into writer repair instructions |
| Cognitive Imaging | Lite / Model Card | existing in CCPE | Use as review actor where applicable |
| Giant Cognition | Lite / Model Card | existing in CCPE | Use as review actor where applicable |
| Zhang Liao | Lite / Agent | planned | Red-team and constructive Socratic reviewer |
## Policy
Do not copy canonical CCPE artifacts here. Record links, usage notes, and task-specific adapters only.

View File

@ -0,0 +1,31 @@
# Capability Requests
Writing Workbench is a consumer of capabilities, not their source of truth.
## CCPE Requests
Use `requirements/ccpe/` when the missing capability is:
- expert agent;
- writer or reviewer prompt;
- runtime protocol;
- invocation rule;
- model card;
- evaluation or governance method.
## Skills-Vault Requests
Use `requirements/skills-vault/` when the missing capability is:
- deterministic file transformation;
- source splitter;
- markdown formatter;
- report exporter;
- citation checker;
- repeatable CLI or script-backed automation.
## Ticket Rule
A ticket should be enough for the supplier project to build the capability without rereading the whole article project.
Do not implement supplier capabilities inside Writing Workbench.

View File

@ -1,163 +0,0 @@
# Writing Workbench Context Handoff
This document preserves the working agreements that led to this workspace. It exists so future Codex sessions do not depend on copied chat history.
## Confirmed Architecture
```text
Knowledge Vault = mine and archive
Writing Workbench = article production stage and process record
CCPE System = actor, skill, model, and runtime factory
Delivery Systems = deployable external agentic systems
Video Workbench = future dimensional video output workspace
```
The user described the metaphor this way:
```text
Knowledge Vault provides the script material.
Writing Workbench is the stage.
CCPE System provides actors, skills, model cards, and runtime protocols.
The user remains the final director, editor, and decision gate.
```
## Knowledge Vault Status
`C:\Users\wangq\Documents\Codex\knowledge-vault` has been established and migrated except for some work assets.
Important directories:
- `diary/`: daily or irregular captures from phone and PC
- `discussions/`: viewpoint base camp and historical process archive
- `sayings/`: formal essays
- `rules/`: human-facing model documents and writing rules
- `prompts/`: legacy and current prompt assets
- `sources/`: Deep Research, reading notes, excerpts, clipped articles, references
- `indexes/`: maintained mostly by Codex on request
- `templates/`: human-facing document templates
Writing Workbench should not recreate diary or generic discussion intake.
## Writing Workbench Role
This workspace begins only after the user decides to turn an idea into an article.
It should preserve the full production trail:
1. creation plan
2. positioning
3. outline generation and review
4. drafting
5. draft review
6. appendix generation
7. metadata generation
8. optional tribunal
9. human-facing model writing
10. publish package
The current scaffold intentionally leaves the first project empty. A real article project should be created under:
```text
projects/active/YYYY-MM-DD-aNNN-temp-slug/
```
## Process Record Principle
The user's prior workflow retained discussion transcripts because single-agent workflows often lost coherence without them. Agentic Engineering should reduce copy-paste burden, but it should not discard process records.
For each writer or reviewer interaction:
- `session.md` records the discussion process
- `report.md` records the final result
- orchestrator reads reports and synthesis, not every full transcript
## Session Mechanism
Use separate sessions or background threads when context isolation is useful.
Recommended pattern:
```text
Article Production Orchestrator
prepares context packs
dispatches writer/reviewer sessions
receives written outputs
synthesizes reports
asks user for decisions
```
Continuity should be file-based, not conversation-context-based.
## Runtime Roadmap For CCPE System
The next CCPE work should be done in:
```text
C:\Users\wangq\Documents\Codex\ccpe-system
```
Recommended build sequence:
1. Upgrade and verify key single-agent experts as CCPE-Lite.
2. Run Scenario Probe before upgrading any Lite into Agent Spec or Skill.
3. Preserve useful Lite artifacts instead of forcing every actor into Agent/Skill/Runtime.
4. Build `Article Production Orchestrator` as an Agent Spec.
5. Build `Outline Review Runtime` first, because outline review is the most expensive and failure-prone stage.
6. Add small reusable Skills only where real workflow demand exists:
- context-pack builder
- review dispatcher
- review synthesis
- repair request builder
- source-map builder
- metadata generator
7. Validate with a trial article project in Writing Workbench.
8. Only after the outline runtime stabilizes, expand to the full article production runtime.
9. Add Tribunal and Modeling Committee later as sub-runtimes with their own coordinators.
Important prior CCPE rule:
```text
Scenario-first layering:
decide Lite / Agent Spec / Skill / Runtime / Model Card based on actual use scenario, not on a desire to over-engineer.
```
## Controller Model
Before Tribunal and Modeling Committee are added, use one primary controller:
```text
Article Production Orchestrator
```
Later, use:
```text
Article Production Orchestrator = total project coordinator
Tribunal Presiding Agent = sub-controller for tribunal judgment
Modeling Committee Facilitator = sub-controller for human model document production
```
Sub-controllers are needed when target outputs, decision criteria, role sets, context isolation, risk boundary, or rhythm differ substantially.
## Future Video Workbench
A future sibling project should be created for dimensional output:
```text
C:\Users\wangq\Documents\Codex\video-workbench
```
It should handle:
- series architecture
- angle proposals
- video outline
- storyboard logic
- voiceover
- image prompts
- image/audio assets
- editing notes
- publishing copy
It should not be folded into Writing Workbench.

52
docs/invocation-policy.md Normal file
View File

@ -0,0 +1,52 @@
# Invocation Policy
## Formal Output Requires Real Invocation
Formal output includes:
- reviewer report;
- lead writer outline repair;
- lead writer draft;
- specialist analysis used for a user decision.
Formal output must come from a real sub-session, thread, tool invocation, or explicitly approved external execution path.
## Controller May Do
The controller session may:
- prepare context packs;
- create review briefs;
- route source files;
- launch or coordinate sub-sessions;
- summarize returned formal outputs;
- update project records;
- ask the user for decisions.
## Controller Must Not Do
The controller session must not:
- impersonate a reviewer or lead writer;
- create a formal report without real invocation;
- treat a prompt draft as an executed report;
- advance the project after its own recommendation;
- hide uncertainty about missing capability.
## Missing Capability
If a required agent, skill, or runtime is unavailable:
1. Create a supplier ticket in `requirements/ccpe/` or `requirements/skills-vault/`.
2. Set project state to `blocked_waiting_capability`.
3. Stop until the user confirms the capability is ready.
## Simulation
Simulation is allowed only for planning and must be labeled:
```yaml
simulation_only: true
formal_output: false
excluded_from_synthesis: true
```

View File

@ -1,206 +1,104 @@
# Writing Workbench Operating Playbook # Operating Playbook
This playbook explains how to run an article project inside Writing Workbench. ## 1. Start A Project
It is the operational layer between the workspace principles in `WORKBENCH.md` and the concrete project files under `projects/active/`. Start a project only when the user has a Web-generated initial outline.
## 1. When To Start A Project Minimum inputs:
Start a Writing Workbench project only after the user has decided that an idea should enter article production. - lead writer identity;
- initial outline path or pasted outline;
- source material paths;
- working slug;
- the user's instruction to create the project.
Do not use this workspace for: If the user only has source materials or open discussion, stop and keep the work in `knowledge-vault`.
- raw diary capture ## 2. Create The Folder
- 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. Use:
## 2. Project ID
Use this folder pattern:
```text ```text
projects/active/YYYY-MM-DD-aNNN-temp-slug/ projects/YYYY-MM-DD-short-slug/
``` ```
Rules: Copy or create the project files from `templates/article-project/PROJECT_STRUCTURE.md`.
- `YYYY-MM-DD` is the project creation date. Fill these first:
- `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` - `project.md`
- `source-map.md` - `source-map.md`
- `status.md` - `status.md`
- `00-creation-plan/creative-brief.md` - `decision-log.md`
- `00-intake/initial-outline-v1.0.md`
3. Update `indexes/active-projects.md`. ## 3. Prepare For Outline Review
4. If CCPE assets are used, update: The first operational stage is `outline-review-prep`.
- `indexes/ccpe-consumption-map.md` Material processing is a subtask of outline review preparation. It exists because context windows are limited, not because the article has not entered writing.
- `ccpe-consumption/runtime-links.md` when a new reusable asset relationship is discovered
## 4. Minimum Viable Project State For each source, decide the processing method from the source type:
A project is ready for article work when these files are no longer blank: - `思想考古报告` 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.
- `project.md`: identity, intent, target article type, decision gates Always keep source paths in `source-map.md`.
- `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. ## 4. Review Rounds
## 5. Phase Flow A review round starts only when the user names the reviewer or reviewers.
Use this default sequence: Each reviewer gets:
```text ```text
00-creation-plan 02-outline-review/round-NN/reviewers/<reviewer-id>/session.md
01-positioning 02-outline-review/round-NN/reviewers/<reviewer-id>/report.md
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`. The review brief may be prepared by the controller session, but the report must come from the real reviewer sub-session.
Required before drafting: ## 5. User Decision Gate
- positioning is stable enough to write After review, stop and wait for the user.
- 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: The user may provide:
- final article exists in `publish/final.md` - reflection;
- unresolved review issues are either fixed or explicitly waived - accepted and rejected review points;
- metadata is complete when needed - direction for lead writer repair;
- archive destinations are recorded - instruction to run another review;
- instruction to draft a specific part.
## 6. Context Packs Record these in `decision-log.md` and the relevant stage folder.
Use the smallest pack that can support the task. ## 6. Outline Repair
- `lite`: article goal, current artifact, core claims, constraints Lead writer repair starts only after the user gives a repair instruction.
- `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. Versioning:
## 7. Sessions And Reports - 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.
For each writer, reviewer, tribunal member, or modeling session, preserve both: Review reports do not create outline versions by themselves.
- `session.md`: process record ## 7. Drafting
- `report.md`: final result or decision-ready output
The orchestrator should read reports, syntheses, and repair requests before reading full session records. Do not generate a full article unless the user explicitly asks for that exact action.
Use full sessions only when: Default drafting is section-level or chapter-level. Preserve the complete writer session and the resulting draft.
- the report is ambiguous If the writer introduces new cases outside source materials, mark them in `draft-notes.md` or the session record.
- a decision depends on reasoning history
- the user asks to inspect the process
- the next agent needs exact prior discussion details
## 8. Review Rounds ## 8. Publication Boundary
Each review round should preserve: Writing Workbench may keep a local full draft for revision.
- `review-brief.md` The publication copy and release metadata are maintained by the user in `knowledge-vault`, normally under `sayings/`.
- 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. Record the intended or final `knowledge-vault` target path in `publish/knowledge-vault-target.md`.
## 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.

41
docs/project-lifecycle.md Normal file
View File

@ -0,0 +1,41 @@
# Project Lifecycle
## States
Use `status.md` to record the current state. Do not infer state from folder location.
Recommended states:
```text
outline_review_prep
blocked_waiting_capability
blocked_waiting_user_decision
review_round
outline_repair
drafting
revision
local_complete
archived_by_user
```
States may repeat. For example, after several review rounds the user may add new materials and return to `outline_review_prep`.
## Stage Folders
```text
00-intake/
01-materials/
02-outline-review/
03-outline-repair/
04-drafting/
05-revision/
publish/
```
These folders are working areas, not mandatory linear gates.
## Advancement Rule
The workspace may suggest next actions, but only the user advances the project.
Avoid language such as "passed review" or "ready to draft" unless it is quoting the user's decision.

View File

@ -0,0 +1,91 @@
# Rebuild Writing Workbench Implementation Plan
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** Rebuild Writing Workbench as a local tool-calling and process-record workspace that starts from a Web-generated initial outline.
**Architecture:** Preserve the existing Git repository identity and replace the old article-production-runtime scaffold with a smaller documentation and template system. Projects live directly under `projects/`; supplier needs are recorded under `requirements/ccpe/` or `requirements/skills-vault/`.
**Tech Stack:** Markdown documentation, Git, Windows PowerShell for filesystem operations.
---
### Task 1: Clear Old Workspace
**Files:**
- Delete old workspace files and folders except `.git`.
- [x] **Step 1: Verify workspace path**
Run: `Resolve-Path .`
Expected: `C:\Users\wangq\Documents\Codex\writing-workbench`
- [x] **Step 2: Remove old files**
Run a guarded PowerShell removal that refuses to operate outside the expected workspace.
Expected: only `.git` remains.
### Task 2: Create New Skeleton
**Files:**
- Create: `docs/`
- Create: `projects/`
- Create: `requirements/ccpe/`
- Create: `requirements/skills-vault/`
- Create: `templates/article-project/`
- Create: `templates/requirements/`
- [x] **Step 1: Create folders**
Run: `New-Item -ItemType Directory -Force` for each target directory.
Expected: all target directories exist.
### Task 3: Write New Operating Documents
**Files:**
- Create: `README.md`
- Create: `WORKBENCH.md`
- Create: `docs/operating-playbook.md`
- Create: `docs/project-lifecycle.md`
- Create: `docs/invocation-policy.md`
- Create: `docs/capability-requests.md`
- [x] **Step 1: Write documents**
Expected: documents define Web initial outline entry, user-directed advancement, real invocation policy, and capability-request pause behavior.
### Task 4: Write Templates
**Files:**
- Create: `templates/article-project/PROJECT_STRUCTURE.md`
- Create: `templates/article-project/project.md`
- Create: `templates/article-project/source-map.md`
- Create: `templates/article-project/status.md`
- Create: `templates/article-project/decision-log.md`
- Create: `templates/requirements/ccpe-request.md`
- Create: `templates/requirements/skills-vault-request.md`
- [x] **Step 1: Write project and supplier templates**
Expected: templates match the new workflow and do not include old active/completed/runtime assumptions.
### Task 5: Verify
**Files:**
- Inspect all created Markdown files.
- Inspect Git status.
- [ ] **Step 1: List files**
Run: `Get-ChildItem -Recurse -File`
Expected: only rebuilt files are present outside `.git`.
- [ ] **Step 2: Check Git status**
Run: `git status --short`
Expected: old tracked files are deleted and new rebuilt files are untracked or modified.

View File

@ -1,13 +0,0 @@
# Active Projects
No active article projects yet.
When adding a project, record:
- project id
- temporary title
- current phase
- lead writer / style
- source-map path
- next action

View File

@ -1,14 +0,0 @@
# CCPE Consumption Map
This index tracks which CCPE assets were used by Writing Workbench projects.
Record:
- project id
- stage
- CCPE asset
- canonical path
- output path
- issues found
- improvement requests for CCPE System

View File

@ -1,12 +0,0 @@
# Completed Projects
No completed article projects yet.
When completing a project, record:
- project id
- final title
- final essay archive path in Knowledge Vault
- model documents extracted, if any
- CCPE assets triggered, if any

View File

@ -1,16 +0,0 @@
# Extracted Models
This index tracks human-facing model documents produced from article projects.
Final human-facing models should be archived in:
```text
C:\Users\wangq\Documents\Codex\knowledge-vault\rules
```
AI-facing model cards should be promoted through:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\model-cards
```

View File

@ -1 +0,0 @@

View File

@ -1 +0,0 @@

View File

@ -1 +0,0 @@

View File

@ -1 +0,0 @@

View File

@ -1,95 +1,51 @@
# Article Project Structure # Article Project Structure
Use this structure when expanding a new active article project. Use this structure for article projects that enter Writing Workbench after a Web initial outline already exists.
The copyable project skeleton lives at:
```text ```text
templates/article-project/skeleton/ YYYY-MM-DD-short-slug/
```
Create a project with:
```powershell
Copy-Item -Recurse templates\article-project\skeleton projects\active\YYYY-MM-DD-aNNN-temp-slug
```
Then fill `project.md`, `source-map.md`, `status.md`, and `00-creation-plan/creative-brief.md` before dispatching writer or reviewer sessions.
```text
YYYY-MM-DD-aNNN-temp-slug/
project.md project.md
source-map.md source-map.md
status.md status.md
decision-log.md
00-creation-plan/ 00-intake/
creative-brief.md initial-outline-v1.0.md
writer-selection.md intake-note.md
series-position.md
context-pack.md
sessions/
01-positioning/ 01-materials/
premise.md source-links.md
main-writer-sessions/ source-digests/
positioning-final.md compression-notes.md
02-outline/ 02-outline-review/
context-packs/
main-writer-sessions/
outlines/
outline-v1.md
outline-v2.md
outline-final.md
review-rounds/
round-01/ round-01/
review-brief.md review-brief.md
cognitive-imaging/ reviewers/
reviewer-id/
session.md session.md
report.md report.md
zhang-liao/ user-reflection.md
synthesis-for-writer.md
03-outline-repair/
writer-session-v2.0/
session.md session.md
report.md outline-v2.0.md
giant-cognition/ repair-notes.md
session.md
report.md
synthesis.md
repair-request.md
appendix-outline.md
03-drafting/ 04-drafting/
context-packs/ section-sessions/
sessions/ draft-v1.md
chapters/ draft-notes.md
full-draft.md
04-draft-review/ 05-revision/
review-rounds/ revision-sessions/
revision-plan.md draft-v2.md
full-revised.md
05-appendix/
sessions/
appendix-draft.md
appendix-final.md
06-metadata/
metadata-session.md
metadata-draft.md
image-prompt.md
image-url.md
metadata-final.md
07-tribunal/
README.md
08-model-writing/
extraction-brief.md
sessions/
model-draft.md
model-final.md
destination-map.md
publish/ publish/
final.md local-final.md
knowledge-vault-target.md
``` ```
Folders may be created as needed. Do not create empty stage files merely to satisfy the structure.

View File

@ -0,0 +1,7 @@
# Decision Log
Record user decisions that advance, pause, or redirect the project.
| Date | Decision Owner | Decision | Inputs | Downstream Effect |
| --- | --- | --- | --- | --- |
| | user | | | |

View File

@ -0,0 +1,23 @@
# Project
```yaml
project_id:
created:
lead_writer:
writer_style:
working_title:
current_outline_version: "1.0"
status: outline_review_prep
```
## Purpose
## Entry Inputs
- Initial outline:
- Source map:
- Lead writer:
## Current Boundary
This project starts from an existing Web initial outline. It does not perform open-ended idea development.

View File

@ -1,23 +0,0 @@
# Context Pack
## Pack Type
- lite
## Task
## Role Receiving This Pack
## Current Artifact
## Article Goal
## Core Claims
## Required Sources
## Selected Evidence
## Constraints
## Output Request

View File

@ -1,19 +0,0 @@
# Creative Brief
## Article Intention
## Reader
## Core Question
## Core Claim
## Desired Effect
## Must Include
## Must Avoid
## Initial Sources
## First Human Decision Needed

View File

@ -1,11 +0,0 @@
# Series Position
## Series
## Position In Series
## Previous Related Articles
## Next Possible Articles
## Continuity Requirements

View File

@ -1,14 +0,0 @@
# Writer Selection
## Candidate Writer Roles
## Selected Lead Writer
## Reason
## Style Constraints
## CCPE Asset Reference
- Canonical path:
- Local usage note:

View File

@ -1,16 +0,0 @@
# Positioning Final
## Final Premise
## Target Reader
## Main Claim
## Supporting Claims
## Article Boundary
## Approved By User
- Date:
- Notes:

View File

@ -1,13 +0,0 @@
# Premise
## Working Premise
## Reader Problem
## Article Promise
## Central Tension
## Boundary
## Open Questions

View File

@ -1,9 +0,0 @@
# Appendix Outline
## Appendix Purpose
## Candidate Sections
## Relationship To Main Article
## Open Questions

View File

@ -1,16 +0,0 @@
# Outline Final
## Final Title Candidate
## Opening
## Section Outline
## Closing
## Appendix Plan
## User Approval
- Date:
- Notes:

View File

@ -1,13 +0,0 @@
# Outline V1
## Title Candidate
## Opening
## Section Outline
## Closing
## Appendix Need
## Known Risks

View File

@ -1,15 +0,0 @@
# Outline V2
## Change Summary From V1
## Title Candidate
## Opening
## Section Outline
## Closing
## Appendix Need
## Remaining Risks

View File

@ -1,15 +0,0 @@
# Cognitive Imaging Report
## Verdict
## Strongest Parts
## Critical Issues
## Structural Risks
## Missing Context Or Evidence
## Repair Suggestions
## Questions For User

View File

@ -1,3 +0,0 @@
# Cognitive Imaging Session
## Process Record

View File

@ -1,15 +0,0 @@
# Giant Cognition Report
## Verdict
## Strongest Parts
## Critical Issues
## Structural Risks
## Missing Context Or Evidence
## Repair Suggestions
## Questions For User

View File

@ -1,3 +0,0 @@
# Giant Cognition Session
## Process Record

View File

@ -1,13 +0,0 @@
# Repair Request
## Addressed To
## Repair Goal
## Required Changes
## Constraints
## Evidence To Preserve
## Output Request

View File

@ -1,16 +0,0 @@
# Review Brief
## Review Target
## Reviewer Role
## Context Pack
## Review Objectives
## Known Concerns
## Required Output
- `session.md` for process record
- `report.md` for final review result

View File

@ -1,11 +0,0 @@
# Review Synthesis
## Shared Findings
## Conflicting Findings
## Highest Priority Repairs
## User Decisions Needed
## Recommendation

View File

@ -1,15 +0,0 @@
# Zhang Liao Report
## Verdict
## Strongest Parts
## Critical Issues
## Structural Risks
## Missing Context Or Evidence
## Repair Suggestions
## Questions For User

View File

@ -1,3 +0,0 @@
# Zhang Liao Session
## Process Record

View File

@ -1,7 +0,0 @@
# Full Draft
## Draft
## Known Gaps
## Writer Notes

View File

@ -1,7 +0,0 @@
# Full Revised Draft
## Revised Draft
## Change Notes
## Remaining Risks

View File

@ -1,11 +0,0 @@
# Revision Plan
## Review Inputs
## Required Revisions
## Optional Revisions
## User Decisions
## Revision Order

View File

@ -1,5 +0,0 @@
# Appendix Draft
## Draft
## Notes

View File

@ -1,5 +0,0 @@
# Appendix Final
## Final Appendix
## Archive Notes

View File

@ -1,7 +0,0 @@
# Image Prompt
## Prompt
## Constraints
## Negative Requirements

View File

@ -1,7 +0,0 @@
# Image URL
## Final Image URL
## Source
## License Or Usage Note

View File

@ -1,13 +0,0 @@
# Metadata Draft
## Title
## Subtitle
## Description
## Keywords
## Tags
## Categories

View File

@ -1,17 +0,0 @@
# Metadata Final
## Title
## Subtitle
## Description
## Keywords
## Tags
## Categories
## Image Prompt
## Image URL

View File

@ -1,3 +0,0 @@
# Metadata Session
## Process Record

View File

@ -1,11 +0,0 @@
# Tribunal
Use this stage only when the article needs multi-role judgment beyond normal review.
Do not run tribunal by default. Record the user decision in `status.md`.
## Inputs
## Roles
## Outputs

View File

@ -1,12 +0,0 @@
# Destination Map
## Human-Facing Archive
- Knowledge Vault path:
## AI-Facing Promotion Candidate
- CCPE System path:
- Promotion status:
## Index Updates

View File

@ -1,14 +0,0 @@
# Extraction Brief
## Source Article
## Candidate Human Model
## Extraction Goal
## Boundary
## Destination
- Knowledge Vault rules path:
- CCPE System potential:

View File

@ -1,13 +0,0 @@
# Model Draft
## Model Name
## Model Definition
## Core Structure
## Mechanism
## Applicable Scenarios
## Non-Applicable Scenarios

View File

@ -1,21 +0,0 @@
# Model Final
## Model Name
## Source Article
## Model Definition
## Core Structure
## Mechanism
## Applicable Scenarios
## Non-Applicable Scenarios
## Version Relationship
## Derivative Models
## AI Model Card Potential

View File

@ -1,29 +0,0 @@
# Project
## Identity
- Project ID:
- Temporary title:
- Final title:
- Status: active
- Current phase: 00-creation-plan
- Created:
- Last updated:
## Intent
## Target Article Type
## Lead Writer / Style
## Series Position
## Human Decision Gates
- Creation plan approval:
- Positioning approval:
- Outline approval:
- Draft repair approval:
- Publish approval:
## Notes

View File

@ -1,9 +0,0 @@
# Final Article
## Final Title
## Article
## Archive Destination
## Publication Notes

View File

@ -1,15 +0,0 @@
# Source Map
## Knowledge Vault Sources
## CCPE Sources
## External Sources
## Selected Materials
## Source Policy
This project references source files unless the user explicitly asks to copy selected excerpts into local context packs.
## Open Source Questions

View File

@ -1,19 +0,0 @@
# Status
## Current State
- Phase: 00-creation-plan
- Status: active
- Last updated:
## Completed
## Open Decisions
## Next Actions
## Blockers
## Phase Notes
Record skipped phases, waived review risks, archive destinations, and CCPE follow-up requests here.

View File

@ -0,0 +1,20 @@
# Source Map
## Source Policy
Original source files remain authoritative. Project material files are derived working aids.
## Initial Outline
- Path:
- Version: 1.0
## Source Materials
| Source | Type | Path | Processing Plan |
| --- | --- | --- | --- |
| | | | |
## Publication Target
- Knowledge Vault final essay path:

View File

@ -0,0 +1,17 @@
# Status
```yaml
current_state: outline_review_prep
waiting_on: user
next_allowed_actions:
- user names reviewers
- prepare material compression
- create capability request if required
```
## Completed
## Open Decisions
## Next Action

View File

@ -1,24 +0,0 @@
# Context Pack
## Pack Type
- lite / standard / deep
## Task
## Role Receiving This Pack
## Current Artifact
## Article Goal
## Core Claims
## Required Sources
## Selected Evidence
## Constraints
## Output Request

View File

@ -1,22 +0,0 @@
# Human Model Document
## Model Name
## Source Article
## Model Definition
## Core Structure
## Mechanism
## Applicable Scenarios
## Non-Applicable Scenarios
## Version Relationship
## Derivative Models
## AI Model Card Potential

View File

@ -1,18 +0,0 @@
# Metadata Request
## Article Path
## Target Output
- title
- subtitle
- keywords
- description
- tags
- categories
- image prompt
## Classification Rules
## Notes

View File

@ -1,24 +0,0 @@
# Project
## Identity
- Project ID:
- Temporary title:
- Final title:
- Status: active
- Current phase:
- Created:
- Last updated:
## Intent
## Target Article Type
## Lead Writer / Style
## Series Position
## Human Decision Gates
## Notes

View File

@ -0,0 +1,24 @@
# CCPE Capability Request
```yaml
request_id:
created:
requested_by_project:
target_supplier: ccpe-system
status: requested
```
## Missing Capability
## Why Writing Workbench Needs It
## Expected Inputs
## Expected Outputs
## Invocation Requirements
## Authority And Safety
## Acceptance Check

View File

@ -0,0 +1,22 @@
# Skills-Vault Capability Request
```yaml
request_id:
created:
requested_by_project:
target_supplier: skills-vault
status: requested
```
## Missing Automation
## Input Files
## Output Files
## Side Effects
## CLI Or Skill Behavior
## Validation Check

View File

@ -1,17 +0,0 @@
# Review Brief
## Review Target
## Reviewer Role
## Context Pack
## Review Objectives
## Known Concerns
## Required Output
- `session.md` for process record
- `report.md` for final review result

View File

@ -1,16 +0,0 @@
# Review Report
## Verdict
## Strongest Parts
## Critical Issues
## Structural Risks
## Missing Context Or Evidence
## Repair Suggestions
## Questions For User

View File

@ -1,14 +0,0 @@
# Source Map
## Knowledge Vault Sources
## CCPE Sources
## External Sources
## Selected Materials
## Source Policy
This project references source files unless explicitly instructed to copy selected excerpts into local context packs.