ccpe-system/PROJECTS.md

Project Relationships

This file is the local project map for CCPE System. It exists so future sessions understand what this repository supplies, what it consumes, and which neighboring repository owns each kind of asset.

Local Identity

ccpe-system is the AI artifact architecture forge and supplier workspace.

It designs, audits, refactors, registers, and maintains:

• CCPE-Lite prompt cards
• Agent Specs
• Committee Specs
• CCPE-Skill Specs
• Runtime Specs
• Model Cards
• Model Index entries
• invocation protocols
• evaluation rubrics
• external capability registrations

It does not own concrete project execution records, deterministic automation source code, or deployed production application runtime.

Neighboring Projects

Project	Relationship To CCPE System	CCPE Consumes	CCPE Produces
knowledge-vault	Upstream knowledge, source archive, discussion memory, and human-readable rule layer	prompt archives, model source discussions, articles, viewpoint-development requirements, feedback from knowledge workflows	canonical AI asset specs, model cards, invocation protocols, runtime specs when reusable
writing-workbench	Client project workspace for article work after an initial outline exists	capability requests under requirements/ccpe/, concrete writing workflow needs, feedback from real use	lead writer agents, reviewer agents, invocation contracts, context-preparation rules, review and repair protocols
video-workbench	Future client workspace for dimensional output and multimodal production	capability requests when the project becomes active	runtime specs, agent specs, model usage rules, and integration registrations for video production support
skills-vault	Supplier of deterministic automation Skill source	automation skill metadata, installed capability paths, validation and safety notes	integration registrations and dependency contracts only when CCPE artifacts depend on those tools
work-projects	Concrete software/customer/experimental development workspace	production or business agent requirements, framework constraints, deployment needs	agent specs, capability contracts, evaluation rubrics, and governance notes for implementation in the target project
work-projects/the-mindscape-of-bro-tsong	Client product and engineered cognitive model governance system	CCPE requirements, review bundle needs, model-governance workflow requirements, feedback from Local CCRA pilots	Local CCRA Agent/Runtime specs, evaluation rules, invocation contracts, and outbound skills-vault request documents

Boundary Rules

• CCPE supplies reusable AI architecture assets; project repositories run concrete projects.
• Project-specific runbooks, process records, returned participant outputs, drafts, decision logs, and publication metadata stay in the project repository.
• Deterministic automation implementation source belongs in skills-vault.
• Production/business agent implementation belongs in the target development project, especially when constrained by LangGraph, CrewAI, server deployment, persistence, or monitoring.
• CCPE may register external capabilities, but it does not copy their implementation source.
• Missing capabilities should be expressed as project requirements first, then classified by CCPE.
• Outbound automation requests from CCPE should be recorded under requirements/skills-vault/ before implementation happens in skills-vault.
• the-mindscape-of-bro-tsong owns its future engineered model cards, model indexes, review runs, and lifecycle decisions. CCPE may supply templates, example assets, Agent/Runtime contracts, and evaluation rules, but should not treat its own model-cards/ and model-index/ as that product's future canonical governance store.

Practical Rule

CCPE is a supplier and architecture forge:

knowledge-vault provides sources, discussions, and long-term memory.
writing-workbench and video-workbench provide concrete workflow requirements.
skills-vault provides deterministic automation tools.
work-projects implements deployed systems.
ccpe-system supplies agents, protocols, model assets, runtime specs, and registrations.

Status Rule

Asset status should be expressed by metadata, reports, or indexes:

active / maintained / reference / superseded / deprecated / archived

Do not infer status from whether an artifact lives in a historical-looking folder. Some older assets remain active references until a concrete replacement is confirmed.