Compare commits

..

2 Commits

Author SHA1 Message Date
wantsong 02ec00d256 完成接口 2026-06-22 02:20:19 +08:00
wantsong 2b2ba006b3 Add CCPE value gate 2026-06-20 03:24:16 +08:00
11 changed files with 739 additions and 59 deletions

View File

@ -58,6 +58,14 @@ The Skill's job is not merely to generate better prompts.
Its job is to preserve, operationalize, and maintain reusable cognitive structure.
CCPE Forge must not accept every requested prompt or workflow as CCPE work. Its core standard is:
```text
CCPE System is the forge for expert agents, cognitive models, reusable methods, and invocation contracts.
```
Before creating or modifying any CCPE artifact, decide whether the request has CCPE value. Accept the request only when it requires expert agent capability, cognitive model structure, reusable method design, durable role definition, cross-project invocation contracts, or high-risk cognitive boundary management. If the request is only project-local prompt glue, one-off output formatting, immature model experimentation, sample-run orchestration, or a business-project decision about when to invoke an existing artifact, return it to the owning project repository instead of producing a CCPE artifact.
## 3. When to Use This Skill
Use CCPE Forge when the user asks to:
@ -141,13 +149,22 @@ If the task starts from a long article or model source, run Model Mining Mode fi
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
1. CCPE Value Gate
2. Classification First Gate
3. Boundary Check
4. Supplier Intake Check
5. Depth vs Automation Check
6. No-Simulation Check when participants are involved
```
CCPE Value Gate must answer:
```text
Does this work require expert agent capability, cognitive model structure, reusable method design, durable invocation contract, or high-risk cognitive boundary management?
```
If the answer is no, stop CCPE artifact creation, state the boundary, and route the request to the owning project or repository.
Classification First Gate must choose from:
```text
@ -189,6 +206,7 @@ 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.
Reject or return project-facing requests whose source models, trial outputs, or actual use effects are not stable enough to justify CCPE canonicalization.
```
If the artifact does not belong in CCPE, recommend the correct repository or produce an Integration Registration plan.
@ -218,17 +236,18 @@ Follow this workflow:
```text
1. Intake
2. Scenario probe
3. Artifact layer selection
4. Artifact classification
5. Operating mode assessment
6. Depth vs automation assessment
7. Cognitive model check
8. Human decision gate check
9. Creation Brief
10. Proposed file list
11. Generate artifact
12. Validate artifact
2. CCPE value gate
3. Scenario probe
4. Artifact layer selection
5. Artifact classification
6. Operating mode assessment
7. Depth vs automation assessment
8. Cognitive model check
9. Human decision gate check
10. Creation Brief
11. Proposed file list
12. Generate artifact
13. Validate artifact
```
### 6.3 Creator Mode Must Determine
@ -236,6 +255,7 @@ Follow this workflow:
Before generating the final artifact, determine:
```text
Does the request have CCPE value, or should it be returned to the owning project?
What is the intended use?
Who will use it?
Where will it run?

View File

@ -23,25 +23,33 @@ All CCPE Forge work should follow this high-level sequence:
```text
1. Intake
2. Classification First Gate
3. Boundary Check
4. Supplier Intake Check
5. Operating Mode Assessment
6. Depth vs Automation Assessment
7. Embedded Component Detection
8. Risk and Human Decision Gate Check
9. Mode-Specific Work
10. Proposed Outputs
11. Validation
12. Final Response
2. CCPE Value Gate
3. Classification First Gate
4. Boundary Check
5. Supplier Intake Check
6. Operating Mode Assessment
7. Depth vs Automation Assessment
8. Embedded Component Detection
9. Risk and Human Decision Gate Check
10. Mode-Specific Work
11. Proposed Outputs
12. Validation
13. Final Response
```
Do not skip classification.
Do not skip the value gate or 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.
Value Gate rule:
```text
Accept CCPE work only when it forges expert agent capability, cognitive model structure, reusable method design, durable invocation contracts, high-risk cognitive boundaries, or cross-project reuse.
Return work when it is only project-local prompt glue, one-off output formatting, immature model trial work, sample-run orchestration, or a project decision about when to invoke existing artifacts.
```
## 3. Intake
During intake, determine what the user has provided and what they want.

View File

@ -18,6 +18,8 @@ Hybrid artifacts
Creator Mode should not assume that every new request requires a full Agent or Runtime.
Creator Mode should also not assume that every requested prompt belongs in CCPE. Use the CCPE value gate first: accept work only when it forges expert agent capability, cognitive model structure, reusable method design, durable invocation contracts, high-risk cognitive boundaries, or cross-project reuse. Return project-local prompt glue, one-off formatting, immature model trials, sample runs, and project invocation decisions to the owning project repository.
The goal is to create the lightest artifact that preserves function, depth, maintainability, and safety.
## 2. When to Use Creator Mode
@ -44,19 +46,20 @@ Follow this sequence:
```text
1. Intake
2. Scenario Probe
3. Intended Use Analysis
4. Target Platform Analysis
5. Layer Selection
6. Classification
7. Operating Mode Assessment
8. Depth vs Automation Assessment
9. Model / Skill / Runtime Check
10. Creation Brief
11. Proposed Files
12. Artifact Draft
13. Validation
14. Final Notes
2. CCPE Value Gate
3. Scenario Probe
4. Intended Use Analysis
5. Target Platform Analysis
6. Layer Selection
7. Classification
8. Operating Mode Assessment
9. Depth vs Automation Assessment
10. Model / Skill / Runtime Check
11. Creation Brief
12. Proposed Files
13. Artifact Draft
14. Validation
15. Final Notes
```
## 3.1 Scenario Probe

View File

@ -12,6 +12,8 @@ This workspace should be treated as a living engineering system, not merely a co
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 System is not a factory for every requested prompt. Its core value is the forging of expert agents, cognitive models, reusable methods, and invocation contracts. Before accepting an external or user-requested artifact into CCPE, test whether it requires expert hidden experience, a stable cognitive model, a reusable method, a durable role, a cross-project contract, or high-risk cognitive boundary management. If it does not, return the request to the business or project repository instead of manufacturing a CCPE artifact.
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
@ -69,7 +71,26 @@ The main tasks are:
## 3. Core Principle
Always classify before creating, auditing, or refactoring.
Always apply the CCPE value gate and then classify before creating, auditing, or refactoring.
Before classification, apply the CCPE value gate:
```text
CCPE accepts work when it forges at least one of:
- expert agent capability
- cognitive model structure
- reusable method
- durable invocation contract
CCPE returns work when it is primarily:
- project-local prompt glue
- one-off output formatting
- immature model trial work
- project-specific orchestration or run records
- a business-project decision about when to invoke an existing agent or Skill
```
Passing the value gate does not mean CCPE must create every possible artifact layer. It means CCPE may proceed to classification and choose the lightest useful artifact. Failing the value gate means the correct action is to explain the boundary and route the work back to the owning project.
Before producing or modifying any artifact, determine whether it is primarily one of the following:
@ -118,6 +139,7 @@ CCPE owns:
- Model Cards
- Model Index entries
- external capability registrations
- invocation contracts for CCPE-owned agents, Skills, runtimes, and model-backed methods
Project repositories own:
- project runbooks
@ -126,6 +148,8 @@ Project repositories own:
- returned participant reports for one project
- user decision logs
- publication metadata
- project-local adapters, glue prompts, sample runs, and decisions about when to invoke existing CCPE artifacts
- immature model exploration before the model reaches a stable enough version for CCPE forging
skills-vault owns:
- automation Skill source
@ -1020,17 +1044,21 @@ Maintainability
If the user gives an artifact and asks what to do with it:
1. Classify it.
2. Identify embedded components.
3. Recommend target forms.
4. Produce a plan.
5. Wait for confirmation before major rewrite.
1. Apply the CCPE value gate.
2. If it fails, return it to the owning project or repository with a short reason.
3. If it passes, classify it.
4. Identify embedded components.
5. Recommend target forms.
6. Produce a plan.
7. Wait for confirmation before major rewrite.
If the user asks to create a new agent:
1. Build a Creation Brief.
2. Decide whether Lite, Agent, Skill, Runtime, Model Card, or Hybrid is appropriate.
3. Generate the artifact in the correct template.
1. Apply the CCPE value gate.
2. If it does not require expert agent capability, cognitive model structure, reusable method, or durable invocation contract, return it to the business/project repository.
3. Build a Creation Brief only after the gate passes.
4. Decide whether Lite, Agent, Skill, Runtime, Model Card, or Hybrid is appropriate.
5. Generate the artifact in the correct template.
If the user asks to extract models from writing:

25
Interface.md Normal file
View File

@ -0,0 +1,25 @@
# CCPE External Interface
This is the single external entrypoint for business systems, workbench projects, and local product repositories that need to invoke CCPE Agents, Lite prompts, Skills, Runtime nodes, or other canonical CCPE participants.
Consumer projects should record this file path as their default CCPE interface:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md
```
Before invoking any CCPE participant, read the consumer setup contract:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccpe-agent-consumer-setup.md
```
Do not memorize or hardcode other CCPE paths as default interfaces. Read protocol, Runtime, Agent, Lite, or Skill files only when the consumer setup contract tells you to.
Minimum rule:
```text
Interface.md
-> ccpe-agent-consumer-setup.md
-> only then read the required protocol / Runtime / Agent / Lite / Skill files for the current task
```

View File

@ -6,10 +6,12 @@ CCPE System is a context protocol engineering workspace for designing, auditing,
CCPE originally emerged from advanced Prompt Engineering. The new CCPE System extends that foundation into Agentic Engineering.
Its purpose is to help transform AI from a one-off responder into a reusable, testable, composable, collaborative, and maintainable task-execution system.
Its purpose is to forge expert agents, cognitive models, reusable methods, and invocation contracts that can 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 a factory for every requested prompt. If a request is only project-local glue, one-off formatting, immature model experimentation, a sample run, or a business-project decision about when to invoke an existing agent, it should remain in the project repository until it has clear CCPE value.
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.
For engineered cognitive model governance systems such as `the-mindscape-of-bro-tsong`, CCPE supplies architecture, Agent/Runtime contracts, evaluation rules, and integration requests. The product repository owns its governed model cards, model indexes, review runs, process records, and lifecycle decisions. CCPE's `model-cards/` and `model-index/` remain CCPE protocol, template, reference, and historical artifact surfaces unless a concrete CCPE artifact says otherwise.
@ -41,6 +43,10 @@ CCPE System is built around one principle:
> Do not treat every AI artifact as a prompt.
It is also built around a supplier value gate:
> Accept only artifacts that require expert agent capability, cognitive model structure, reusable method design, or durable invocation contracts.
Some artifacts are prompts.
Some are agents.
Some are reusable skills.

View File

@ -13,7 +13,7 @@ a deployed agentic application framework
a copy of upstream methodology documents
```
CCPE is an architecture forge and supplier layer for AI artifacts.
CCPE is an architecture forge and supplier layer for AI artifacts. More specifically, it is the forge for expert agents, cognitive models, reusable methods, and invocation contracts.
## 2. System Position
@ -57,6 +57,8 @@ migration policies
artifact templates
```
CCPE should accept a requested artifact only when it has CCPE value. A request has CCPE value when it requires expert hidden experience, a stable cognitive model, a reusable method, a durable role, a cross-project invocation contract, or high-risk cognitive boundary management. If a request is merely project-local prompt glue, one-off formatting, immature model experimentation, a sample run, or a project decision about when to invoke an existing artifact, CCPE should return it to the owning project repository.
CCPE may design both:
```text
@ -96,6 +98,10 @@ process logs
publication metadata
project handoffs
application code and deployment configuration
project-local prompt adapters and glue prompts
sample runs and trial outputs
model exploration before stable CCPE-worthy versions exist
decisions about when to invoke existing CCPE agents, Skills, runtimes, or external reviewers
```
CCPE may supply the agents, protocols, and rules used by those projects, but it should not store the project-specific run history.

View File

@ -4,9 +4,9 @@
This document defines how to classify AI artifacts inside the CCPE System.
Classification must happen before creation, auditing, refactoring, or migration.
The CCPE value gate and classification must happen before creation, auditing, refactoring, or migration.
Classification must be preceded by scenario probing. Do not decide artifact layers from the artifact's importance alone.
Classification must be preceded by the CCPE value gate and scenario probing. Do not decide artifact layers from the artifact's importance alone.
The goal is to avoid two common errors:
@ -20,7 +20,35 @@ Turning every artifact into a complex Agent / Skill / Runtime system.
Use the lightest structure that preserves clarity, function, reusability, maintainability, and safety.
## 1.1 Supplier Intake Rule
## 1.1 CCPE Value Gate
Before classifying an artifact, decide whether the work belongs in CCPE at all.
CCPE should accept work when it forges at least one of:
```text
expert agent capability
cognitive model structure
reusable method
durable invocation contract
high-risk cognitive boundary management
cross-project reuse
```
CCPE should return work when it is primarily:
```text
project-local prompt glue
one-off output formatting
immature model trial work
sample runs or trial outputs
project-specific orchestration or run records
a business-project decision about when to invoke an existing agent, Skill, runtime, or reviewer
```
If the value gate fails, do not force the request into Lite, Agent, Skill, Runtime, Model Card, or Model Index form. Explain the boundary and route it to the owning project or repository.
## 1.2 Supplier Intake Rule
For project-facing work, do not begin by inventing a CCPE asset from an assumed business scenario.
@ -29,14 +57,15 @@ 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.
3. CCPE applies the value gate.
4. CCPE classifies the requirement and checks repository ownership only if the gate passes.
5. CCPE supplies the smallest appropriate artifact.
6. 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
## 1.3 Scenario Probe First
Before choosing Lite, Agent, Skill, Runtime, Model Card, or Hybrid, determine the real usage scenario.

View File

@ -6,6 +6,8 @@ CCPE System is a context protocol engineering framework for constructing, auditi
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.
CCPE's core value is the forging of expert agents, cognitive models, reusable methods, and invocation contracts. It should not accept every prompt request as CCPE work. Requests that are only project-local prompt glue, one-off formatting, immature model trials, sample runs, or business-project invocation decisions should be returned to the owning project repository.
It exists to solve a structural problem:
> Advanced AI work is no longer only a matter of writing better prompts.
@ -129,6 +131,23 @@ The primary design principle of CCPE is:
> Probe scenario, then classify before designing.
The primary supplier intake rule is:
> Gate for CCPE value before accepting the work.
The work has CCPE value when it requires at least one of:
```text
expert agent capability
cognitive model structure
reusable method design
durable invocation contract
high-risk cognitive boundary management
cross-project reuse
```
If the work does not pass this gate, do not force it into Prompt Card, Agent Spec, Skill, Runtime, or Model Card form. Explain the boundary and route it back to the project repository.
Before creating or modifying an AI artifact, determine how it is or will be used, then determine what it actually is.
Scenario probe should identify:

View File

@ -128,6 +128,14 @@ review-committee.runtime.md
= process that invokes several reviewers and synthesizes outputs
```
For projects and business systems that call CCPE Agents or Lite prompts, record this single CCPE external interface:
```text
Interface.md
```
`Interface.md` routes consumers to the setup contract. The setup contract defines which additional CCPE files should be read for environment checks, invocation packets, specific Runtimes, and participant artifacts. Consumer projects should not memorize multiple CCPE paths as their default interface.
## 6. Runtime vs Skill
A Skill is a reusable capability.

View File

@ -0,0 +1,528 @@
---
artifact_type: ccpe-runtime-consumer-setup
name: ccpe-agent-consumer-setup
protocol_id: ccpe-agent-consumer-setup
author: CCPE System
version: 0.1.0
created: 2026-06-20
updated: 2026-06-20
status: draft
runtime_type: hybrid
target_platform: Codex / Claude Code / OpenClaw / GPT / Gemini / Claude / local business systems
depends_on:
- runtimes/hybrid/agent-invocation-packet.protocol.md
based_on: CCPE System
---
# CCPE Agent Consumer Setup
## 1. Purpose
This document is the single consumer entrypoint for any project or business system that needs to invoke CCPE Agents, Lite prompts, Skills, Runtime nodes, or native participants as formal participants.
It answers one practical question:
```text
What must a consumer project create before it can safely call a CCPE Agent?
```
Consumer projects should record the root interface file as their stable CCPE interface:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md
```
`Interface.md` routes consumer projects to this setup contract. Do not require consumer projects to memorize multiple CCPE protocol, Runtime, Agent, or Skill paths. This setup tells them which additional files to read only when the current task requires them.
This setup does not replace the Agent Invocation Packet Protocol, specific Runtime specs, or canonical Agent artifacts. It routes the consumer project to them at the right time. Its first job is to make the project install a small project-local contract that forces every invocation to bind an agent name to its canonical CCPE artifact before any child thread, subagent, external platform, or local Skill execution is launched.
## 2. Classification
```yaml
primary_classification: ccpe-runtime-consumer-setup
secondary_components:
- cross-project invocation contract
- project-local registry template
- invocation preflight checklist
- no-simulation guard
operating_mode: hybrid
depth_vs_automation: hybrid
owner: ccpe-system
consumer_owner: target project repository
```
CCPE owns this setup contract because it defines a reusable cross-project invocation boundary.
Consumer projects own their own registry files, run directories, prompt-to-send files, returned outputs, decision logs, and project-specific runbooks.
## 3. Single Entry Point Rule
A consumer project must store exactly one default CCPE startup reference:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md
```
When a project starts, repairs its CCPE integration, or prepares to call a CCPE participant, it reads `Interface.md` first, then follows it to this setup file.
After reading this file, it must decide which narrower read set applies:
```text
Environment check only:
Read Interface.md and this setup file.
Verify the CCPE root exists.
Verify the project-local registry exists or can be created.
Prepare or validate invocation packets:
Read Interface.md and this setup file.
Then read runtimes/hybrid/agent-invocation-packet.protocol.md.
Invoke a specific participant:
Read Interface.md and this setup file.
Read the project-local registry.
Resolve participant_id to canonical_artifact_path.
Read or paste that canonical artifact.
Read runtimes/hybrid/agent-invocation-packet.protocol.md when writing the packet.
Run a specific CCPE Runtime:
Read Interface.md and this setup file.
Read the project-local registry or workflow manifest.
Read the named Runtime spec only if the project is actually running that workflow.
Read runtimes/hybrid/agent-invocation-packet.protocol.md when the Runtime invokes participants.
```
Do not read a specific Runtime just because the project might use CCPE. Read a Runtime only when the active workflow names it.
## 4. Interface Layers
Consumer projects should treat CCPE files as four layers:
```text
Layer 0. Consumer entrypoint:
Interface.md
Always read first.
Layer 1. Consumer setup contract:
runtimes/hybrid/ccpe-agent-consumer-setup.md
Read after Interface.md.
Layer 2. Invocation evidence protocol:
runtimes/hybrid/agent-invocation-packet.protocol.md
Read when preparing, validating, or auditing participant invocation.
Layer 3. Workflow Runtime:
runtimes/{interactive|automation|hybrid}/{runtime_id}.runtime.md
Read only when the project is running that specific workflow.
Layer 4. Participant artifact:
agents/lite/*.prompt.md
agents/agent-specs/*.agent.md
skills/**/*.skill.md
Read or paste only for the participant being invoked.
```
The exact canonical artifact path must come from the project-local registry, not from memory, fuzzy search, or the display name alone.
## 5. Consumer Project File Contract
Every consumer project that invokes CCPE participants should create these project-local files.
Recommended default for software or business repositories:
```text
ccpe/
agent-registry.yaml
invocation-policy.md
invocations/
{participant_id}/
{run_id}/
agent-invocation-packet.md
prompt-to-send.md # when needed
returned-output.md # after real return
run-metadata.json
skill-execution-record.md # only for local_skill_execution
```
Recommended default for workbench projects that already have an audit or review folder:
```text
audit/
ccpe-agent-registry.yaml
{participant_id}/
{run_id}/
agent-invocation-packet.md
prompt-to-send.md
returned-output.md
run-metadata.json
skill-execution-record.md
```
The path may vary by project, but the file roles must not vary.
## 6. Project-Local Registry Template
Create one registry per consumer project or per concrete workbench project.
```yaml
schema: ccpe.agent.consumer.registry.v1
project_id:
project_root:
ccpe_system_root: C:\Users\wangq\Documents\Codex\ccpe-system
invocation_protocol_path: C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\agent-invocation-packet.protocol.md
default_run_root: ccpe\invocations
strict_invocation_required: true
no_simulation_requirement: true
defaults:
invocation_mode: prompt_path_reference
carrier_type: codex_thread_participant
role_integrity_requirement: must_load_canonical_artifact_before_task
missing_canonical_behavior: blocked_missing_canonical_artifact
task_prompt_authority: task_context_only
output_structure_authority: canonical_artifact
packet_only_is_execution: false
prompt_to_send_only_is_execution: false
participants:
example-participant-id:
display_name:
canonical_artifact_path:
canonical_artifact_type: ccpe_lite | ccpe_agent | ccpe_skill | ccpe_runtime_node | native_agent | external_agent | human
canonical_artifact_version:
default_invocation_mode: prompt_path_reference
default_carrier_type: codex_thread_participant
role_integrity_requirement: must_load_canonical_artifact_before_task
missing_canonical_behavior: blocked_missing_canonical_artifact
output_structure_authority: canonical_artifact
allowed_wrapper_instructions:
- project_id
- workflow
- stage
- run_id
- input_files
- context_files
- output_path
- output_language_policy
forbidden_role_changes:
- replacing the canonical role
- replacing the canonical tone
- replacing the canonical output structure
- weakening the canonical evaluation method
- treating the task prompt as the role definition
```
## 7. Environment Check
Before creating the registry or launching participants, a consumer project may run an environment check. It should verify:
```text
1. The CCPE entrypoint exists:
C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md
2. The CCPE consumer setup exists:
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccpe-agent-consumer-setup.md
3. The CCPE invocation protocol exists:
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\agent-invocation-packet.protocol.md
4. The project can create or update its project-local registry.
5. Every participant it plans to invoke has a registry entry.
6. Every referenced canonical_artifact_path exists and is readable, or the invocation mode is full_prompt_paste.
7. The project has a run root for invocation records.
```
Environment check is not execution. It may produce or repair registry files, but it must not claim any participant has returned output.
## 8. Standard Participants Example
For article outline review projects that use the current CCPE reviewer trio, the registry entries should look like this:
```yaml
participants:
zhang-liao:
display_name: 张辽
canonical_artifact_path: C:\Users\wangq\Documents\Codex\ccpe-system\agents\lite\zhang-liao.prompt.md
canonical_artifact_type: ccpe_lite
canonical_artifact_version: current
default_invocation_mode: prompt_path_reference
default_carrier_type: codex_thread_participant
role_integrity_requirement: must_load_canonical_artifact_before_task
missing_canonical_behavior: blocked_missing_canonical_artifact
output_structure_authority: canonical_artifact
giant-cognition:
display_name: 巨人
canonical_artifact_path: C:\Users\wangq\Documents\Codex\ccpe-system\agents\lite\giant-cognition.prompt.md
canonical_artifact_type: ccpe_lite
canonical_artifact_version: current
default_invocation_mode: prompt_path_reference
default_carrier_type: codex_thread_participant
role_integrity_requirement: must_load_canonical_artifact_before_task
missing_canonical_behavior: blocked_missing_canonical_artifact
output_structure_authority: canonical_artifact
cognitive-imaging:
display_name: 认知显影
canonical_artifact_path: C:\Users\wangq\Documents\Codex\ccpe-system\agents\lite\cognitive-imaging-practitioner.prompt.md
canonical_artifact_type: ccpe_lite
canonical_artifact_version: current
default_invocation_mode: prompt_path_reference
default_carrier_type: codex_thread_participant
role_integrity_requirement: must_load_canonical_artifact_before_task
missing_canonical_behavior: blocked_missing_canonical_artifact
output_structure_authority: canonical_artifact
```
## 9. Invocation Preflight
Before launching any CCPE participant, the consumer project must complete this preflight:
```text
1. Locate the project-local registry.
2. Resolve participant_id to canonical_artifact_path.
3. Verify the canonical artifact exists and is readable, or prepare full_prompt_paste.
4. Create a run directory.
5. Write agent-invocation-packet.md.
6. Write prompt-to-send.md when the participant carrier needs a startup prompt.
7. Separate canonical role from task context.
8. Include output contract and return path.
9. Launch a real participant carrier.
10. Save returned-output.md only after the real participant returns.
```
If any required canonical artifact is missing or unreadable, stop with:
```text
blocked_missing_canonical_artifact
```
If the participant cannot be truly invoked, stop with:
```text
blocked_waiting_for_participant_output
```
Do not produce a role-played report in the main session.
## 10. Prompt-To-Send Startup Block
When `invocation_mode = prompt_path_reference`, the startup prompt may reference local paths, but it must still force the participant to load the canonical artifact before reading the task prompt.
```md
# Prompt To Send: {participant_id}
You are being invoked as a formal CCPE participant.
First read your canonical CCPE artifact:
{canonical_artifact_path}
This canonical artifact defines your role, tone, judgment method, and output structure.
The task prompt and project files below are task context only. They must not replace your canonical role.
If the canonical artifact is unavailable or unreadable, stop and return:
blocked_missing_canonical_artifact
After loading the canonical artifact, read:
{task_prompt_path_or_embedded_task}
Write the formal output to:
{returned_output_path}
Return metadata:
- participant_id:
- canonical_artifact_path:
- invocation_mode:
- carrier_type:
- thread_id:
- execution_status: returned
- simulation_only: false
```
When `invocation_mode = full_prompt_paste`, paste the full canonical artifact into the prompt-to-send before the task context.
## 11. Agent Invocation Packet Minimum
Every run must include at least:
```yaml
project_id:
workflow:
stage:
run_id:
participant_id:
display_name:
canonical_artifact_path:
canonical_artifact_type:
canonical_artifact_version:
invocation_mode:
carrier_type:
thread_id:
strict_invocation_required: true
simulation_only: false
task_prompt_authority: task_context_only
output_structure_authority: canonical_artifact
path_readability_evidence:
input_files:
context_files:
output_contract:
returned_output_path:
no_simulation_requirement: true
runtime_acceptance_rule:
```
The full field set is defined in:
```text
runtimes/hybrid/agent-invocation-packet.protocol.md
```
## 12. Runtime Selection Rule
A business system does not read all CCPE Runtimes by default.
It reads a specific Runtime only when one of these is true:
```text
- the user explicitly asks for that workflow
- the project-local registry names workflow_runtime_path
- the project-local run manifest names runtime_id
- a previous accepted project decision says this project uses that Runtime
```
Examples:
```text
Article outline development:
Read the article outline development Runtime only when the project is actually running the article outline workflow.
Local CCRA review:
Read runtimes/hybrid/ccra-local-review.runtime.md only when the project is running a Local CCRA review.
Viewpoint discussion distillation:
Read runtimes/hybrid/viewpoint-discussion-distillation.runtime.md only when the project is distilling a long discussion into topic documents or related outputs.
```
If no specific Runtime is named, the consumer project should use this setup file plus the invocation packet protocol only.
## 13. Runtime Acceptance Rule
A consumer project may treat a CCPE participant output as formal only when:
```text
- the project-local registry binds participant_id to canonical_artifact_path
- an agent-invocation-packet.md exists for the run
- a real participant carrier was launched
- the participant loaded or received the canonical artifact
- returned-output.md exists
- returned metadata says simulation_only: false
- packet-only and prompt-to-send-only states are rejected as execution
```
If these are not true, the output is not a formal CCPE participant result.
## 14. Business-System Startup Instruction
Use this instruction when initializing or repairing a business project that will call CCPE Agents:
```md
Before invoking any CCPE Agent, read the single CCPE external interface:
C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md
Then follow Interface.md to the consumer setup contract and create or repair the project-local CCPE agent registry and invocation policy.
Do not invoke a CCPE participant until:
- every participant name is bound to a canonical_artifact_path
- the canonical artifact path is readable or pasted into prompt-to-send.md
- agent-invocation-packet.md will be written for the run
- returned-output.md will be saved only after a real participant returns
- the main session will not simulate formal participant output
Read additional CCPE files only when Interface.md and the consumer setup contract tell you to:
- read agent-invocation-packet.protocol.md when preparing invocation packets
- read a specific Runtime only when the active workflow names it
- read a specific Agent / Lite / Skill artifact only when invoking that participant
```
## 15. Failure Modes This Setup Prevents
```text
Display-name invocation:
The project says "call Zhang Liao" but never binds Zhang Liao to zhang-liao.prompt.md.
Task-prompt role replacement:
The task prompt says "CCPE Zhang Liao" but does not include or reference the canonical prompt.
Generic review drift:
A child thread behaves like a normal reviewer because no canonical artifact was loaded.
Packet-only false positive:
The project creates prompt-to-send.md but treats it as completed execution.
Main-session simulation:
The orchestrator writes what a participant would have said and records it as formal output.
Interface sprawl:
A project is told to read several CCPE paths without a single stable entrypoint or routing rule.
```
## 16. Validation Checklist
```text
Single CCPE entrypoint recorded?
Interface.md exists?
Consumer setup contract exists?
Project-local registry exists?
Registry schema version present?
CCPE system root present?
Invocation protocol path present?
Participant ID present?
Display name present?
Canonical artifact path present?
Canonical artifact readable or fully pasted?
Task prompt marked as task_context_only?
Output structure authority set to canonical_artifact?
Forbidden role changes listed?
Run directory created?
Agent invocation packet written?
Prompt-to-send written when needed?
Real participant carrier recorded?
Returned output saved only after return?
Simulation-only false for formal output?
Packet-only rejected as execution?
Prompt-to-send-only rejected as execution?
```
## 17. Boundary
CCPE supplies:
```text
- this consumer setup contract
- canonical participant artifacts
- Agent Invocation Packet Protocol
- reusable Runtime specs
- reusable Skill specs
- model and evaluation assets when needed
```
The consumer project supplies:
```text
- project-local registry
- project-specific invocation policy
- run directories
- task prompts
- context packs
- returned outputs
- decision logs
- implementation adapters
```
Do not copy project run history into CCPE. Do not copy CCPE canonical prompts into project repositories unless `full_prompt_paste` is required for an external/manual participant.