ccpe-system/ccpe-protocol/ccpe-migration-policy.md

CCPE Migration Policy

1. Purpose

This document defines how to migrate older CCPE 2.0 artifacts into the new CCPE System.

The migration policy applies to:

Old CCPE 2.0 prompts
Custom GPT / Gem instructions
Single-agent expert prompts
Self-contained model-backed agents
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.

The goal is to identify what each artifact really contains and move each component into its most useful form.

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.

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:

Preserve cognitive power while improving structure.

For mature single-agent expert prompts, preserve the working prompt kernel before extracting components.

Migration should improve:

Clarity
Reusability
Maintainability
Portability
Safety
Evaluation
Model fidelity

Migration should not destroy:

Original metaphor
Conceptual force
Distinctive terminology
User's intellectual intent
Useful personality
Domain-specific sharpness

Do not turn powerful cognitive tools into bland generic templates.

2.1 Scenario Probe

Before migrating an old CCPE 2.0 artifact, determine:

current_usage:
  - Web / GPT / Gemini / Claude single-agent prompt?
  - Codex local workspace artifact?
  - committee member manually invoked by the user?
  - automated workflow node?

planned_usage:
  - copy-paste prompt?
  - Codex-callable Skill?
  - durable Agent Spec?
  - multi-agent Runtime?

orchestration:
  - human manually passes context?
  - a lead agent routes work?
  - system automation routes and synthesizes outputs?

depth_orientation:
  - deep expert thinking?
  - workflow execution?
  - hybrid?

If scenario information is unavailable, produce a scenario assumption and mark it as a migration risk.

Also determine whether the artifact is:

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:

default_migration: CCPE-Lite
recommended_addition: Model Card if the embedded model is stable and valuable
defer: Agent Spec, Skill, Runtime

Create additional layers only when the scenario requires them:

Skill:
  Needed when Codex should invoke the method automatically, or the method is reused across agents.

Agent Spec:
  Needed when the role participates in a durable workflow or committee and needs handoff, authority, and evaluation rules.

Runtime:
  Needed when multiple roles, stages, state, synthesis, archival, tools, or automation must be coordinated.

Do not treat four-layer expansion as a default migration outcome.

2.3 Minimal-Kernel First Rule

For mature CCPE 2.0 single-agent expert prompts, the default first migration should be:

original-ccpe-2
→ original-kernel-minimal-lite
→ optional refined-lite A/B optimization
→ later-layer decision if needed

This rule exists because a full Lite rewrite can improve structure while losing the old prompt's working kernel.

original-kernel-minimal-lite is a simple wrapper around the chosen original source version. It is the highest-ROI migration baseline and a kernel-fidelity reference, not the same thing as a fully optimized refined Lite prompt.

original-kernel-minimal-lite should preserve:

original objective
original method pressure
original report behavior
distinctive terminology
core metaphor when structurally meaningful
domain worldview
productive sharpness

2.3.1 Original Kernel Means Verbatim Kernel

In Fast Migration Lane, Original Kernel means the original CCPE 2.0 prompt kernel is preserved verbatim.

Allowed outside the Original Kernel block:

front matter
classification note
minimal Lite wrapper
platform boundary
source / retrieval boundary
hidden chain-of-thought disclosure repair
output validation discipline
minimal conflict override notes

Forbidden inside the Original Kernel block:

translation
paraphrase
deduplication
section reordering
terminology replacement
workflow rewrite
style smoothing
template normalization

If any forbidden operation is performed on the original prompt body, the artifact is no longer original-kernel-minimal-lite. It is a refined-lite candidate and must enter Refinement Lane before production promotion.

It should add only minimal migration repairs:

platform boundary
hidden reasoning disclosure repair
source / retrieval boundary if needed
output validation discipline
version or status metadata

Do not use a full refined Lite rewrite as the default first move for every mature agent.

2.3.2 Pre-Migration Source Judgment Gate

Before generating or planning original-kernel-minimal-lite for any mature original CCPE 2.0 agent, run a source judgment pass for the original CCPE 2.0 prompt.

The purpose is to decide whether the current source version is good enough to preserve verbatim, or whether the source prompt itself should be repaired first.

This gate must always produce a distinct Original Source Judgment Report before migration.

Do not collapse the Original Source Judgment Report into a general audit summary.

Default report path:

workbench/analysis/{artifact-slug}-original-source-judgment-report.md

If no visible source-level risks are found, the report must explicitly record:

no blocking source-level risks found
source decision: use source as-is

If visible risks are found, the report must classify each finding and recommend a source decision before migration proceeds.

Judgment categories:

Source defect:
  A real flaw in the original prompt body that may degrade output quality.

Platform incompatibility:
  A statement that is acceptable in the old prompt but unsafe or false in the current target platform.

Kernel feature:
  A sharp, strange, severe, or distinctive behavior that looks risky but is part of the prompt's useful force.

Ambiguous finding:
  A possible defect that requires review by the user or by the original CCPE agent.

Typical findings:

omniscience or retrieval claims
hidden chain-of-thought disclosure risk
duplicated sections
contradictory authority rules
outdated tool claims
unsafe factual confidence
unclear output contract
valuable but severe critique style

The report must recommend one of these source decisions:

Use source as-is:
  Generate original-kernel-minimal-lite with the current source body verbatim.

Patch only in wrapper:
  Keep source verbatim, and resolve platform or disclosure conflicts through the wrapper.

Repair source first:
  Create a revised source version, such as v1.2, then use that chosen source version verbatim.

Enter Refinement Lane:
  Do not claim original-kernel-minimal-lite; produce a refined-lite candidate instead.

Human decision gate:

The user must choose the source decision before Fast Migration Lane generates the final minimal-kernel artifact.
The report may be sent to the original CCPE agent on its native platform, such as Gemini, for second judgment.
If the user provides Gemini's reply, a rejection, or a new source prompt version, Codex must align the judgment and migration plan before generating the minimal-kernel artifact.
Codex must not silently repair, translate, deduplicate, reorder, or smooth the original source body before this decision.

2.3.3 Fast Migration Lane

Use Fast Migration Lane when:

the old agent already works
the target is short-term migration or batch upgrade
the user needs low evaluation burden
the artifact is mainly a portable single-agent expert prompt

Fast Migration Lane workflow:

1. Receive the original prompt from the user.
2. Run Source Judgment Gate and produce a distinct Original Source Judgment Report.
3. Let the user choose the source decision, or send the report to the original CCPE agent for second judgment.
4. Align with Gemini / original-agent feedback, user rejection, or a new source prompt version.
5. Preserve the chosen CCPE 2.0 source version verbatim under `## Original Kernel`.
6. Generate `original-kernel-minimal-lite`; this step is mandatory in the original-agent upgrade flow.
7. Stop here by default when batch migration ROI matters.
8. Keep original and any full rewrite candidates as regression references.

If the minimal-kernel version performs acceptably, stop the migration for now.

2.3.4 Refined Lite Optimization Lane

Use this lane only after original-kernel-minimal-lite exists.

This is the formal Lite optimization stage. It is optional, expensive, and should not be treated as the default migration requirement.

Use this lane when:

the agent is high-value or high-frequency
the minimal-kernel version has a concrete weakness
the current Lite must improve production stability or output usability
the user has time and budget for A/B testing

Refined Lite Optimization workflow:

1. Start from original-kernel-minimal-lite, not from a fresh rewrite.
2. Identify a concrete improvement target.
3. Add targeted discipline rules or wrapper changes.
4. Run A/B comparisons against the original and kernel versions.
5. Compare Kernel Force and Production Stability.
6. Promote the refined Lite only if it improves production stability without losing kernel force.
7. If refined Lite loses kernel force, pause and keep original-kernel-minimal-lite.

Regression pattern proven in workbench/analysis/review-agent-regression-2026-06-02:

One agent family:
  3 prompt variants:
    - original-ccpe-2
    - ccpe-system-lite / refined-lite candidate
    - original-kernel-minimal-lite
  2 platforms:
    - ChatGPT / Codex
    - Gemini
  4 article types:
    - strong metaphor
    - business analysis
    - logical argument
    - value philosophy
  24 result files
  1 agent-level regression report

Two agent families:
  48 result files
  2 agent-level reports
  1 strategy summary report

Current known examples:

Cognitive Imaging:
  refined Lite success after multiple A/B rounds.
  Current canonical Lite is beyond original-kernel-minimal-lite.

Giant Cognition:
  intentionally stopped at original-kernel-minimal-lite because that had the best ROI and stronger kernel fidelity.

Zhang Liao:
  intentionally stopped at original-kernel-minimal-lite after source judgment and source alignment.

2.3.5 Later-Layer Decision

Later-layer upgrades are not assumed. Model Card, Skill, Agent Spec, Runtime, and Model Index work should be decided only after:

1. Original Source Judgment Report exists.
2. Source decision is aligned.
3. original-kernel-minimal-lite exists.
4. The user decides whether refined Lite optimization is worth the A/B cost.

2.3.6 Refinement Lane For Non-Lite Layers

Use this lane only when:

the user explicitly wants deeper non-Lite expansion
the usage scenario requires Model Card, Skill, Agent Spec, Runtime, or Model Index work
the original-kernel-minimal-lite and any chosen refined Lite status are already clear

Non-Lite refinement workflow:

1. Identify the target layer and reason for expansion.
2. Produce a layer-specific plan.
3. Extract only what improves reuse, clarity, maintainability, orchestration, or evaluation.
4. Keep the Lite / kernel artifact as the production or regression reference unless the user explicitly changes canonical status.

2.3.7 A/B Budget Rule

Do not spend multi-round A/B testing on every migrated agent.

Default test budget:

Fast Migration Lane:
  no A/B by default; optional small regression only when confidence is unclear

Refined Lite Optimization Lane:
  multiple A/B rounds only for high-value or high-frequency agents

Manual result inspection is a real migration cost and should be reserved for artifacts where the improvement is worth it.

3. Old CCPE 2.0 Layer Mapping

Old CCPE 2.0 used four major layers:

Core Layer
Execution Layer
Constraint Layer
Operation Layer

The new CCPE System expands these into more precise structures.

For CCPE-Lite migration, these four layers remain the preferred prompt-construction kernel:

Core Layer
Execution Layer
Constraint Layer
Operation Layer

Do not collapse a Web-style Lite prompt into an Agent Spec outline if the target use is direct single-agent deployment.

3.1 Core Layer Migration

Old:

Core Layer
= identity, role, professional background, style, values, reasoning preference

New:

Objective Layer
Role Layer
Model Layer if cognitive model is embedded
Collaboration Layer if role participates in workflow

Migration action:

• Extract objective from role description.
• Preserve meaningful role identity.
• Move cognitive model content into Model Layer or Model Card.
• Move collaboration-related content into Collaboration Layer or Runtime.

3.2 Execution Layer Migration

Old:

Execution Layer
= functional range, skills, knowledge base, tools, decision authority

New:

Capability Layer
Context Layer
Tool Layer
Authority Layer
Skill references
Model references

Migration action:

• Separate capability from authority.
• Separate knowledge assumptions from source policy.
• Separate internal methods from reusable Skills.
• Separate tool abilities from general reasoning abilities.
• Replace omniscience with evidence and uncertainty rules.

3.3 Constraint Layer Migration

Old:

Constraint Layer
= hard constraints, soft constraints, safety boundaries, conflict resolution

New:

Constraint Layer
Authority Layer
Safety Rules
Refusal Conditions
Conflict Resolution
Evaluation Layer

Migration action:

• Keep hard constraints.
• Mark soft constraints as preferences.
• Move permission-related rules to Authority Layer.
• Add testable refusal conditions.
• Add evaluation rules where constraints imply quality standards.

3.4 Operation Layer Migration

Old:

Operation Layer
= input processing, context, memory, workflow, output, validation, feedback, exceptions

New:

Context Layer
Workflow Layer
State Layer
Output Layer
Evaluation Layer
Runtime Layer
Collaboration Layer if multi-agent

Migration action:

• Separate input handling from workflow.
• Separate state from memory.
• Replace chain-of-thought requirements with auditable reasoning summaries.
• Move output format to Output Layer.
• Move validation to Evaluation Layer.
• Move long-running process rules to Runtime Layer.

4. Migration Decision Tree

Before migrating, classify the artifact.

4.1 If it is a portable expert prompt

Target:

CCPE-Lite

Actions:

• Keep concise.
• Preserve persona.
• Preserve the four-layer CCPE 2.0 working kernel when the prompt is deep or expert-like.
• Keep necessary workflow, output, validation, and feedback rules.
• Add minimal objective, boundary, and evaluation rules without weakening the original effect.
• Do not extract components unless reuse, indexing, Codex invocation, or workflow participation is likely.

4.2 If it is a durable work role

Target:

CCPE-Agent

Actions:

• Add input/output contract.
• Add authority rules.
• Add collaboration rules if applicable.
• Add evaluation criteria.
• Reference Skills and Models instead of embedding everything.

4.3 If it contains a reusable procedure

Target:

CCPE-Skill

Actions:

• Extract trigger conditions.
• Define inputs and outputs.
• Define procedure.
• Add validation and failure handling.
• Reference the Skill from relevant Agents.

4.4 If it contains a cognitive model

Target:

Model Card

Actions:

• Extract model name, scope, assumptions, mechanism, procedure, failure modes, and falsification boundary.
• Keep source trace.
• Add related agents and skills.
• Register in Model Index if accepted.

4.5 If it coordinates multiple roles or stages

Target:

CCPE-Runtime

Actions:

• Define stages.
• Define participants.
• Define handoff.
• Define state.
• Define human decision gates.
• Define automation boundaries.
• Define outputs and archival rules.

5. Self-Contained Model Agent Migration

Many old agents combine:

Role
Model
Method
Workflow
Output format
Tool policy

This is common and acceptable in CCPE 2.0.

In the new system, inspect whether to split.

5.1 Migration Pattern

Preferred pattern:

Original self-contained agent
→ Portable Lite Prompt
→ Durable Agent Spec
→ Model Card
→ Executable Skill
→ Runtime node if needed

Not all outputs are always required.

For mature Web-style expert agents, the preferred initial pattern is:

Original self-contained agent
→ Original Source Judgment Report
→ original-kernel-minimal-lite preserving the original working kernel
→ optional refined Lite A/B optimization only when cost is justified
→ later-layer decision only if the usage scenario requires it

The Lite or kernel-preserving prompt is not a byproduct. In single-agent scenarios it is the primary production artifact or regression reference.

For mature expert prompts, prefer this staged pattern before full refinement:

Original self-contained agent
→ original-kernel-minimal-lite
→ optional refined Lite A/B optimization only when cost is justified
→ Model Card / Skill / Agent Spec / Runtime only after the Lite status is clear

Do not confuse a refined Lite success case with a default migration requirement.

5.2 Example Pattern

Original:

Cognitive Imaging Specialist

Possible migration:

cognitive-imaging-specialist.prompt.md
cognitive-imaging-specialist.agent.md
cognitive-imaging-model.md
cognitive-imaging.skill.md
review-committee.runtime.md reference

5.3 Keep Lite Version When

• The user wants copy-paste deployment.
• The agent is used in GPT / Gemini / Claude.
• The model is short enough to embed.
• Platform cannot load external references.
• One-piece portability matters.

5.4 Extract Model Card When

• The model is an intellectual asset.
• The model appears in multiple agents.
• The model comes from long-form writing.
• The model deserves indexing.
• The model has independent value.

5.5 Extract Skill When

• The method is reusable.
• The method has stable steps.
• The method can be called by multiple agents.
• The method has clear inputs and outputs.
• The method can be validated.

5.6 Create Agent Spec When

• The role will be maintained over time.
• The role participates in workflows.
• The role needs authority and collaboration rules.
• The role calls Skills or tools.
• The role has evaluation criteria.

5.7 Create Runtime When

• Multiple agents are involved.
• Outputs are routed or synthesized.
• Human approval gates exist.
• State must be tracked.
• Automation is introduced.

6. CoT and Reasoning Migration

Old prompts may include instructions such as:

Must include internal thought
Must show chain of thought
Must reveal full reasoning process

Migrate these instructions.

6.1 Replace With

Reasoning Summary
Decision Criteria
Validation Checklist
Assumptions
Evidence Used
Uncertainty Notes
Intermediate Findings
Self-Check Results

6.2 Do Not Require

Full hidden chain-of-thought
Private internal reasoning
Raw scratchpad

6.3 Acceptable Pattern

Before final output, perform internal analysis.
In the response, provide:
- Key assumptions
- Reasoning summary
- Main checks performed
- Uncertainty or failure points
- Final conclusion

7. Retrieval and Source Policy Migration

Old prompts may say:

Can use online search
Can use latest facts
Can retrieve external data

Migrate to explicit Source Policy.

7.1 Required Fields

When retrieval is required
What sources are acceptable
How retrieved facts are treated
How source conflicts are handled
How uncertainty is marked
Whether retrieved material is evidence, raw material, or context

7.2 Example

Retrieved data is not self-evident truth.
It is treated as raw observational material.
The agent must distinguish:
- reported fact
- interpretation
- correlation
- causal claim
- noise

8. Tool Policy Migration

Old prompts may mention tools informally.

Migrate informal tool rules into Tool Layer and Authority Layer.

8.1 Required Fields

Tool Name
Purpose
Allowed Use
Trigger Conditions
Input
Output
Permission Level
Failure Handling
Validation

8.2 Authority Mapping

Separate:

Can propose tool use
Can invoke tool automatically
Requires confirmation
Forbidden tool use

9. Output Format Migration

Old prompts may contain long report formats.

Migrate output formats into Output Layer.

9.1 Keep

Distinctive report sections
Useful terminology
Required analysis fields
Downstream usability

9.2 Remove or Simplify

Duplicate sections
Ceremonial headings with no function
Excessive mandatory verbosity
Unclear formatting

9.3 Add

Concise mode if needed
Full report mode if needed
Follow-up discussion mode if needed
Delivery checklist
Output hierarchy rules

9.4 Output Structure Discipline

When migrating old prompts with report formats, preserve useful sections but repair hierarchy.

Keep:
  Distinctive section names, required fields, and downstream-useful report shape.

Repair:
  Flattened list levels, ambiguous heading hierarchy, repeated fields, and formatting that hides conclusions.

Require:
  Each major section should begin with a clear judgment, followed by supporting evidence or subpoints.

10. Constraint Migration

Old hard constraints should be preserved when still useful.

But separate:

Safety constraint
Quality constraint
Role boundary
Permission rule
Evaluation requirement

10.1 Example

Old:

Must always follow five-step workflow.

Possible migration:

For full report mode, execute five-step workflow.
For follow-up discussion mode, use the relevant step only.
For non-CAS input, refuse or switch to general analysis.

This preserves rigor while reducing unnecessary rigidity.

10A. Concept and Reconstruction Discipline

When migrating critique, review, modeling, or pressure-test agents, add rules that prevent false targets.

10A.1 Concept Function Discipline

Before testing or refactoring a concept, classify its function:

lens
claim
metaphor
mechanism
generator
procedure
constraint
output form

Do not force a lens, metaphor, or local heuristic to carry full causal-generator responsibility unless the source artifact explicitly or implicitly assigns that role.

10A.2 Reconstruction Discipline

When testing implicit claims:

1. Separate explicit source claims from reconstructed claims.
2. Mark reconstructed claims before testing them.
3. Use the strongest plausible reconstruction, not a straw version.
4. Note uncertainty when source intent is ambiguous.

11. Multi-Agent Migration

Old multi-agent systems may exist as separate prompts manually coordinated by the user.

Do not assume immediate automation. First determine whether the current system is:

Manual committee:
  The user manually invokes each agent and passes context.

Lead-agent committee:
  A director / project manager agent coordinates known members.

Automated Runtime:
  The system routes, stores, synthesizes, and resumes work.

Migrate into full Runtime only when state, handoff, synthesis, archival, or automation is actually needed:

Runtime Spec
+ Member Agent Specs
+ Shared Skills
+ Human Decision Gates
+ Output Synthesis Rules
+ Archival Rules

11.1 Pre-Composed Committee Pattern

Use this pattern for stable human-led committees.

Committee Runtime
├── Director Agent
├── Specialist Agents
├── Shared Skills
├── State Rules
├── Human Decision Gates
├── Synthesis Rules
└── Knowledge Archival Rules

11.2 Do Not Default to Dynamic Agent Creation

If roles are already known and valuable, preserve them.

Dynamic role generation is optional, not default.

12. Model Index Migration

When extracting models from old artifacts or articles, update Model Index.

12.1 Required Index Fields

Model Name
Model Type
Layer
Status
Source
Related Models
Related Agents
Related Skills
Runtime Usage
Canonical Path
Review Status

12.2 Candidate vs Canonical

Do not promote extracted models to canonical status automatically.

Use statuses:

candidate
draft
active
deprecated
archived

Human confirmation is required to promote important models.

13. Migration Output Format

Every migration should produce an Upgrade Report.

Use this format:

# CCPE Upgrade Report

## 1. Original Artifact
Name:
Path:
Version:
Original Format:

## 2. Original Classification
Primary:
Secondary Components:
Operating Mode:
Depth vs Automation:

## 3. Target Classification
Primary:
Secondary Outputs:
Runtime Need:

## 4. Preserved Elements
...

## 5. Extracted Elements
...

## 6. Modified Elements
...

## 7. Deprecated or Removed Elements
...

## 8. Generated Files
...

## 9. Model Index Updates
...

## 10. Human Decisions Required
...

## 11. Next Step
...

14. Migration Severity

Use severity labels for problems:

S = Must fix before reuse
A = Major issue
B = Should improve
C = Minor cleanup

14.1 S-Level Issues

Examples:

Unsafe tool authority
Contradictory instructions
No clear objective
High-risk automation without human approval
Model flattened into false universality

14.2 A-Level Issues

Examples:

Model and role too tightly coupled
No source policy for retrieval
No evaluation criteria
Workflow unclear
Scope boundary vague

14.3 B-Level Issues

Examples:

Output format too long
Duplicate sections
Skill extraction opportunity
Missing version metadata

14.4 C-Level Issues

Examples:

Naming inconsistency
Minor formatting issues
Section order could improve

15. Migration Safety Rules

Before modifying files:

1. Read the artifact.
2. Classify it.
3. Produce a migration plan.
4. List proposed output files.
5. Ask for confirmation before large changes.
6. Write upgraded drafts first.
7. Do not overwrite originals.
8. Preserve an archive copy if replacing canonical versions.

16. Migration Completion Criteria

A migration is complete when:

Scenario probe is documented.
The artifact has a clear target form.
Embedded models are handled.
Reusable Skills are identified or extracted.
Runtime needs are addressed or explicitly rejected.
Agent Spec and Skill extraction are justified by usage scenario.
Human decision gates are defined where needed.
Output format is usable.
Evaluation criteria exist.
Model Index is updated when relevant.
Original intent is preserved.
Original working prompt kernel is preserved when target is Lite.
Regression test or comparison is planned for mature agents.
Fast Migration Lane or Refinement Lane is explicitly chosen for mature Lite migrations.
Kernel Force and Production Stability are both considered before promotion.

17. Final Rule

Migration is not modernization theater.

Do not split an artifact just because the new system has more categories.

Split only when it improves reuse, clarity, safety, evaluation, or long-term maintenance.

Preserve the portable Lite form when it remains useful.

Upgrade the structure without sanding off the mind behind it.