1038 lines
21 KiB
Markdown
1038 lines
21 KiB
Markdown
# CCPE Quality Rubric
|
|
|
|
## 1. Purpose
|
|
|
|
This rubric defines how to evaluate the quality of CCPE artifacts.
|
|
|
|
It applies to:
|
|
|
|
```text id="bd8ps2"
|
|
CCPE-Lite Prompt Cards
|
|
CCPE-Agent Specs
|
|
CCPE-Skill Specs
|
|
CCPE-Runtime Specs
|
|
Model Cards
|
|
Model Indexes
|
|
Hybrid artifacts
|
|
```
|
|
|
|
The goal is not to reward length or complexity.
|
|
|
|
The goal is to judge whether the artifact is clear, useful, safe, reusable, maintainable, and faithful to its underlying cognitive structure.
|
|
|
|
## 2. Scoring Scale
|
|
|
|
Use this scale for each criterion:
|
|
|
|
```text id="0854wz"
|
|
0 = Missing
|
|
1 = Weak
|
|
2 = Adequate
|
|
3 = Strong
|
|
4 = Excellent
|
|
```
|
|
|
|
Optional severity labels:
|
|
|
|
```text id="j2hl0u"
|
|
S = Structural blocker
|
|
A = Major issue
|
|
B = Moderate issue
|
|
C = Minor issue
|
|
```
|
|
|
|
## 3. Core Evaluation Criteria
|
|
|
|
The main criteria are:
|
|
|
|
```text id="diif3r"
|
|
1. Purpose Fit
|
|
2. Scenario Fit
|
|
3. Classification Accuracy
|
|
4. Structural Clarity
|
|
5. Boundary Precision
|
|
6. Capability Realism
|
|
7. Context Handling
|
|
8. Model Fidelity
|
|
9. Lite Kernel Fidelity
|
|
10. Skill Reusability
|
|
11. Authority Clarity
|
|
12. Workflow Coherence
|
|
13. State Awareness
|
|
14. Output Usability
|
|
15. Evaluation Strength
|
|
16. Human-in-the-Loop Design
|
|
17. Runtime Safety
|
|
18. Portability
|
|
19. Maintainability
|
|
20. Intellectual Flavor Preservation
|
|
```
|
|
|
|
Not every criterion applies equally to every artifact.
|
|
|
|
## 4. Purpose Fit
|
|
|
|
### 4.1 Question
|
|
|
|
Does the artifact clearly serve its intended purpose?
|
|
|
|
### 4.2 Good Signs
|
|
|
|
```text id="zlzxbx"
|
|
Primary objective is explicit.
|
|
Success criteria are defined.
|
|
Non-goals are stated.
|
|
The artifact does not drift beyond its purpose.
|
|
The form matches the use case.
|
|
```
|
|
|
|
### 4.3 Bad Signs
|
|
|
|
```text id="s8mnqq"
|
|
Role is vivid but goal is vague.
|
|
The artifact tries to do everything.
|
|
Output does not match the intended work.
|
|
The user cannot tell what good performance means.
|
|
```
|
|
|
|
### 4.4 Common Fixes
|
|
|
|
```text id="pwtws6"
|
|
Add Objective Layer.
|
|
Add Non-Goals.
|
|
Add Success Criteria.
|
|
Remove unrelated capabilities.
|
|
```
|
|
|
|
## 4A. Scenario Fit
|
|
|
|
### 4A.1 Question
|
|
|
|
Does the artifact form match how the user actually uses or plans to use it?
|
|
|
|
### 4A.2 Good Signs
|
|
|
|
```text
|
|
Usage scenario is explicit.
|
|
Target platform is explicit.
|
|
Single-agent vs multi-agent use is clear.
|
|
Manual orchestration vs automation is clear.
|
|
Codex-callable Skill need is justified.
|
|
The artifact is not expanded beyond scenario needs.
|
|
```
|
|
|
|
### 4A.3 Bad Signs
|
|
|
|
```text
|
|
A Web-style expert prompt is overbuilt as a full Runtime.
|
|
A committee member is converted to Agent Spec before collaboration needs are clear.
|
|
A Codex Skill is omitted even though automatic invocation is required.
|
|
Scenario assumptions are hidden.
|
|
The artifact is classified only from its content, not its use.
|
|
```
|
|
|
|
### 4A.4 Common Fixes
|
|
|
|
```text
|
|
Run Scenario Probe.
|
|
Document current and planned usage.
|
|
Choose Lite / Agent / Skill / Runtime from scenario evidence.
|
|
Defer unnecessary layers.
|
|
```
|
|
|
|
## 5. Classification Accuracy
|
|
|
|
### 5.1 Question
|
|
|
|
Is the artifact classified correctly as Lite, Agent, Skill, Runtime, Model Card, Model Index, or Hybrid?
|
|
|
|
### 5.2 Good Signs
|
|
|
|
```text id="cq0rxr"
|
|
The primary form is clear.
|
|
Embedded components are identified.
|
|
Hybrid structure is acknowledged when needed.
|
|
No unnecessary complexity is added.
|
|
No complex artifact is flattened into a prompt.
|
|
Mature single-agent prompts are not expanded without scenario evidence.
|
|
```
|
|
|
|
### 5.3 Bad Signs
|
|
|
|
```text id="ds7a5s"
|
|
A full workflow is written as one prompt.
|
|
A reusable model is trapped inside one agent.
|
|
A simple expert prompt is overbuilt as Runtime.
|
|
A tool procedure is mixed into persona instructions.
|
|
Every mature prompt is automatically split into Lite + Agent + Skill + Runtime.
|
|
```
|
|
|
|
### 5.4 Common Fixes
|
|
|
|
```text id="fucbgb"
|
|
Reclassify.
|
|
Split into Model Card, Skill, Agent Spec, or Runtime.
|
|
Preserve a Lite version if portability matters.
|
|
```
|
|
|
|
## 6. Structural Clarity
|
|
|
|
### 6.1 Question
|
|
|
|
Can a human or AI system understand how the artifact is organized?
|
|
|
|
### 6.2 Good Signs
|
|
|
|
```text id="j855g5"
|
|
Sections are logically ordered.
|
|
Objective, role, capabilities, constraints, workflow, and output are distinguishable.
|
|
No major duplicate sections.
|
|
No contradictory instructions.
|
|
```
|
|
|
|
### 6.3 Bad Signs
|
|
|
|
```text id="ock6oj"
|
|
Same concept appears in multiple places with different meanings.
|
|
Workflow is repeated.
|
|
Capability and authority are confused.
|
|
Model and persona are fused without explanation.
|
|
```
|
|
|
|
### 6.4 Common Fixes
|
|
|
|
```text id="u1ux5r"
|
|
Reorganize using CCPE Layer Spec.
|
|
Remove duplicate sections.
|
|
Separate Agent, Skill, Model, and Runtime components.
|
|
```
|
|
|
|
## 7. Boundary Precision
|
|
|
|
### 7.1 Question
|
|
|
|
Does the artifact clearly define what it should not do?
|
|
|
|
### 7.2 Good Signs
|
|
|
|
```text id="6t5zuy"
|
|
Hard constraints are explicit.
|
|
Soft constraints are marked as preferences.
|
|
Refusal conditions are clear.
|
|
Conflict resolution rules exist.
|
|
Scope boundaries are testable.
|
|
```
|
|
|
|
### 7.3 Bad Signs
|
|
|
|
```text id="ajccf0"
|
|
Artifact accepts any input.
|
|
Constraints are vague.
|
|
It cannot say when the task is inappropriate.
|
|
It claims universal applicability.
|
|
```
|
|
|
|
### 7.4 Common Fixes
|
|
|
|
```text id="fzfm5p"
|
|
Add Scope.
|
|
Add Non-Goals.
|
|
Add Refusal Conditions.
|
|
Add Failure Conditions.
|
|
Add Conflict Resolution.
|
|
```
|
|
|
|
## 8. Capability Realism
|
|
|
|
### 8.1 Question
|
|
|
|
Are the stated capabilities realistic and executable?
|
|
|
|
### 8.2 Good Signs
|
|
|
|
```text id="m82chn"
|
|
Capabilities match available context and tools.
|
|
Internal reasoning is separated from external actions.
|
|
No claims of omniscience.
|
|
Tool-dependent abilities are marked.
|
|
```
|
|
|
|
### 8.3 Bad Signs
|
|
|
|
```text id="5bqx3h"
|
|
Claims all-domain mastery without source policy.
|
|
Says it can verify facts without retrieval.
|
|
Promises perfect correctness.
|
|
Uses phrases like all-knowing mode.
|
|
```
|
|
|
|
### 8.4 Common Fixes
|
|
|
|
```text id="bzzd0t"
|
|
Add Source Policy.
|
|
Add Tool Preconditions.
|
|
Add Uncertainty Handling.
|
|
Replace omniscient language with evidence-based rules.
|
|
```
|
|
|
|
## 9. Context Handling
|
|
|
|
### 9.1 Question
|
|
|
|
Does the artifact define what context it uses and how?
|
|
|
|
### 9.2 Good Signs
|
|
|
|
```text id="ioyxpb"
|
|
Input contract is clear.
|
|
User-provided context is prioritized.
|
|
Retrieved context is treated critically.
|
|
Memory and state are separated.
|
|
Source priority exists.
|
|
Uncertainty is acknowledged.
|
|
```
|
|
|
|
### 9.3 Bad Signs
|
|
|
|
```text id="wjda9a"
|
|
External search is assumed but not specified.
|
|
User context and model assumptions are mixed.
|
|
Old knowledge is treated as current.
|
|
Retrieved material is treated as truth.
|
|
```
|
|
|
|
### 9.4 Common Fixes
|
|
|
|
```text id="5f2913"
|
|
Add Input Contract.
|
|
Add Source Priority.
|
|
Add Retrieval Policy.
|
|
Add Context Refresh Rules.
|
|
Add Uncertainty Handling.
|
|
```
|
|
|
|
## 10. Model Fidelity
|
|
|
|
### 10.1 Question
|
|
|
|
If the artifact uses a cognitive model, does it preserve the model accurately?
|
|
|
|
### 10.2 Good Signs
|
|
|
|
```text id="5bubj1"
|
|
Core assumptions are preserved.
|
|
Mechanism is clear.
|
|
Scope is defined.
|
|
Failure modes are included.
|
|
Falsification boundary exists.
|
|
Original terminology is retained when meaningful.
|
|
Concepts are separated by function: lens, claim, mechanism, generator, metaphor, output format.
|
|
Inferred claims are marked as reconstructions rather than attributed as explicit source claims.
|
|
```
|
|
|
|
### 10.3 Bad Signs
|
|
|
|
```text id="un57a5"
|
|
Model is reduced to generic advice.
|
|
Metaphor is kept but mechanism is lost.
|
|
The model becomes too broad to be falsifiable.
|
|
Important edge cases are removed.
|
|
A useful lens is incorrectly treated as a causal generator.
|
|
The artifact attacks a reconstructed claim as if it were stated by the source.
|
|
```
|
|
|
|
### 10.4 Common Fixes
|
|
|
|
```text id="uj2zq6"
|
|
Create Model Card.
|
|
Restore core mechanism.
|
|
Add scope and failure modes.
|
|
Add falsification boundary.
|
|
Separate model from agent persona.
|
|
Add Concept Function Discipline.
|
|
Add Reconstructed Claim Labeling.
|
|
```
|
|
|
|
## 10A. Lite Kernel Fidelity
|
|
|
|
### 10A.1 Question
|
|
|
|
When the target is CCPE-Lite, does the artifact preserve the single-agent prompt kernel that makes it work in Web / GPT / Gemini / Claude style environments?
|
|
|
|
### 10A.2 Good Signs
|
|
|
|
```text
|
|
Core / Execution / Constraint / Operation are present or clearly compressed.
|
|
The prompt can be copied into a chat product and used directly.
|
|
The output standard and workflow are operational, not merely descriptive.
|
|
Original voice and working behavior are preserved for migrated mature agents.
|
|
Regression testing against the old prompt is planned or documented.
|
|
```
|
|
|
|
### 10A.3 Bad Signs
|
|
|
|
```text
|
|
The Lite prompt reads like a shortened Agent Spec.
|
|
The old prompt's practical force is lost.
|
|
The workflow no longer produces the expected output.
|
|
The prompt depends on external files unavailable in Web environments.
|
|
The migration improves structure but worsens production behavior.
|
|
```
|
|
|
|
### 10A.4 Common Fixes
|
|
|
|
```text
|
|
Restore the CCPE 2.0 four-layer prompt kernel.
|
|
Use Outside-In construction.
|
|
Embed necessary model and output rules for portability.
|
|
Add regression comparison against the old agent.
|
|
Move nonessential governance details out of Lite.
|
|
```
|
|
|
|
## 10B. Concept Function Discipline
|
|
|
|
### 10B.1 Question
|
|
|
|
Does the artifact distinguish what each concept is doing before evaluating or operationalizing it?
|
|
|
|
### 10B.2 Good Signs
|
|
|
|
```text
|
|
Concepts are classified as lens, claim, metaphor, mechanism, generator, procedure, constraint, or output form.
|
|
Evaluation does not force every useful lens to become a causal generator.
|
|
Metaphors are tested for structural function before being kept or removed.
|
|
Pressure tests target the right object.
|
|
```
|
|
|
|
### 10B.3 Bad Signs
|
|
|
|
```text
|
|
A lens is judged as if it were a full causal mechanism.
|
|
A metaphor is dismissed before its structural function is checked.
|
|
A procedure is treated as a model.
|
|
A local heuristic is promoted into a universal law.
|
|
```
|
|
|
|
### 10B.4 Common Fixes
|
|
|
|
```text
|
|
Add concept-function labels.
|
|
Separate lens validity from generator validity.
|
|
Test metaphors for operational function.
|
|
Mark local heuristics and scope boundaries.
|
|
```
|
|
|
|
## 10C. Reconstruction Discipline
|
|
|
|
### 10C.1 Question
|
|
|
|
When an artifact tests an implicit claim, does it label the claim as a reconstruction and avoid attributing it as an explicit source statement?
|
|
|
|
### 10C.2 Good Signs
|
|
|
|
```text
|
|
Explicit source claims are separated from inferred claims.
|
|
Reconstructed claims are marked before testing.
|
|
The strongest plausible version is tested, not a weaker caricature.
|
|
Ambiguous source intent is marked as uncertain.
|
|
```
|
|
|
|
### 10C.3 Bad Signs
|
|
|
|
```text
|
|
The artifact criticizes a claim the source did not make.
|
|
A nuanced concept is reconstructed as a crude opposite.
|
|
The pressure test wins by changing the original claim into a weaker version.
|
|
```
|
|
|
|
### 10C.4 Common Fixes
|
|
|
|
```text
|
|
Label reconstructed claims.
|
|
Quote or summarize the explicit source claim separately.
|
|
Use a charitable strong-form reconstruction.
|
|
Add uncertainty notes when the source intent is ambiguous.
|
|
```
|
|
|
|
## 10D. Output Structure Discipline
|
|
|
|
### 10D.1 Question
|
|
|
|
Does the output structure help the user inspect, compare, and reuse the result?
|
|
|
|
### 10D.2 Good Signs
|
|
|
|
```text
|
|
Markdown hierarchy is clean.
|
|
List nesting matches conceptual hierarchy.
|
|
Each section starts with a judgment before supporting detail.
|
|
Formatting does not obscure the conclusion.
|
|
```
|
|
|
|
### 10D.3 Bad Signs
|
|
|
|
```text
|
|
Everything is flattened into one list level.
|
|
Bullets, headings, and paragraphs compete for hierarchy.
|
|
The output is formally structured but hard to scan.
|
|
The result is correct but difficult to use downstream.
|
|
```
|
|
|
|
### 10D.4 Common Fixes
|
|
|
|
```text
|
|
Define output hierarchy rules.
|
|
Keep evidence subordinate to judgments.
|
|
Use consistent heading levels.
|
|
Add a final usable summary or next-step section.
|
|
```
|
|
|
|
## 11. Skill Reusability
|
|
|
|
### 11.1 Question
|
|
|
|
If the artifact contains a reusable method, can it be extracted as a Skill?
|
|
|
|
### 11.2 Good Signs
|
|
|
|
```text id="3a6yeh"
|
|
Method has clear trigger conditions.
|
|
Steps are stable.
|
|
Inputs and outputs are definable.
|
|
Multiple agents could use it.
|
|
Validation is possible.
|
|
```
|
|
|
|
### 11.3 Bad Signs
|
|
|
|
```text id="mh03n0"
|
|
Reusable procedure is buried in persona.
|
|
Method is duplicated across several agents.
|
|
Tool use is described inconsistently.
|
|
No clear output or failure handling.
|
|
```
|
|
|
|
### 11.4 Common Fixes
|
|
|
|
```text id="5rj80t"
|
|
Extract Skill.
|
|
Add input/output contract.
|
|
Add execution workflow.
|
|
Add validation criteria.
|
|
Reference Skill from Agent.
|
|
```
|
|
|
|
## 12. Authority Clarity
|
|
|
|
### 12.1 Question
|
|
|
|
Does the artifact define what it can do autonomously and what requires human approval?
|
|
|
|
### 12.2 Good Signs
|
|
|
|
```text id="pkkpqn"
|
|
Autonomous actions are defined.
|
|
Confirmation-required actions are defined.
|
|
Forbidden actions are defined.
|
|
Human decision gates are explicit.
|
|
Risk levels are considered.
|
|
```
|
|
|
|
### 12.3 Bad Signs
|
|
|
|
```text id="4pd9di"
|
|
Agent can rewrite or execute without approval.
|
|
Tool permissions are implied.
|
|
Authority is mixed with capability.
|
|
No escalation rule exists.
|
|
```
|
|
|
|
### 12.4 Common Fixes
|
|
|
|
```text id="t2lsyl"
|
|
Add Authority Layer.
|
|
Add Human Decision Gates.
|
|
Add Tool Permission Rules.
|
|
Add Forbidden Actions.
|
|
```
|
|
|
|
## 13. Workflow Coherence
|
|
|
|
### 13.1 Question
|
|
|
|
Does the workflow proceed logically and reliably?
|
|
|
|
### 13.2 Good Signs
|
|
|
|
```text id="8i4rkd"
|
|
Steps are ordered.
|
|
Branch conditions are defined.
|
|
Stop conditions exist.
|
|
Fallback behavior exists.
|
|
Discussion and execution modes are distinct.
|
|
```
|
|
|
|
### 13.3 Bad Signs
|
|
|
|
```text id="fkkkgs"
|
|
Workflow repeats itself.
|
|
The agent must always follow a long process even when unnecessary.
|
|
No handling for poor input.
|
|
No distinction between new request and follow-up discussion.
|
|
```
|
|
|
|
### 13.4 Common Fixes
|
|
|
|
```text id="ii44vr"
|
|
Define Main Workflow.
|
|
Add Branch Logic.
|
|
Add Stop Conditions.
|
|
Add Fallback Workflow.
|
|
Separate Report Mode from Discussion Mode.
|
|
```
|
|
|
|
## 14. State Awareness
|
|
|
|
### 14.1 Question
|
|
|
|
Does the artifact need to track state, and if so, does it do so explicitly?
|
|
|
|
### 14.2 Good Signs
|
|
|
|
```text id="jmv9yk"
|
|
Session state is defined.
|
|
Persistent state is defined if needed.
|
|
Decision logs are specified.
|
|
Open questions are tracked.
|
|
Resume rules exist.
|
|
```
|
|
|
|
### 14.3 Bad Signs
|
|
|
|
```text id="ai11ea"
|
|
Long-running process has no state.
|
|
Committee workflow does not track decisions.
|
|
Model Index updates have no source or review status.
|
|
Agent remembers vaguely without rules.
|
|
```
|
|
|
|
### 14.4 Common Fixes
|
|
|
|
```text id="a77a5t"
|
|
Add State Layer.
|
|
Add Decision Log.
|
|
Add Version Markers.
|
|
Add Resume Rules.
|
|
Add Model Index status fields.
|
|
```
|
|
|
|
## 15. Output Usability
|
|
|
|
### 15.1 Question
|
|
|
|
Is the output useful, structured, and appropriate for the task?
|
|
|
|
### 15.2 Good Signs
|
|
|
|
```text id="791dk3"
|
|
Output format is explicit.
|
|
Required sections are clear.
|
|
Output matches user workflow.
|
|
Actionable next steps are included.
|
|
No unnecessary verbosity.
|
|
```
|
|
|
|
### 15.3 Bad Signs
|
|
|
|
```text id="pk87zs"
|
|
Output is generic.
|
|
Output is too long to use.
|
|
No prioritization.
|
|
No summary or action path.
|
|
Report format does not match the user's work.
|
|
```
|
|
|
|
### 15.4 Common Fixes
|
|
|
|
```text id="g0o9lo"
|
|
Add Output Layer.
|
|
Add Delivery Checklist.
|
|
Add prioritization.
|
|
Add concise and full modes.
|
|
Add downstream usage target.
|
|
```
|
|
|
|
## 16. Evaluation Strength
|
|
|
|
### 16.1 Question
|
|
|
|
Can the artifact's work be checked?
|
|
|
|
### 16.2 Good Signs
|
|
|
|
```text id="wnhmon"
|
|
Quality rubric exists.
|
|
Validation checklist exists.
|
|
Failure criteria are defined.
|
|
Human acceptance criteria are clear.
|
|
Test cases exist for important artifacts.
|
|
```
|
|
|
|
### 16.3 Bad Signs
|
|
|
|
```text id="23uqet"
|
|
No way to tell if output is good.
|
|
Agent self-declares success.
|
|
No falsification boundary for models.
|
|
No test cases for Skills or Runtimes.
|
|
```
|
|
|
|
### 16.4 Common Fixes
|
|
|
|
```text id="c6a9kd"
|
|
Add Evaluation Layer.
|
|
Add validation checklist.
|
|
Add failure conditions.
|
|
Add test cases.
|
|
Add human review protocol.
|
|
```
|
|
|
|
## 17. Human-in-the-Loop Design
|
|
|
|
### 17.1 Question
|
|
|
|
Does the artifact correctly preserve human judgment where needed?
|
|
|
|
### 17.2 Good Signs
|
|
|
|
```text id="7qawty"
|
|
Human decision gates are explicit.
|
|
Human owns final judgment in deep work.
|
|
Automation boundaries are clear.
|
|
The artifact asks for confirmation before risky actions.
|
|
```
|
|
|
|
### 17.3 Bad Signs
|
|
|
|
```text id="ck2ejn"
|
|
Agent silently decides major conceptual questions.
|
|
Automation is applied to high-uncertainty thinking.
|
|
Human role is vague.
|
|
Committee workflow lacks stage approval.
|
|
```
|
|
|
|
### 17.4 Common Fixes
|
|
|
|
```text id="uu0mhr"
|
|
Add Human Decision Gates.
|
|
Add Stage Approval.
|
|
Add Escalation Rules.
|
|
Mark depth-oriented tasks as non-fully-automatable.
|
|
```
|
|
|
|
## 18. Runtime Safety
|
|
|
|
### 18.1 Question
|
|
|
|
If the artifact runs tools, files, code, or workflows, is it safe?
|
|
|
|
### 18.2 Good Signs
|
|
|
|
```text id="xeh0dt"
|
|
Tool scope is explicit.
|
|
Allowed and forbidden actions are defined.
|
|
Risky actions require confirmation.
|
|
Validation and rollback exist.
|
|
Errors are handled.
|
|
```
|
|
|
|
### 18.3 Bad Signs
|
|
|
|
```text id="87koby"
|
|
Agent can write files without permission.
|
|
No validation after tool use.
|
|
No rollback strategy.
|
|
No distinction between draft and canonical files.
|
|
```
|
|
|
|
### 18.4 Common Fixes
|
|
|
|
```text id="6x87kn"
|
|
Add Runtime Layer.
|
|
Add Authority Layer.
|
|
Add Recovery Rules.
|
|
Add Draft-first Policy.
|
|
Add Validation Rules.
|
|
```
|
|
|
|
## 19. Portability
|
|
|
|
### 19.1 Question
|
|
|
|
Can the artifact be used in the intended platform?
|
|
|
|
### 19.2 Good Signs
|
|
|
|
```text id="673x3l"
|
|
Lite prompts are copy-paste friendly.
|
|
Agent Specs can be adapted to Codex / Claude Code / OpenClaw.
|
|
Skills use clear references and templates.
|
|
Runtime does not assume unsupported features.
|
|
```
|
|
|
|
### 19.3 Bad Signs
|
|
|
|
```text id="m3hohu"
|
|
Prompt assumes unavailable tools.
|
|
Skill format does not match platform.
|
|
Agent relies on hidden context.
|
|
Runtime depends on unspecified environment.
|
|
```
|
|
|
|
### 19.4 Common Fixes
|
|
|
|
```text id="0gxhuj"
|
|
Add Platform Target.
|
|
Add Deployment Notes.
|
|
Separate platform-neutral spec from platform-specific implementation.
|
|
Keep portable Lite version where useful.
|
|
```
|
|
|
|
## 20. Maintainability
|
|
|
|
### 20.1 Question
|
|
|
|
Can the artifact be updated without breaking everything?
|
|
|
|
### 20.2 Good Signs
|
|
|
|
```text id="p2kb47"
|
|
Version metadata exists.
|
|
Dependencies are listed.
|
|
Model and Skill references are separate.
|
|
Change log or status exists.
|
|
Canonical location is clear.
|
|
```
|
|
|
|
### 20.3 Bad Signs
|
|
|
|
```text id="h7d5df"
|
|
One giant prompt contains everything.
|
|
Same model copied into many agents.
|
|
No status or version.
|
|
No index entry.
|
|
```
|
|
|
|
### 20.4 Common Fixes
|
|
|
|
```text id="2iaam8"
|
|
Extract Model Card.
|
|
Extract Skill.
|
|
Add Knowledge Asset Layer.
|
|
Add Version Metadata.
|
|
Update Model Index.
|
|
```
|
|
|
|
## 21. Intellectual Flavor Preservation
|
|
|
|
### 21.1 Question
|
|
|
|
Does the refactored artifact preserve the user's original thinking?
|
|
|
|
### 21.2 Good Signs
|
|
|
|
```text id="wskdkg"
|
|
Core metaphor remains meaningful.
|
|
Distinctive terminology is preserved.
|
|
The model's tension and sharpness remain.
|
|
The artifact does not become generic.
|
|
Original cognitive stance is visible.
|
|
```
|
|
|
|
### 21.3 Bad Signs
|
|
|
|
```text id="kf0d9x"
|
|
Unique model becomes generic consulting advice.
|
|
Sharp critique becomes bland summary.
|
|
Metaphor is removed even though it carried mechanism.
|
|
Conceptual edge is softened unnecessarily.
|
|
```
|
|
|
|
### 21.4 Common Fixes
|
|
|
|
```text id="5tafww"
|
|
Restore key terms.
|
|
Restore metaphor where structurally meaningful.
|
|
Add Model Fidelity note.
|
|
Compare refactor against original.
|
|
Ask user to approve major conceptual compression.
|
|
```
|
|
|
|
## 22. Artifact-Specific Rubric
|
|
|
|
### 22.1 CCPE-Lite
|
|
|
|
Prioritize:
|
|
|
|
```text id="fflqrv"
|
|
Purpose Fit
|
|
Role Clarity
|
|
Portability
|
|
Output Usability
|
|
Boundary Precision
|
|
Model Fidelity if model-backed
|
|
```
|
|
|
|
Avoid overloading with:
|
|
|
|
```text id="ernkw8"
|
|
Heavy Runtime
|
|
Long authority systems
|
|
Complex state
|
|
Too many sections
|
|
```
|
|
|
|
### 22.2 CCPE-Agent
|
|
|
|
Prioritize:
|
|
|
|
```text id="hsk5xb"
|
|
Objective
|
|
Role
|
|
Input / Output Contract
|
|
Capability
|
|
Authority
|
|
Workflow
|
|
Evaluation
|
|
Collaboration
|
|
Maintainability
|
|
```
|
|
|
|
### 22.3 CCPE-Skill
|
|
|
|
Prioritize:
|
|
|
|
```text id="szb655"
|
|
Trigger Conditions
|
|
Input / Output
|
|
Procedure
|
|
Reusability
|
|
Validation
|
|
Failure Handling
|
|
Tool Rules if applicable
|
|
```
|
|
|
|
### 22.4 CCPE-Runtime
|
|
|
|
Prioritize:
|
|
|
|
```text id="67i4lr"
|
|
Stages
|
|
Participants
|
|
Handoff
|
|
State
|
|
Human Decision Gates
|
|
Authority
|
|
Validation
|
|
Recovery
|
|
Archival
|
|
```
|
|
|
|
### 22.5 Model Card
|
|
|
|
Prioritize:
|
|
|
|
```text id="08ff7q"
|
|
Model Fidelity
|
|
Scope
|
|
Core Assumptions
|
|
Mechanism
|
|
Procedure
|
|
Failure Modes
|
|
Falsification Boundary
|
|
Related Models
|
|
Source Traceability
|
|
```
|
|
|
|
### 22.6 Model Index
|
|
|
|
Prioritize:
|
|
|
|
```text id="9xho1e"
|
|
Taxonomy
|
|
Hierarchy
|
|
Dependencies
|
|
Usage Mapping
|
|
Version Status
|
|
Source Tracking
|
|
Review Status
|
|
```
|
|
|
|
## 23. Quality Report Format
|
|
|
|
Use this format when evaluating an artifact:
|
|
|
|
```text id="qx96zs"
|
|
# CCPE Quality Report
|
|
|
|
## 1. Artifact
|
|
Name:
|
|
Path:
|
|
Type:
|
|
|
|
## 2. Classification
|
|
Primary:
|
|
Secondary:
|
|
Hybrid Components:
|
|
|
|
## 3. Score Summary
|
|
| Criterion | Score | Severity | Notes |
|
|
|---|---:|---|---|
|
|
| Purpose Fit | | | |
|
|
| Scenario Fit | | | |
|
|
| Classification Accuracy | | | |
|
|
| Structural Clarity | | | |
|
|
| Boundary Precision | | | |
|
|
| Capability Realism | | | |
|
|
| Context Handling | | | |
|
|
| Model Fidelity | | | |
|
|
| Lite Kernel Fidelity | | | |
|
|
| Concept Function Discipline | | | |
|
|
| Reconstruction Discipline | | | |
|
|
| Skill Reusability | | | |
|
|
| Authority Clarity | | | |
|
|
| Workflow Coherence | | | |
|
|
| State Awareness | | | |
|
|
| Output Usability | | | |
|
|
| Output Structure Discipline | | | |
|
|
| Evaluation Strength | | | |
|
|
| Human-in-the-Loop Design | | | |
|
|
| Runtime Safety | | | |
|
|
| Portability | | | |
|
|
| Maintainability | | | |
|
|
| Intellectual Flavor Preservation | | | |
|
|
|
|
## 4. Major Findings
|
|
...
|
|
|
|
## 5. Required Fixes
|
|
...
|
|
|
|
## 6. Recommended Improvements
|
|
...
|
|
|
|
## 7. Refactor Direction
|
|
...
|
|
|
|
## 8. Human Decisions Needed
|
|
...
|
|
```
|
|
|
|
## 24. Final Rule
|
|
|
|
A high-quality CCPE artifact is not the longest artifact.
|
|
|
|
It is the artifact that has the right structure for its job.
|
|
|
|
Evaluate quality by fitness, clarity, fidelity, safety, and reuse.
|