179 lines
4.6 KiB
Markdown
179 lines
4.6 KiB
Markdown
# Deep Creation Automation Boundary
|
|
|
|
```yaml
|
|
status: analysis-draft
|
|
canonical: false
|
|
created: 2026-06-15
|
|
scope: ccpe-system / writing-workbench / knowledge-vault
|
|
classification: boundary-analysis
|
|
```
|
|
|
|
## 1. Purpose
|
|
|
|
This draft records the current boundary for deep creation workflows.
|
|
|
|
It is not a canonical Runtime. It is an analysis document for later protocol updates.
|
|
|
|
## 2. Core Judgment
|
|
|
|
Deep creation can be supported by CCPE, but it should not be prematurely automated.
|
|
|
|
The user's earlier Web-based workflow worked because the user acted as the implicit runtime:
|
|
|
|
```text
|
|
choosing which expert to invoke
|
|
judging when context was polluted
|
|
deciding which critique mattered
|
|
deciding when to revise, stop, restart, or write
|
|
holding the final responsibility for taste, stance, and publication
|
|
```
|
|
|
|
When moved into Codex or another agentic environment, those hidden decisions must become explicit gates, records, and invocation boundaries. That is a governance problem, not a simple automation problem.
|
|
|
|
## 3. Not Automatically Automatable
|
|
|
|
Do not default to automating:
|
|
|
|
```text
|
|
article premise selection
|
|
whether an idea is worth writing
|
|
final thesis judgment
|
|
which review comments to accept
|
|
whether a structure carries the intended argument
|
|
whether a reviewer is producing useful tension or style noise
|
|
when to restart context
|
|
when a model should be promoted
|
|
when to enter full drafting
|
|
whether to publish
|
|
```
|
|
|
|
These are high-uncertainty judgment tasks. Agents may advise; the user directs.
|
|
|
|
## 4. Suitable for Context Assistance
|
|
|
|
CCPE may support:
|
|
|
|
```text
|
|
source digest drafting
|
|
source map preparation
|
|
premise context pack preparation
|
|
outline-aligned context pack preparation
|
|
role-specific dispatch packet drafting
|
|
material gap identification
|
|
conflict summary for user decision
|
|
repair instruction drafting after user decision
|
|
outline versioning rules
|
|
returned-output record templates
|
|
```
|
|
|
|
These tasks prepare context and preserve traceability. They do not replace human judgment.
|
|
|
|
## 5. Suitable for Automation
|
|
|
|
Automation is safer when the task is stable, low-risk, and verifiable:
|
|
|
|
```text
|
|
file naming
|
|
markdown heading repair
|
|
format conversion
|
|
template expansion
|
|
batch export
|
|
asset manifest generation
|
|
TTS batch preparation
|
|
image prompt list export
|
|
metadata formatting
|
|
archive packaging
|
|
```
|
|
|
|
These should usually belong in `skills-vault` as automation Skill source, with CCPE registration only when a CCPE Agent or Runtime depends on them.
|
|
|
|
## 6. Formal Participant Boundary
|
|
|
|
Canonical writer and reviewer output must come from real invocation.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Han Yu lead writer output
|
|
Zhang Liao red-team review
|
|
Giant Cognition macro-model review
|
|
Cognitive Imaging inspection
|
|
```
|
|
|
|
The controller session may prepare context and synthesize returned outputs. It must not impersonate the formal participant.
|
|
|
|
If invocation is not available, the workflow should produce:
|
|
|
|
```text
|
|
agent-invocation-packet.md
|
|
prompt-to-send.md
|
|
blocked_waiting_for_participant_output
|
|
```
|
|
|
|
## 7. Current Writing Workflow Boundary
|
|
|
|
For `writing-workbench`, the current expected flow is narrower:
|
|
|
|
```text
|
|
Web discussion and source digestion
|
|
-> Web initial outline v1.0
|
|
-> Writing Workbench project
|
|
-> outline review preparation
|
|
-> user-named reviewer invocation
|
|
-> user reflection and decision
|
|
-> user-directed lead writer repair
|
|
-> revised outline v2.0+
|
|
-> user-directed section / chapter drafting
|
|
```
|
|
|
|
The user decides every stage transition.
|
|
|
|
## 8. CCPE Supplier Role
|
|
|
|
CCPE should supply:
|
|
|
|
```text
|
|
lead writer Lite prompts or Agent specs
|
|
reviewer Lite prompts or Agent specs
|
|
invocation packet protocols
|
|
returned-output record templates
|
|
review report contracts
|
|
context preparation rules
|
|
source fidelity rules
|
|
evaluation rubrics
|
|
repair instruction builder rules
|
|
```
|
|
|
|
CCPE should not store one article's project records, reviewer sessions, draft chapters, or decision logs.
|
|
|
|
## 9. Stop Rule
|
|
|
|
Stop once the smallest useful artifact has been produced.
|
|
|
|
For deep creation, useful stopping points include:
|
|
|
|
```text
|
|
context pack ready for user review
|
|
prompt-to-send ready for real participant invocation
|
|
real participant output returned and recorded
|
|
conflict summary ready for user decision
|
|
repair instruction ready after user decision
|
|
revised outline returned and versioned
|
|
```
|
|
|
|
Do not continue into the next creative stage merely because another artifact can be generated.
|
|
|
|
## 10. Open Follow-Up
|
|
|
|
Future CCPE work may turn this draft into:
|
|
|
|
```text
|
|
ccpe-protocol deep creation boundary rule
|
|
writing-workbench supplier intake template
|
|
outline-review-and-repair runtime spec
|
|
reviewer invocation packet template
|
|
lead writer repair packet template
|
|
```
|
|
|
|
Promotion should happen only after concrete project requirements exist.
|