Refine CCPE boundaries and supplier governance

.codex/skills/ccpe-forge/SKILL.md

@@ -11,19 +11,32 @@ CCPE Forge is the operating Skill for the CCPE System.
 
 It is used to create, audit, refactor, and extract AI artifacts within the CCPE framework.
 
-CCPE Forge supports six artifact families:
+CCPE Forge supports eight CCPE-owned artifact families:
 
 ```text
 1. CCPE-Lite Prompt Cards
 2. CCPE-Agent Specs
-3. CCPE-Skill Specs
+3. CCPE-Committee Specs
-4. CCPE-Runtime Specs
+4. CCPE-Skill Specs
-5. Model Cards
+5. CCPE-Runtime Specs
-6. Model Index entries
+6. Model Cards
+7. Model Index entries
+8. Integration Registrations
 ```
 
 It also handles Hybrid artifacts that combine several of these forms.
 
+It must also recognize non-CCPE ownership categories:
+
+```text
+Project Runbook
+Project Execution Record
+automation Skill source
+external tool / MCP / CLI / API
+production application implementation
+out of scope
+```
+
 ## 2. Core Mission
 
 Use this Skill to help the user:
@@ -37,6 +50,8 @@ Generate and maintain Model Cards.
 Generate and maintain Model Index entries.
 Design human-in-the-loop workflows.
 Separate deep cognitive work from safe automation.
+Supply concrete project repositories after they raise real requirements.
+Register external capabilities without copying their implementation source.
 ```
 
 The Skill's job is not merely to generate better prompts.
@@ -95,6 +110,17 @@ CCPE Forge has four operating modes:
 4. Model Mining Mode
 ```
 
+It also has two cross-cutting modes used before or inside the four major modes:
+
+```text
+Registrar Mode
+Runtime Designer Mode
+```
+
+Registrar Mode is used when CCPE needs to record an external capability dependency such as a `skills-vault` automation skill, MCP server, CLI tool, API service, installed local capability, or agentic development framework.
+
+Runtime Designer Mode is used when a workflow may require a Runtime spec. It must first prove that Runtime is needed and must choose Lite, Standard, or Full by evidence.
+
 Select a mode before acting.
 
 If the user request spans multiple modes, run them in this order:
@@ -110,6 +136,63 @@ Exception:
 
 If the task starts from a long article or model source, run Model Mining Mode first.
 
+## 5.1 Mandatory Startup Gates
+
+Before any Creator, Auditor, Refactor, Model Mining, Registrar, or Runtime Designer work, run these gates:
+
+```text
+1. Classification First Gate
+2. Boundary Check
+3. Supplier Intake Check
+4. Depth vs Automation Check
+5. No-Simulation Check when participants are involved
+```
+
+Classification First Gate must choose from:
+
+```text
+CCPE-Lite
+CCPE-Agent
+CCPE-Committee
+CCPE-Skill
+CCPE-Runtime
+Model Card
+Model Index
+Integration Registration
+Project Runbook
+Project Execution Record
+automation Skill source
+external tool / MCP / CLI / API
+production application implementation
+Hybrid Artifact
+Out of Scope
+```
+
+Boundary Check must route ownership:
+
+```text
+CCPE:
+  prompt cards, agent specs, committee specs, CCPE-Skill specs, runtimes, models, indexes, registrations
+
+project repositories:
+  runbooks, project context packs, returned outputs, drafts, decision records, process logs
+
+skills-vault:
+  automation Skill source, scripts, tests, fixtures, installation notes
+
+development application repositories:
+  production agent implementation, framework adapters, server runtime, persistence, deployment
+```
+
+Supplier Intake Check:
+
+```text
+For project-facing work, prefer concrete project requirements over CCPE-internal speculation.
+Do not design a full workflow before a project has a real use case or the user explicitly asks for system-building.
+```
+
+If the artifact does not belong in CCPE, recommend the correct repository or produce an Integration Registration plan.
+
 ## 6. Mode 1: Creator Mode
 
 ### 6.1 Use Creator Mode When
@@ -120,10 +203,12 @@ Use Creator Mode when the user wants to create:
 A new expert prompt
 A new custom GPT / Gem / Claude assistant
 A new durable Agent Spec
+A new Committee Spec
 A new Skill
 A new Runtime workflow
 A new Model Card
 A new Model Index entry
+A new Integration Registration
 A new committee or multi-agent workflow
 ```
 
@@ -157,6 +242,8 @@ Where will it run?
 Is this a Web-style single expert, Codex-callable method, durable workflow role, or Runtime?
 Will the user manually coordinate other agents, or should the system automate routing?
 Is it Lite, Agent, Skill, Runtime, Model Card, Model Index, or Hybrid?
+Does it belong in CCPE, a project repository, skills-vault, or a development application repository?
+Is it a development agent for local work or a production/business agent for a deployed system?
 Is it Expert, Workshop, Automation, or Hybrid Mode?
 Is it Depth-Oriented, Automation-Oriented, or Hybrid?
 Does it involve tools?
@@ -172,6 +259,8 @@ What final files should be generated?
 
 For mature or planned deep expert assistants, do not automatically generate Agent, Skill, and Runtime layers. Choose layers from scenario evidence.
 
+For production/business agents, CCPE may generate specifications and governance contracts, but should not implement the server runtime or framework adapter unless the user is working inside the target development project.
+
 ### 6.4 Creator Mode Output
 
 Creator Mode should produce:
@@ -235,6 +324,8 @@ Potential Skills
 Runtime needs
 Current usage scenario
 Planned usage scenario
+Repository ownership
+Supplier or consumer relationship
 Lite preservation need
 Codex Skill invocation need
 Tool and authority gaps
@@ -569,6 +660,103 @@ Human review questions
 
 Important Model Cards should remain draft or candidate until the user confirms them.
 
+## 9.6 Cross-Cutting Mode: Registrar Mode
+
+### 9.6.1 Use Registrar Mode When
+
+Use Registrar Mode when CCPE depends on an external capability that it does not own:
+
+```text
+skills-vault automation skill
+MCP server
+CLI tool
+API service
+installed local skill
+platform-specific capability
+agentic development framework
+```
+
+### 9.6.2 Registrar Mode Rule
+
+Do not copy implementation source into CCPE.
+
+Produce or propose an Integration Registration that records:
+
+```text
+name
+integration_type
+canonical_implementation
+installed_path_or_endpoint
+used_by
+authority
+allowed_operations
+forbidden_operations
+side_effects
+security_notes
+validation
+failure_behavior
+status
+version
+```
+
+Only create registration files when the capability is actually used by a CCPE Agent, Runtime, Committee, Skill, or project requirement.
+
+## 9.7 Cross-Cutting Mode: Runtime Designer Mode
+
+### 9.7.1 Use Runtime Designer Mode When
+
+Use Runtime Designer Mode when a request may involve stages, participants, state, handoff, tools, files, human gates, synthesis, archival, or downstream dependency.
+
+### 9.7.2 Runtime Designer Startup
+
+Before creating a Runtime, prove that Runtime is needed.
+
+Classify maturity:
+
+```text
+Lite
+Standard
+Full
+```
+
+Default to Lite.
+
+### 9.7.3 Runtime Designer Must Define
+
+```text
+runtime_orientation: interactive / automation / hybrid
+mode: lite / standard / full
+qpi_class
+participants
+state_protocol
+human_gates
+invocation_authenticity
+simulation_labeling
+authority_matrix
+tool_permissions
+source_fidelity
+evaluation_level
+stop_rule
+handoff_rules
+related_models
+related_skills
+related_integrations
+```
+
+### 9.7.4 Runtime Designer Non-Goals
+
+Do not create a Full Runtime when the work is:
+
+```text
+one-off
+low risk
+single-participant
+not dependent on formal process evidence
+better handled by user-directed interaction
+```
+
+For deep creation, Runtime should often act as an interactive support protocol rather than an autonomous production pipeline.
+
 ## 10. Classification First Rule
 
 Before generating any final artifact, classify it.
@@ -578,11 +766,18 @@ Use:
 ```text
 CCPE-Lite
 CCPE-Agent
+CCPE-Committee
 CCPE-Skill
 CCPE-Runtime
 Model Card
 Model Index
+Integration Registration
+Project Runbook
+Project Execution Record
+automation Skill source
+external tool / MCP / CLI / API
 Hybrid Artifact
+Out of Scope
 ```
 
 For Hybrid artifacts, identify:
@@ -730,6 +925,8 @@ Transformation Skill
 Knowledge Management Skill
 ```
 
+If the capability is primarily a deterministic script-backed automation tool, route implementation source to `skills-vault`. CCPE should create only a CCPE-Skill spec when the capability is a method, cognitive procedure, workflow contract, or evaluation rule; otherwise create or propose an Integration Registration when a CCPE artifact depends on the external tool.
+
 ## 17. Runtime Rule
 
 Recommend Runtime only when needed.
@@ -751,6 +948,72 @@ Archival
 
 Do not create Runtime for a simple expert prompt.
 
+## 17.1 Agent Invocation / No Simulation Rule
+
+When a Runtime, Agent, workflow, or cross-workspace handoff depends on a CCPE participant, define the invocation boundary before claiming the participant has produced output.
+
+Use an Agent Invocation Packet or equivalent dispatch record whenever the workflow invokes:
+
+```text
+CCPE-Lite prompt
+CCPE-Agent spec
+CCPE-Skill spec
+CCPE-Runtime node
+Native platform agent
+External GPT / Gemini / Claude participant
+Human-run participant
+```
+
+The packet must identify:
+
+```text
+canonical_artifact_path
+invocation_mode
+role_integrity_requirement
+task_context
+input_files
+context_files
+output_contract
+continuity_policy
+session_logging
+return_path
+no_simulation_requirement
+```
+
+Required invocation modes:
+
+```text
+full_prompt_paste
+prompt_path_reference
+native_agent_id
+local_skill_execution
+manual_handoff
+```
+
+Hard rule:
+
+```text
+The runtime operator must not simulate a canonical participant's formal output.
+```
+
+If the participant cannot be truly invoked, the Runtime must stop after generating the invocation packet or `prompt-to-send.md` and mark:
+
+```text
+blocked_waiting_for_participant_output
+```
+
+If the user explicitly requests a simulated output, it must be labeled:
+
+```text
+simulation-only
+excluded-from-synthesis
+not-a-formal-report
+```
+
+For local Skill execution, the operator may execute the Skill only when the Skill spec is explicit and the run writes a Skill execution record identifying the canonical Skill path, inputs, outputs, completed procedure steps, validation checks, and skipped or failed steps.
+
+When creating or auditing a Runtime, missing invocation packets, missing prompt-to-send paths, or absent no-simulation requirements are structural defects.
+
 ## 18. Human Confirmation Rule
 
 Require human confirmation before:

.codex/skills/ccpe-forge/references/ccpe-forge-workflows.md

@@ -13,6 +13,8 @@ Refactor Mode
 Model Mining Mode
 ```
 
+It also applies to cross-cutting Registrar and Runtime Designer work.
+
 The purpose is to keep CCPE Forge systematic without making it bureaucratic.
 
 ## 2. Universal Workflow
@@ -21,21 +23,25 @@ All CCPE Forge work should follow this high-level sequence:
 
 ```text
 1. Intake
-2. Classification
+2. Classification First Gate
-3. Operating Mode Assessment
+3. Boundary Check
-4. Depth vs Automation Assessment
+4. Supplier Intake Check
-5. Embedded Component Detection
+5. Operating Mode Assessment
-6. Risk and Human Decision Gate Check
+6. Depth vs Automation Assessment
-7. Mode-Specific Work
+7. Embedded Component Detection
-8. Proposed Outputs
+8. Risk and Human Decision Gate Check
-9. Validation
+9. Mode-Specific Work
-10. Final Response
+10. Proposed Outputs
+11. Validation
+12. Final Response
 ```
 
 Do not skip classification.
 
 Do not write final artifacts before understanding what kind of artifact is needed.
 
+Do not assume CCPE owns the artifact just because it is useful. Some useful assets belong in project repositories, `skills-vault`, external tool registries, or development application repositories.
+
 ## 3. Intake
 
 During intake, determine what the user has provided and what they want.
@@ -47,6 +53,9 @@ Existing prompt
 Existing agent
 Existing Skill
 Existing Runtime
+Existing project runbook
+Existing automation Skill source
+External tool or API dependency
 Long-form essay
 Article draft
 Model description
@@ -71,6 +80,8 @@ Update Model Index
 Prepare for Codex
 Prepare for GPT / Gem
 Prepare for Claude Code / OpenClaw
+Prepare for LangGraph / CrewAI / deployed application use
+Register external capability
 ```
 
 ## 4. Classification
@@ -80,11 +91,29 @@ Classify the artifact or request as one or more of:
 ```text
 CCPE-Lite
 CCPE-Agent
+CCPE-Committee
 CCPE-Skill
 CCPE-Runtime
 Model Card
 Model Index
+Integration Registration
+Project Runbook
+Project Execution Record
+automation Skill source
+external tool / MCP / CLI / API
 Hybrid Artifact
+Out of Scope
+```
+
+Then decide ownership:
+
+```text
+CCPE-owned
+Project-owned
+skills-vault-owned
+development-application-owned
+external capability to register
+out of scope
 ```
 
 For Hybrid artifacts, identify:

.codex/skills/ccpe-forge/references/depth-vs-automation-rules.md

@@ -12,6 +12,8 @@ Some exist to automate execution.
 
 Many of the user's most valuable workflows are hybrid: human-led depth with automated support.
 
+This distinction also decides repository ownership. Depth and cognitive architecture usually belong in CCPE or project discussions. Deterministic automation implementation belongs in `skills-vault`. Concrete project execution records belong in the project repository.
+
 ## 2. Core Distinction
 
 The key distinction is:
@@ -51,6 +53,8 @@ Review of user-authored models
 High-uncertainty research synthesis
 ```
 
+Deep creation, such as article premise formation, outline judgment, and authorial decision-making, is Depth-Oriented unless a concrete project requirement proves that a smaller operational piece is stable enough to automate.
+
 ### 3.3 Typical Artifact Types
 
 Depth-Oriented work often uses:

AGENTS.md

@@ -10,6 +10,10 @@ The project is designed for use with Codex and related agentic coding or knowled
 
 This workspace should be treated as a living engineering system, not merely a collection of prompts.
 
+CCPE System is a supplier and architecture forge for the user's work projects. Concrete projects such as `writing-workbench`, `knowledge-vault`, `video-workbench`, and future `work-projects` should provide actual requirements first; CCPE supplies the relevant Prompt Cards, Agent Specs, Runtime protocols, Model Cards, evaluation rubrics, invocation contracts, and integration registrations.
+
+CCPE may design both development agents for the user's own work and production/business agents for deployed systems. For production systems, CCPE owns the specification and governance layer only. The target development project owns framework implementation, LangGraph/CrewAI or similar adapters, server deployment, production state, monitoring, and application-specific runtime behavior.
+
 ## 2. Primary Mission
 
 When working in this repository, assist the user in building and using the CCPE System.
@@ -50,6 +54,19 @@ The main tasks are:
    * Update Model Index
    * Identify possible Agent or Skill conversions
 
+5. Supply assets to project repositories:
+
+   * Read concrete requirement files from project workbenches when provided
+   * Build only the CCPE assets required by those requirements
+   * Avoid inventing project execution workflows before a project asks for them
+   * Keep project runbooks, process records, returned outputs, drafts, and decision logs in the project repository
+
+6. Register external capabilities:
+
+   * Record architecture dependencies on `skills-vault`, MCP servers, CLI tools, APIs, or installed local capabilities
+   * Do not copy external implementation source into CCPE
+   * Capture authority, allowed operations, validation, failure behavior, and known consumers
+
 ## 3. Core Principle
 
 Always classify before creating, auditing, or refactoring.
@@ -61,9 +78,15 @@ CCPE-Lite
 CCPE-Agent
 CCPE-Skill
 CCPE-Runtime
+CCPE-Committee
 Model Card
 Model Index
+Integration Registration
+Project Runbook
+automation Skill source
+external tool / MCP / CLI / API
 Hybrid Artifact
+Out of Scope
 ```
 
 If the artifact is hybrid, identify its components.
@@ -79,6 +102,44 @@ Cognitive Imaging Specialist
 + possible Runtime node in review committee
 ```
 
+### 3.1 Boundary Check Before Work
+
+After classification, determine whether the artifact belongs in CCPE.
+
+Use this routing:
+
+```text
+CCPE owns:
+- CCPE-Lite prompt cards
+- durable Agent Specs
+- Committees
+- CCPE-Skill specs for cognitive, method, workflow, or evaluation capabilities
+- Runtime specs
+- Model Cards
+- Model Index entries
+- external capability registrations
+
+Project repositories own:
+- project runbooks
+- project-specific execution records
+- article materials and drafts
+- returned participant reports for one project
+- user decision logs
+- publication metadata
+
+skills-vault owns:
+- automation Skill source
+- installable tool skills
+- scripts, tests, fixtures, examples, and install notes
+
+development application repositories own:
+- deployed production agent implementation
+- LangGraph, CrewAI, or other framework adapters
+- server runtime, persistence, monitoring, and application operations
+```
+
+Do not migrate project runbooks, automation Skill source, MCP implementations, or production application code into CCPE. If a CCPE Agent or Runtime depends on such a capability, create or propose an Integration Registration instead.
+
 ## 4. CCPE Artifact Types
 
 ### 4.1 CCPE-Lite
@@ -653,7 +714,9 @@ agents/committees/
 
 ### 11.8 `skills/`
 
-Stores finalized reusable skills.
+Stores finalized reusable CCPE-Skill specs.
+
+These are cognitive, method, workflow, evaluation, transformation, or knowledge-management capability specifications. They are not the canonical source for deterministic automation Skill implementation.
 
 Subdirectories:
 
@@ -664,6 +727,8 @@ skills/workflow/
 skills/evaluation/
 ```
 
+If a capability is primarily script-backed automation, its implementation source belongs in `skills-vault`. CCPE should register it only when a CCPE Agent, Committee, Skill, or Runtime formally depends on it.
+
 ### 11.9 `runtimes/`
 
 Stores workflow and runtime protocols.
@@ -702,6 +767,21 @@ model-usage-map.md
 extraction-log.md
 ```
 
+### 11.12 `integrations/`
+
+Stores architecture registrations for external capabilities only when concrete registration files are needed.
+
+Future subdirectories may include:
+
+```text
+integrations/skills-vault/
+integrations/mcp/
+integrations/cli-tools/
+integrations/api-services/
+```
+
+Do not create these directories merely because the category exists. Create them when a CCPE artifact or a project requirement needs a real registration.
+
 ## 12. Output Standards
 
 When producing analysis, use the following structure when relevant:
@@ -793,6 +873,62 @@ Do not create automation protocols that exceed the user's stated intent.
 
 Do not assume full autonomy when the work is depth-oriented.
 
+### 14.1 Agent Invocation and No-Simulation Safety
+
+When a Runtime, Agent, or cross-workspace workflow depends on a CCPE participant, define a real invocation boundary before accepting that participant's output.
+
+Use an Agent Invocation Packet or equivalent dispatch record for:
+
+```text
+CCPE-Lite prompt
+CCPE-Agent spec
+CCPE-Skill spec
+CCPE-Runtime node
+Native platform agent
+External GPT / Gemini / Claude participant
+Human-run participant
+```
+
+The packet must include:
+
+```text
+canonical_artifact_path
+invocation_mode
+role_integrity_requirement
+task_context
+input_files
+context_files
+output_contract
+continuity_policy
+session_logging
+return_path
+no_simulation_requirement
+```
+
+Hard rule:
+
+```text
+Do not simulate canonical participant output.
+```
+
+If a participant cannot be truly invoked, stop after producing the invocation packet or `prompt-to-send.md`, mark the stage as:
+
+```text
+blocked_waiting_for_participant_output
+```
+
+and wait for real returned output.
+
+If the user explicitly asks for simulation, label it:
+
+```text
+simulation-only
+excluded-from-synthesis
+not-a-formal-report
+```
+
+For local Skill execution, write a Skill execution record that identifies the canonical Skill path, input files, output files, completed procedure steps, validation checks, and skipped or failed steps.
+
 ## 15. Model Mining Rules
 
 When extracting models from articles:

PROJECTS.md

@@ -0,0 +1,63 @@
+# Project Relationships
+
+This file is the local project map for CCPE System. It exists so future sessions understand what this repository supplies, what it consumes, and which neighboring repository owns each kind of asset.
+
+## Local Identity
+
+`ccpe-system` is the AI artifact architecture forge and supplier workspace.
+
+It designs, audits, refactors, registers, and maintains:
+
+- CCPE-Lite prompt cards
+- Agent Specs
+- Committee Specs
+- CCPE-Skill Specs
+- Runtime Specs
+- Model Cards
+- Model Index entries
+- invocation protocols
+- evaluation rubrics
+- external capability registrations
+
+It does not own concrete project execution records, deterministic automation source code, or deployed production application runtime.
+
+## Neighboring Projects
+
+| Project | Relationship To CCPE System | CCPE Consumes | CCPE Produces |
+| --- | --- | --- | --- |
+| `knowledge-vault` | Upstream knowledge, source archive, discussion memory, and human-readable rule layer | prompt archives, model source discussions, articles, viewpoint-development requirements, feedback from knowledge workflows | canonical AI asset specs, model cards, invocation protocols, runtime specs when reusable |
+| `writing-workbench` | Client project workspace for article work after an initial outline exists | capability requests under `requirements/ccpe/`, concrete writing workflow needs, feedback from real use | lead writer agents, reviewer agents, invocation contracts, context-preparation rules, review and repair protocols |
+| `video-workbench` | Future client workspace for dimensional output and multimodal production | capability requests when the project becomes active | runtime specs, agent specs, model usage rules, and integration registrations for video production support |
+| `skills-vault` | Supplier of deterministic automation Skill source | automation skill metadata, installed capability paths, validation and safety notes | integration registrations and dependency contracts only when CCPE artifacts depend on those tools |
+| `work-projects` | Concrete software/customer/experimental development workspace | production or business agent requirements, framework constraints, deployment needs | agent specs, capability contracts, evaluation rubrics, and governance notes for implementation in the target project |
+
+## Boundary Rules
+
+- CCPE supplies reusable AI architecture assets; project repositories run concrete projects.
+- Project-specific runbooks, process records, returned participant outputs, drafts, decision logs, and publication metadata stay in the project repository.
+- Deterministic automation implementation source belongs in `skills-vault`.
+- Production/business agent implementation belongs in the target development project, especially when constrained by LangGraph, CrewAI, server deployment, persistence, or monitoring.
+- CCPE may register external capabilities, but it does not copy their implementation source.
+- Missing capabilities should be expressed as project requirements first, then classified by CCPE.
+
+## Practical Rule
+
+CCPE is a supplier and architecture forge:
+
+```text
+knowledge-vault provides sources, discussions, and long-term memory.
+writing-workbench and video-workbench provide concrete workflow requirements.
+skills-vault provides deterministic automation tools.
+work-projects implements deployed systems.
+ccpe-system supplies agents, protocols, model assets, runtime specs, and registrations.
+```
+
+## Status Rule
+
+Asset status should be expressed by metadata, reports, or indexes:
+
+```text
+active / maintained / reference / superseded / deprecated / archived
+```
+
+Do not infer status from whether an artifact lives in a historical-looking folder. Some older assets remain active references until a concrete replacement is confirmed.

README.md

@@ -8,6 +8,10 @@ CCPE originally emerged from advanced Prompt Engineering. The new CCPE System ex
 
 Its purpose is to help transform AI from a one-off responder into a reusable, testable, composable, collaborative, and maintainable task-execution system.
 
+CCPE System is also a supplier workspace for the user's local work projects. Project workbenches such as `writing-workbench`, `knowledge-vault`, `video-workbench`, and future `work-projects` should raise concrete requirements first; CCPE then supplies the appropriate Prompt Cards, Agent Specs, Runtime protocols, Model Cards, evaluation rules, invocation contracts, or integration registrations.
+
+CCPE is not the runtime framework for deployed production systems. For production or business agents that will run inside LangGraph, CrewAI, a server application, or another agentic framework, CCPE may design and govern the agent specification, but implementation, deployment, service state, framework adapters, and production operations belong to the concrete development project.
+
 ## 2. Core Definition
 
 **CCPE is a context protocol engineering framework for constructing, auditing, and maintaining AI Prompt, Agent, Skill, and Agentic Workflow systems.**
@@ -48,6 +52,46 @@ The first job of CCPE is classification.
 The second job is structural diagnosis.
 The third job is creation or refactoring.
 
+### 3.1 Repository Boundary
+
+CCPE owns architecture, classification, and reusable cognitive assets. It does not own every execution artifact that those assets may produce.
+
+```text
+CCPE System
+= architecture forge
++ cognitive model registry
++ prompt / agent / skill / runtime specification workspace
++ external capability registration center
+
+Project workbenches / vaults
+= concrete project execution spaces
++ runbooks
++ project-specific process records
++ article materials
++ drafts
++ returned participant outputs
++ user decision records
+
+skills-vault
+= automation skill source repository
++ installable tool skills
++ scripts
++ tests
++ fixtures
++ installation notes
+```
+
+Business rule:
+
+```text
+CCPE designs who does what, why, under what authority, and with what evaluation.
+Project repositories execute concrete work.
+skills-vault implements repeatable automation actions.
+Production application repositories implement deployable agentic systems.
+```
+
+CCPE may design both development agents for the user's own work and production/business agents for deployed systems. Production/business agents should be exported or adapted into the target application project; CCPE should not become the server runtime or application framework.
+
 ## 4. Core Artifact Types
 
 ### 4.1 CCPE-Lite
@@ -95,7 +139,21 @@ Typical examples:
 
 CCPE-Agent is not limited to multi-agent systems. A single agent may also need an Agent Spec when it becomes a long-term, composable, or evaluable work unit.
 
-### 4.3 CCPE-Skill
+### 4.3 CCPE-Committee
+
+CCPE-Committee is a fixed multi-agent judgment or review structure.
+
+Use it when:
+
+* Several roles must preserve independent judgment
+* Role tension matters
+* Reports must be produced by real invocation
+* Synthesis must not erase disagreement
+* A human decision gate controls downstream action
+
+Committee is not a casual collection of agents. It requires member definitions, invocation rules, report contracts, synthesis rules, and no-simulation discipline.
+
+### 4.4 CCPE-Skill
 
 CCPE-Skill is a reusable capability module.
 
@@ -122,7 +180,9 @@ Typical examples:
 
 A Skill should be reusable across multiple agents.
 
-### 4.4 CCPE-Runtime
+CCPE-Skill is distinct from automation Skill source. Deterministic script-backed automation belongs in `skills-vault`; CCPE registers it only when a CCPE Agent or Runtime formally depends on it.
+
+### 4.5 CCPE-Runtime
 
 CCPE-Runtime is a protocol for running multi-step, multi-role, tool-using, or long-running work.
 
@@ -161,6 +221,21 @@ Typical examples:
 * Knowledge extraction pipeline
 * Multi-agent synthesis workflow
 
+### 4.6 Integration Registration
+
+Integration Registration records an external capability that CCPE depends on but does not own.
+
+Use it for:
+
+* `skills-vault` automation skills
+* MCP servers
+* CLI tools
+* API services
+* Installed local capabilities
+* Agentic development frameworks
+
+Registration records authority, allowed operations, safety, validation, failure behavior, and consumers. It does not copy implementation source.
+
 ## 5. Cognitive Model Assets
 
 CCPE System distinguishes between Agents and Models.
@@ -292,11 +367,14 @@ ccpe-system/
 │
 ├── ccpe-protocol/
 │   ├── ccpe-system-definition.md
+│   ├── ccpe-boundaries.md
 │   ├── ccpe-classification-rules.md
+│   ├── ccpe-artifact-taxonomy.md
 │   ├── ccpe-operating-modes.md
 │   ├── ccpe-layer-spec.md
 │   ├── ccpe-quality-rubric.md
-│   └── ccpe-migration-policy.md
+│   ├── ccpe-migration-policy.md
+│   └── ccpe-governance-adapter.md
 │
 ├── .codex/
 │   └── skills/
@@ -334,12 +412,18 @@ ccpe-system/
 │   ├── workflow-models/
 │   └── implicit-extracted/
 │
-└── model-index/
+├── model-index/
-    ├── model-index.md
+│   ├── model-index.md
-    ├── model-taxonomy.md
+│   ├── model-taxonomy.md
-    ├── model-dependency-map.md
+│   ├── model-dependency-map.md
-    ├── model-usage-map.md
+│   ├── model-usage-map.md
-    └── extraction-log.md
+│   └── extraction-log.md
+│
+└── integrations/              # Create only when concrete registration files are needed.
+    ├── skills-vault/
+    ├── mcp/
+    ├── cli-tools/
+    └── api-services/
 ```
 
 ## 8. Recommended Workflow
@@ -353,9 +437,12 @@ ccpe-system/
 
    * Lite
    * Agent
+   * Committee
    * Skill
    * Runtime
    * Model Card
+   * Integration Registration
+   * Project Runbook or automation Skill source that should be routed outside CCPE
    * Hybrid
 5. Generate the target file.
 6. Place the final artifact in the correct directory.

ccpe-protocol/ccpe-artifact-taxonomy.md

@@ -0,0 +1,228 @@
+# CCPE Artifact Taxonomy
+
+## 1. Purpose
+
+This document defines the expanded artifact taxonomy for CCPE System.
+
+Classification must precede creation, audit, refactor, migration, registration, or deletion.
+
+## 2. Primary CCPE-Owned Artifact Types
+
+### 2.1 CCPE-Lite
+
+Portable expert prompt or Prompt Card.
+
+Use when:
+
+```text
+single expert role
+human-facing interaction
+Web / GPT / Gemini / Claude use
+no heavy state or handoff requirement
+portable prompt is the production artifact
+```
+
+Mature expert prompts should stay Lite by default unless real usage requires another layer.
+
+### 2.2 CCPE-Agent
+
+Durable role spec for a reusable working agent.
+
+Use when:
+
+```text
+stable responsibility
+explicit input / output contract
+collaboration or handoff
+authority boundaries
+evaluation requirements
+possible tool or skill calls
+```
+
+### 2.3 CCPE-Committee
+
+A fixed multi-agent review or judgment structure.
+
+Use when:
+
+```text
+multiple roles create necessary tension
+independent reports are required
+synthesis must preserve disagreement
+human gate decides how to use the reports
+no-simulation evidence is required
+```
+
+Committee is not a casual list of agents. It must define members, role tension, invocation rules, report schema, synthesis rule, and human decision gate.
+
+### 2.4 CCPE-Skill
+
+Reusable capability spec.
+
+CCPE-Skill may be:
+
+```text
+cognitive
+method
+workflow
+evaluation
+transformation
+knowledge-management
+```
+
+CCPE-Skill is not the same as an installable automation script. A CCPE-Skill may be a method, checklist, reasoning protocol, or evaluation contract.
+
+### 2.5 CCPE-Runtime
+
+Protocol for multi-stage or stateful work.
+
+Use only when the work involves:
+
+```text
+multiple stages
+multiple participants
+state
+handoff
+tools
+files
+human gates
+recovery
+synthesis
+archival
+downstream dependency
+```
+
+Runtime does not imply full automation. Interactive Runtime is first-class.
+
+### 2.6 Model Card
+
+Reusable cognitive model definition.
+
+Use when the artifact defines how to understand or reason about a class of problems, with assumptions, mechanism, scope, failure modes, and falsification boundary.
+
+### 2.7 Model Index
+
+Registry and map of Model Cards.
+
+Use when models need taxonomy, dependency tracking, overlap tracking, usage mapping, or lifecycle governance.
+
+### 2.8 Integration Registration
+
+Architecture registration for a capability CCPE depends on but does not own.
+
+Use for:
+
+```text
+skills-vault automation skill
+MCP server
+CLI tool
+API service
+installed local capability
+agentic development framework
+```
+
+Registration records dependency metadata, authority, safety, validation, failure behavior, and consumers.
+
+## 3. Non-CCPE Ownership Categories
+
+### 3.1 Project Runbook
+
+Belongs in the project repository.
+
+Examples:
+
+```text
+writing-workbench project playbook
+video-workbench production runbook
+knowledge-vault discussion processing instructions
+work-projects application workflow docs
+```
+
+CCPE may provide a Runtime spec or Agent spec that a runbook uses. The runbook itself belongs to the project.
+
+### 3.2 Project Execution Record
+
+Belongs in the project repository.
+
+Examples:
+
+```text
+session.md
+returned reviewer report for one article
+decision record
+source digest for one project
+draft chapter
+editing checklist for one deliverable
+```
+
+### 3.3 automation Skill Source
+
+Belongs in `skills-vault`.
+
+Examples:
+
+```text
+script-backed markdown cleanup
+batch export
+TTS batch generation
+file renaming
+source splitting
+format conversion
+```
+
+CCPE may register such a skill when used by a CCPE Runtime or Agent.
+
+### 3.4 Production Application Implementation
+
+Belongs in the concrete development project.
+
+Examples:
+
+```text
+LangGraph node implementation
+CrewAI agent class
+server route
+database state schema
+queue worker
+monitoring configuration
+deployment scripts
+```
+
+CCPE may design the agent contract. It does not own the deployable implementation.
+
+### 3.5 Out of Scope
+
+If an artifact is not reusable architecture, not a project requirement, not an external capability registration, and not a cognitive model asset, it may be out of scope for CCPE.
+
+## 4. Decision Matrix
+
+| Input | Target |
+| --- | --- |
+| Mature Web expert prompt | CCPE-Lite |
+| Expert prompt with stable embedded model | CCPE-Lite + optional Model Card |
+| Durable workflow role | CCPE-Agent |
+| Fixed multi-agent review structure | CCPE-Committee |
+| Reusable cognitive method | CCPE-Skill |
+| Deterministic script-backed tool | skills-vault automation Skill source |
+| Multi-stage stateful process | CCPE-Runtime |
+| One project runbook | project repository |
+| One project output or decision log | project repository |
+| External tool dependency | Integration Registration |
+| Production app implementation | development project repository |
+
+## 5. Minimality Rule
+
+Select the smallest structure that preserves:
+
+```text
+purpose fit
+intellectual flavor
+reuse value
+boundary precision
+authority clarity
+evaluation strength
+runtime safety
+maintainability
+```
+
+Do not upgrade an artifact into Agent, Skill, Runtime, Committee, or Model Index layers merely because it is important.

ccpe-protocol/ccpe-boundaries.md

@@ -0,0 +1,227 @@
+# CCPE Boundaries
+
+## 1. Purpose
+
+This document defines what CCPE System owns, what it only registers, and what it must leave in other repositories.
+
+The goal is to prevent CCPE from becoming:
+
+```text
+a project execution repository
+an automation script source repository
+a deployed agentic application framework
+a copy of upstream methodology documents
+```
+
+CCPE is an architecture forge and supplier layer for AI artifacts.
+
+## 2. System Position
+
+CCPE sits between high-level methodology and concrete project execution.
+
+```text
+HiFi Agent Studio
+= top-level principles and architecture philosophy
+
+Agentic Engineering Handbook
+= operating governance and field rules
+
+CCPE System
+= prompt / agent / skill / runtime / model / integration architecture forge
+
+Project workbenches and vaults
+= concrete project execution, records, materials, drafts, and runbooks
+
+skills-vault / MCP / CLI / API services
+= implementation and external capability layer
+```
+
+CCPE may reference higher-level methodology and external capability sources. It should not copy their full content or become their implementation source.
+
+## 3. What CCPE Owns
+
+CCPE owns reusable AI architecture assets:
+
+```text
+CCPE-Lite prompt cards
+CCPE-Agent specs
+CCPE-Committee specs
+CCPE-Skill specs for cognitive, method, workflow, and evaluation capabilities
+CCPE-Runtime specs
+Model Cards
+Model Index entries
+Integration Registrations
+quality rubrics
+invocation protocols
+migration policies
+artifact templates
+```
+
+CCPE may design both:
+
+```text
+development agents
+= agents for the user's own local work, such as creation, review, planning, sales support, project planning, system design, or output production
+
+production / business agents
+= agents intended for deployed intelligent systems
+```
+
+For production / business agents, CCPE owns the specification and governance layer. The concrete development project owns framework implementation, deployment, state, monitoring, and application behavior.
+
+## 4. What Project Repositories Own
+
+Project repositories own concrete execution.
+
+Examples:
+
+```text
+writing-workbench
+video-workbench
+knowledge-vault
+work-projects/*
+```
+
+These repositories should own:
+
+```text
+requirements submitted to CCPE
+project runbooks
+project-specific context packs
+source digests for one project
+returned participant outputs
+drafts and revisions
+decision records
+process logs
+publication metadata
+project handoffs
+application code and deployment configuration
+```
+
+CCPE may supply the agents, protocols, and rules used by those projects, but it should not store the project-specific run history.
+
+## 5. What skills-vault Owns
+
+`skills-vault` owns automation-oriented Skill source.
+
+This includes:
+
+```text
+SKILL.md
+scripts
+tests
+fixtures
+examples
+installation notes
+migration records
+deterministic tool logic
+```
+
+Examples:
+
+```text
+fix-title
+markdown-normalizer
+citation-checker
+report-exporter
+source-splitter
+tts-batch-generator
+image-prompt-exporter
+```
+
+These are not CCPE source assets unless they become method or governance specs. If a CCPE Runtime or Agent formally depends on one, CCPE should register the dependency rather than copying the source.
+
+## 6. What Integration Registration Covers
+
+Integration Registration is used when CCPE depends on a capability it does not own.
+
+Possible integrations:
+
+```text
+skills-vault automation skills
+MCP servers
+CLI tools
+API services
+installed local skills
+platform-specific capabilities
+agentic development frameworks
+```
+
+Registration records architecture metadata:
+
+```text
+canonical implementation
+installed path or endpoint
+used_by
+authority
+allowed operations
+forbidden operations
+side effects
+security notes
+validation
+failure behavior
+status
+version
+```
+
+Registration does not copy implementation source.
+
+## 7. Requirement-First Supplier Rule
+
+CCPE should not invent project workflows before a project needs them.
+
+Preferred flow:
+
+```text
+project repository identifies a real use case
+project writes or states a requirement
+CCPE classifies the requirement
+CCPE supplies the smallest appropriate artifact
+project repository runs the concrete workflow
+project returns feedback or new requirements
+```
+
+This reverses the older pattern where CCPE first discussed a business scenario internally, built assets, and then expected project repositories to adapt around them.
+
+## 8. No-Simulation Boundary
+
+Formal participant output must come from real invocation.
+
+The following are not execution:
+
+```text
+dispatch packet only
+prompt-to-send only
+controller summary
+main-session role-played reviewer output
+```
+
+If a participant cannot be truly invoked, the state must remain:
+
+```text
+blocked_waiting_for_participant_output
+```
+
+Simulation may be used for planning only when labeled:
+
+```yaml
+simulation_only: true
+formal_output: false
+excluded_from_synthesis: true
+```
+
+## 9. Boundary Decision Checklist
+
+Before creating or moving an artifact, answer:
+
+```text
+Does this artifact define a reusable AI role, method, model, runtime, or governance contract?
+Does it belong to one project execution history?
+Is it deterministic automation source?
+Is it implementation code for a deployed system?
+Is CCPE the owner, or only the architecture registrar?
+Who will consume the artifact next?
+What must not be copied into CCPE?
+```
+
+If ownership is unclear, write an analysis note in `workbench/analysis/` before changing canonical directories.

ccpe-protocol/ccpe-classification-rules.md

@@ -20,7 +20,23 @@ Turning every artifact into a complex Agent / Skill / Runtime system.
 
 Use the lightest structure that preserves clarity, function, reusability, maintainability, and safety.
 
-## 1.1 Scenario Probe First
+## 1.1 Supplier Intake Rule
+
+For project-facing work, do not begin by inventing a CCPE asset from an assumed business scenario.
+
+Preferred sequence:
+
+```text
+1. Project repository identifies a real use case.
+2. Project repository provides a requirement or the user states the concrete need.
+3. CCPE classifies the requirement and checks repository ownership.
+4. CCPE supplies the smallest appropriate artifact.
+5. The project repository runs the concrete work and stores execution records.
+```
+
+This applies to `writing-workbench`, `knowledge-vault`, `video-workbench`, and future `work-projects`.
+
+## 1.2 Scenario Probe First
 
 Before choosing Lite, Agent, Skill, Runtime, Model Card, or Hybrid, determine the real usage scenario.
 
@@ -56,11 +72,17 @@ Every artifact should be classified as one or more of the following:
 ```text
 CCPE-Lite
 CCPE-Agent
+CCPE-Committee
 CCPE-Skill
 CCPE-Runtime
 Model Card
 Model Index
+Integration Registration
+Project Runbook
+automation Skill source
+external tool / MCP / CLI / API
 Hybrid Artifact
+Out of Scope
 ```
 
 Many real artifacts will be Hybrid.
@@ -68,6 +90,24 @@ Many real artifacts will be Hybrid.
 The job of classification is not to force one label.
 The job is to identify the dominant form and embedded components.
 
+Classification must also decide repository ownership.
+
+```text
+CCPE-owned:
+  Lite, Agent, Committee, CCPE-Skill, Runtime, Model Card, Model Index, Integration Registration
+
+Project-owned:
+  Project Runbook, project execution record, one-off context pack, returned report, draft, decision log
+
+skills-vault-owned:
+  automation Skill source, scripts, tests, fixtures, install notes
+
+development-project-owned:
+  production agent implementation, LangGraph/CrewAI adapters, server runtime, persistence, deployment
+```
+
+If an external capability is required by a CCPE artifact, classify the CCPE-side output as `Integration Registration`, not as copied source.
+
 ## 3. Quick Decision Tree
 
 Start with these questions.
@@ -82,12 +122,16 @@ Use this matrix before the artifact-type questions.
 | Long-term expert role in GPT / Gem / Claude | CCPE-Lite or Agent-Lite | Preserve single-context prompt strength. |
 | Web-like single-agent use inside Codex | CCPE-Lite + optional Codex Skill | Skill is needed only if Codex should invoke it automatically. |
 | Stable role with collaboration responsibilities | CCPE-Agent | Use when the role needs contracts, handoff, authority, or evaluation. |
+| Fixed group of reviewers or judges | CCPE-Committee | Requires independent reports, role tension, synthesis rule, human gate, and no-simulation rule. |
 | Multiple roles manually coordinated by the user | CCPE-Lite / CCPE-Agent + Interactive Runtime Lite | The human may remain the orchestrator. |
 | Reusable method across roles | CCPE-Skill | Extract only when reuse or invocation is real. |
-| Repeated tool or file operation | CCPE-Skill or Runtime | Add permission, validation, and recovery rules. |
+| Repeated deterministic tool or file operation | automation Skill source in skills-vault | CCPE registers dependency only when a CCPE artifact formally uses it. |
 | Multi-agent automated or semi-automated workflow | CCPE-Runtime | Requires state, handoff, routing, and human gates. |
 | Deep creation / modeling / critique | Interactive Runtime or Lite/Agent set | Human judgment must remain central. |
 | Low-risk repetitive execution | Automation Runtime | Use only when stable and verifiable. |
+| One project runbook or execution record | Project repository | Do not migrate project-specific records into CCPE. |
+| External tool, MCP, CLI, API, or installed capability | Integration Registration | Register architecture dependency; do not copy implementation source. |
+| Production business agent for deployed system | CCPE spec + development project implementation | CCPE designs contract; target project implements runtime. |
 
 ### 3.1 Is it mainly a portable expert prompt?
 

ccpe-protocol/ccpe-governance-adapter.md

@@ -0,0 +1,297 @@
+# CCPE Governance Adapter
+
+## 1. Purpose
+
+This document adapts broader agentic engineering governance into CCPE artifact design without copying an entire external handbook into this repository.
+
+CCPE should reference higher-level methodology when needed, but local CCPE artifacts must still carry the governance fields needed for safe use.
+
+## 2. Intake Before Artifact Design
+
+Before designing or refactoring an artifact, classify the request by:
+
+```text
+QPI class
+task nature
+reuse level
+run mode
+depth vs automation orientation
+consumer repository
+```
+
+QPI class:
+
+```text
+Q = information gap
+P = path / production / transformation problem
+I = order / judgment / responsibility problem
+```
+
+Task nature:
+
+```text
+one-off output
+reusable capability
+governed system building
+model calibration
+exploratory rehearsal
+```
+
+Reuse level:
+
+```text
+one-off
+reusable
+governed
+```
+
+Run mode:
+
+```text
+Lite
+Standard
+Full
+```
+
+Default to Lite unless evidence requires escalation.
+
+## 3. Cost Ledger
+
+For substantial work, distinguish:
+
+```text
+Content Cost
+System-Building Cost
+Calibration Cost
+Exploration Cost
+```
+
+Do not present system-building cost as if it were normal content production cost.
+
+If a small source task expands into protocol design, runtime building, worker orchestration, audit logs, or no-simulation validation, reclassify the work and ask for human confirmation before continuing.
+
+## 4. Scope Drift Detector
+
+Pause and reclassify when a task starts showing these signals:
+
+```text
+one-off task begins creating reusable protocol
+new agents, skills, runtimes, or directories are introduced
+original output is delayed while governance artifacts multiply
+Lite task dispatches multiple workers
+P-domain work drifts into I-domain governance
+budget is exceeded
+invocation, authority, state, or audit becomes central
+```
+
+Required response:
+
+```text
+pause
+name the drift
+ask whether this is still the original task
+if not, reclassify as system-building or governed work
+separate the cost ledger
+continue only after human confirmation
+```
+
+## 5. Runtime Maturity Modes
+
+### 5.1 Lite
+
+Use for:
+
+```text
+one-off task
+low risk
+single model can handle it
+no true multi-agent requirement
+no full trace requirement
+downstream does not depend on process evidence
+```
+
+Typical outputs:
+
+```text
+target output
+brief input record
+human confirmation
+optional sample check
+```
+
+### 5.2 Standard
+
+Use for:
+
+```text
+future reuse
+clear downstream consumer
+context package needed
+small number of real participant invocations
+key human gate required
+```
+
+Typical outputs:
+
+```text
+source or context pack
+confirmed structure
+reusable artifacts
+decision record
+targeted audit
+minimal invocation record
+```
+
+### 5.3 Full
+
+Use for:
+
+```text
+many roles
+many sources
+high risk
+accountability requirement
+long cycle
+external delivery
+process authenticity required downstream
+```
+
+Typical outputs:
+
+```text
+full runtime
+invocation records
+authority map
+state machine
+coverage audit
+distortion risk log
+recovery protocol
+downstream handoff
+```
+
+## 6. Required Governance Fields
+
+Runtime specs should include:
+
+```text
+runtime_orientation
+mode
+qpi_class
+participants
+human_gates
+state_protocol
+invocation_authenticity
+simulation_labeling
+authority_matrix
+tool_permissions
+source_fidelity
+evaluation_level
+stop_rule
+handoff_rules
+related_models
+related_skills
+related_integrations
+```
+
+Agent specs should include:
+
+```text
+responsibility
+inputs
+outputs
+authority_level
+allowed_tools
+forbidden_actions
+required_skills
+related_models
+handoff_rules
+evaluation
+invocation_requirements
+failure_modes
+```
+
+Integration registrations should include:
+
+```text
+canonical_implementation
+installed_path_or_endpoint
+used_by
+authority
+allowed_operations
+forbidden_operations
+side_effects
+security_notes
+validation
+failure_behavior
+status
+```
+
+## 7. Human Gate Contract
+
+Human gates must be explicit.
+
+Each gate should record:
+
+```text
+gate_id
+decision_owner
+input_artifacts
+decision_options
+default_action
+downstream_effect
+reversibility
+escalation_condition
+record_path
+```
+
+Do not use vague "wait for user confirmation" text when the decision changes downstream authority or artifact status.
+
+## 8. Execution Authenticity
+
+Formal participant output requires real invocation evidence.
+
+Minimum invocation record:
+
+```text
+participant id
+canonical artifact path
+invocation carrier
+thread / session / platform id when available
+input context
+returned output path
+timestamp
+whether output enters synthesis
+```
+
+Packet-only and prompt-to-send-only are not execution.
+
+## 9. Evaluation Stack
+
+Use the lightest evaluation level that fits the risk:
+
+```text
+E0 Smoke Test
+E1 Format Test
+E2 Factual Test
+E3 Reasoning Test
+E4 Expert Similarity
+E5 Decision Utility
+E6 Calibration Test
+E7 Governance Test
+```
+
+Suggested defaults:
+
+```text
+Lite: E0-E2
+Standard: E0-E5
+Full: E0-E7
+```
+
+## 10. Platform and Framework Boundary
+
+Codex, Claude Code, OpenClaw, Superpowers, LangGraph, CrewAI, and similar systems may execute or host CCPE-designed artifacts.
+
+They do not override CCPE's classification, no-simulation, authority, and boundary rules.
+
+For deployed systems, CCPE should stop at specification, evaluation, and governance contracts unless the user explicitly asks to work in the concrete application repository.

ccpe-protocol/ccpe-migration-policy.md

@@ -16,6 +16,10 @@ Multi-agent committees
 Old Skill-like procedures
 Workflow descriptions
 Prompt templates
+Project runbooks
+Automation skill sources
+External tool dependencies
+Production / business agent specifications
 ```
 
 The goal is not to rewrite everything into a heavier format.
@@ -24,6 +28,24 @@ The goal is to identify what each artifact really contains and move each compone
 
 Migration must begin with scenario probing. The same source artifact may become only a Lite prompt, or may become Lite + Model Card + Skill + Agent + Runtime, depending on how the user actually uses it.
 
+Migration must also begin with ownership probing. Not every useful artifact should migrate into CCPE.
+
+```text
+CCPE target:
+  reusable prompt, agent, committee, CCPE-Skill, runtime, model, index, registration
+
+Project repository target:
+  project runbook, execution record, context pack, returned output, draft, decision log
+
+skills-vault target:
+  automation Skill source, scripts, tests, fixtures, installation notes
+
+development project target:
+  deployed production agent implementation, framework adapter, server runtime, persistence
+```
+
+If CCPE needs an external capability but does not own its implementation, produce an Integration Registration instead of copying source.
+
 ## 2. Migration Principle
 
 The central migration principle is:
@@ -87,6 +109,18 @@ depth_orientation:
 
 If scenario information is unavailable, produce a scenario assumption and mark it as a migration risk.
 
+Also determine whether the artifact is:
+
+```text
+development agent:
+  used by the user for local creation, review, planning, workflow support, or system design
+
+production / business agent:
+  intended for a deployed intelligent system
+```
+
+CCPE may specify both. For production / business agents, the concrete implementation normally belongs in the application project, especially when constrained by LangGraph, CrewAI, or another deployment framework.
+
 ## 2.2 Mature Agent Minimal Expansion Rule
 
 For a proven old agent that is mainly used as a single expert in chat:

ccpe-protocol/ccpe-operating-modes.md

@@ -13,6 +13,8 @@ Operating mode tells us how it behaves in practice.
 
 Operating mode must be determined from the user's real or planned usage scenario, not from the artifact's perceived importance.
 
+For project-facing work, the usage scenario should normally come from the consuming project repository, not from CCPE's internal speculation. CCPE supplies assets after a real requirement exists.
+
 The same artifact type can operate in different modes.
 
 Example:
@@ -39,6 +41,62 @@ These modes are not maturity levels.
 
 They are different usage patterns.
 
+## 2.1 Runtime Maturity Modes
+
+In addition to operating mode, substantial workflows should declare a runtime maturity mode:
+
+```text
+Lite
+Standard
+Full
+```
+
+Default to Lite. Escalate only when evidence requires it.
+
+### Lite
+
+Use when the task is one-off, low-risk, single-model or single-artifact, and does not require formal multi-agent evidence.
+
+Typical outputs:
+
+```text
+target output
+brief input record
+human confirmation
+optional sample check
+```
+
+### Standard
+
+Use when the work will likely recur, has a downstream consumer, needs a context pack or structured artifacts, and may involve a small number of real participant invocations.
+
+Typical outputs:
+
+```text
+source or context pack
+confirmed structure
+decision record
+targeted audit
+minimal invocation record
+```
+
+### Full
+
+Use only when there are multiple roles, multiple sources, high risk, accountability needs, long cycles, external delivery, or downstream dependency on process authenticity.
+
+Typical outputs:
+
+```text
+full runtime
+invocation records
+authority map
+state machine
+coverage audit
+distortion-risk log
+recovery protocol
+downstream handoff
+```
+
 ## 3. Expert Mode
 
 ### 3.1 Definition
@@ -852,5 +910,33 @@ Do not create committees when one expert agent is enough.
 
 Do not reduce a cognitive workshop to a pipeline.
 
+Do not simulate canonical participant output.
+
+When a Runtime depends on a CCPE-Lite prompt, CCPE-Agent, CCPE-Skill, Runtime node, native agent, external model participant, or human-run participant, the Runtime must define a real invocation boundary before accepting that participant's output.
+
+Required invocation evidence:
+
+```text
+Agent Invocation Packet
+prompt-to-send.md with returned external output
+Skill execution record
+Native agent run record
+Manual handoff return record
+```
+
+If the participant cannot be truly invoked, the Runtime must stop and mark:
+
+```text
+blocked_waiting_for_participant_output
+```
+
+Any explicitly requested simulation must be labeled:
+
+```text
+simulation-only
+excluded-from-synthesis
+not-a-formal-report
+```
+
 The correct operating mode is the one that preserves depth while reducing unnecessary friction.
 

ccpe-protocol/ccpe-system-definition.md

@@ -2,7 +2,9 @@
 
 ## 1. Purpose
 
-CCPE System is a context protocol engineering framework for constructing, auditing, refactoring, and maintaining AI Prompt Cards, Agent Specs, Skills, Runtime protocols, Cognitive Model Cards, and Model Indexes.
+CCPE System is a context protocol engineering framework for constructing, auditing, refactoring, registering, and maintaining AI Prompt Cards, Agent Specs, Committee Specs, CCPE Skill Specs, Runtime protocols, Cognitive Model Cards, Model Indexes, and external capability registrations.
+
+It is also a supplier layer for the user's concrete work repositories. Project repositories should raise real requirements; CCPE supplies the appropriate AI artifact architecture and governance contracts.
 
 It exists to solve a structural problem:
 
@@ -22,6 +24,8 @@ Modern AI work often involves:
 
 CCPE System provides a shared protocol for defining and managing these components.
 
+CCPE can design both local development agents for the user's own work and production/business agents intended for deployed intelligent systems. For deployed systems, CCPE owns the specification, authority, evaluation, and governance contract. The target application project owns implementation, framework adapters, server runtime, persistence, monitoring, and deployment.
+
 ## 2. Core Definition
 
 **CCPE is a context protocol engineering framework for building, reviewing, and maintaining AI Prompts, Agents, Skills, and Agentic Workflows.**
@@ -98,11 +102,17 @@ A tool wrapper
 A generic agent framework
 A pure automation framework
 A knowledge-base folder
+A project execution repository
+An automation Skill source repository
+A deployed application runtime
+A LangGraph, CrewAI, or other framework implementation
 A chain-of-thought template
 ```
 
 It is also not designed to force every AI artifact into a heavy engineering structure.
 
+It is not the canonical source for `skills-vault` automation skills, MCP implementations, CLI tools, API services, or project-specific run histories. CCPE may register these capabilities as dependencies when CCPE artifacts rely on them.
+
 The system should avoid both extremes:
 
 ```text
@@ -138,11 +148,17 @@ Possible forms:
 ```text
 CCPE-Lite
 CCPE-Agent
+CCPE-Committee
 CCPE-Skill
 CCPE-Runtime
 Model Card
 Model Index
+Integration Registration
+Project Runbook
+automation Skill source
+external tool / MCP / CLI / API
 Hybrid Artifact
+Out of Scope
 ```
 
 This classification determines the necessary structure.

workbench/analysis/deep-creation-automation-boundary.protocol.md

@@ -0,0 +1,178 @@
+# 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.