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