Add CCPE value gate

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

@@ -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
+1. CCPE Value Gate
-2. Boundary Check
+2. Classification First Gate
-3. Supplier Intake Check
+3. Boundary Check
-4. Depth vs Automation Check
+4. Supplier Intake Check
-5. No-Simulation Check when participants are involved
+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
+2. CCPE value gate
-3. Artifact layer selection
+3. Scenario probe
-4. Artifact classification
+4. Artifact layer selection
-5. Operating mode assessment
+5. Artifact classification
-6. Depth vs automation assessment
+6. Operating mode assessment
-7. Cognitive model check
+7. Depth vs automation assessment
-8. Human decision gate check
+8. Cognitive model check
-9. Creation Brief
+9. Human decision gate check
-10. Proposed file list
+10. Creation Brief
-11. Generate artifact
+11. Proposed file list
-12. Validate artifact
+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?

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

@@ -23,25 +23,33 @@ All CCPE Forge work should follow this high-level sequence:
 
 ```text
 1. Intake
-2. Classification First Gate
+2. CCPE Value Gate
-3. Boundary Check
+3. Classification First Gate
-4. Supplier Intake Check
+4. Boundary Check
-5. Operating Mode Assessment
+5. Supplier Intake Check
-6. Depth vs Automation Assessment
+6. Operating Mode Assessment
-7. Embedded Component Detection
+7. Depth vs Automation Assessment
-8. Risk and Human Decision Gate Check
+8. Embedded Component Detection
-9. Mode-Specific Work
+9. Risk and Human Decision Gate Check
-10. Proposed Outputs
+10. Mode-Specific Work
-11. Validation
+11. Proposed Outputs
-12. Final Response
+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.

.codex/skills/ccpe-forge/references/creator-mode.md

@@ -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
+2. CCPE Value Gate
-3. Intended Use Analysis
+3. Scenario Probe
-4. Target Platform Analysis
+4. Intended Use Analysis
-5. Layer Selection
+5. Target Platform Analysis
-6. Classification
+6. Layer Selection
-7. Operating Mode Assessment
+7. Classification
-8. Depth vs Automation Assessment
+8. Operating Mode Assessment
-9. Model / Skill / Runtime Check
+9. Depth vs Automation Assessment
-10. Creation Brief
+10. Model / Skill / Runtime Check
-11. Proposed Files
+11. Creation Brief
-12. Artifact Draft
+12. Proposed Files
-13. Validation
+13. Artifact Draft
-14. Final Notes
+14. Validation
+15. Final Notes
 ```
 
 ## 3.1 Scenario Probe

AGENTS.md

@@ -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.
+1. Apply the CCPE value gate.
-2. Identify embedded components.
+2. If it fails, return it to the owning project or repository with a short reason.
-3. Recommend target forms.
+3. If it passes, classify it.
-4. Produce a plan.
+4. Identify embedded components.
-5. Wait for confirmation before major rewrite.
+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.
+1. Apply the CCPE value gate.
-2. Decide whether Lite, Agent, Skill, Runtime, Model Card, or Hybrid is appropriate.
+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. Generate the artifact in the correct template.
+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:
 

README.md

@@ -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.

ccpe-protocol/ccpe-boundaries.md

@@ -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.

ccpe-protocol/ccpe-classification-rules.md

@@ -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.
+3. CCPE applies the value gate.
-4. CCPE supplies the smallest appropriate artifact.
+4. CCPE classifies the requirement and checks repository ownership only if the gate passes.
-5. The project repository runs the concrete work and stores execution records.
+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.
 

ccpe-protocol/ccpe-system-definition.md

@@ -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: