wantsong
/
Cognitive-OS-Wantsong
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Compare commits

base: wantsong:main
Branches Tags
wantsong:main
wantsong:v0.1.0-m0-m1
..
compare: wantsong:v0.1.0-m0-m1
Branches Tags
wantsong:main
wantsong:v0.1.0-m0-m1

No commits in common. "main" and "v0.1.0-m0-m1" have entirely different histories.
main ... v0.1.0-m0-

7 changed files with 9 additions and 547 deletions
Show Stats Expand all files Collapse all files

24
PROJECTS.md
View File

@ -2,9 +2,9 @@
## Active Phase ## Active Phase
Current phase: M2a boundary correction. Current phase: M0-M1 startup.
The active deliverable is the authority boundary for M2 prompt/runtime work. The repository should not create canonical prompts, canonical runtime specs, or Local CCRA review artifacts during M2a. The active deliverable is a small file-first foundation for a cognitive-processing runtime. The repository should stay closer to runtime setup than governance evidence.
## Source Of Truth ## Source Of Truth
@ -22,24 +22,18 @@ The old project is not an upstream branch and not a source tree to merge.
1. M0: project boundary freeze. 1. M0: project boundary freeze.
2. M1: model-management kernel. 2. M1: model-management kernel.
3. M2a: prompt authority boundary and supplier requests. 3. M2: prompt/runtime skeleton.
4. M2b: product-local runtime adapters and one minimal manual sample. 4. M3: reader translation prompt and before/after translation check.
5. M3: reader translation refinement and before/after translation check. 5. M4: first real sample run.
6. M4: first full real sample run. 6. M5: first Local CCRA milestone review.
7. M5: first Local CCRA milestone review.
Do not skip from M2a into canonical prompt creation. If `prompts/` is created during M2b, files must be product-local draft adapters with explicit non-canonical frontmatter. Do not skip from M1 into sample execution without an explicit owner instruction.
## Supplier Boundaries ## Supplier Boundaries
This repository records supplier requests under: This repository may record requests for external reusable tooling later, but M0-M1 should not create a supplier-request channel unless a real missing tool blocks progress.
- `requirements/ccpe/` for canonical Prompt Cards, Agent Specs, Runtime Specs, model-call protocols, evaluation rubrics, and Local CCRA review protocol. Reusable policy, reviewers, and broader CCRA method should stay outside this product repo unless the owner explicitly asks to localize a milestone protocol.
- `requirements/skills-vault/` for deterministic reusable automation such as adapter validators, run loggers, manifest checkers, and review context builders.
Reusable policy, reviewers, prompt authority, and broader CCRA method stay outside this product repo unless the owner explicitly asks to localize a product-only adapter.
Do not copy canonical CCPE artifacts into this repository. Do not implement reusable automation locally when the correct action is a supplier request.
## Naming ## Naming

43
docs/DECISIONS.md
View File

@ -62,46 +62,3 @@ Reason: the system needs model identity and call boundaries before it needs auto
Decision: reader translation is a first-class product layer, even though its prompt is not created in M0-M1. Decision: reader translation is a first-class product layer, even though its prompt is not created in M0-M1.
Reason: internal model output is not automatically understandable or usable by frontend readers. Reason: internal model output is not automatically understandable or usable by frontend readers.
## D011: M2 Prompt Authority Boundary
Decision: M2 must not directly implement GPT-authored prompt plans as canonical prompts in this repository.
Reason: canonical Prompt Cards, Agent Specs, Runtime Specs, model-call protocols, evaluation rubrics, and Local CCRA review protocol belong in `ccpe-system`.
## D012: Product-Local Adapter Scope
Decision: this repository may later hold only product-local draft adapters, sample runs, product workflow glue, and output formats.
Reason: product-local adapters are implementation-facing runtime surfaces, not canonical CCPE prompt authority.
## D013: Mandatory Adapter Frontmatter
Decision: if `prompts/` is created before CCPE supplies canonical contracts, every prompt-like file must declare:
```yaml
authority: product_local_adapter
status: draft
canonical_source: pending_ccpe
not_canonical_ccpe_prompt: true
```
Reason: future sessions must not confuse product-local adapters with canonical CCPE artifacts.
## D014: CCPE Request Channel For M2 Contracts
Decision: M2 canonical prompt/spec/rubric/protocol needs are recorded under `requirements/ccpe/`.
Reason: missing CCPE-owned authority should become a supplier request, not an ad hoc local implementation.
## D015: Skills-Vault Request Channel For Deterministic Tools
Decision: deterministic M2 tooling needs are recorded under `requirements/skills-vault/`.
Reason: reusable automation such as adapter metadata validation, run logging, and manifest checking belongs in `skills-vault`, not in this product repository.
## D016: Local CCRA Waits Until After A Minimal Manual Sample
Decision: Local CCRA must not start during M2 boundary correction.
Reason: Local CCRA should review milestone output after boundary correction and one minimal manual sample, not review the boundary correction itself as a new round.

124
docs/PROMPT_AUTHORITY_BOUNDARY.md
View File

@ -1,124 +0,0 @@
# Prompt Authority Boundary
status: draft_m2_boundary_correction
date: 2026-06-20
## Purpose
M2 must not directly implement the GPT-authored prompt plan as canonical prompts in this repository.
The M2 correction is to separate product-local runtime work from CCPE-owned canonical prompt and runtime authority.
## Authority Split
| Surface | Owner | This repository may store | This repository must not store |
| --- | --- | --- | --- |
| Product runtime | `Cognitive-OS-Wantsong` | product-local adapters, manual run records, sample inputs/outputs, product workflow notes, product output formats | canonical CCPE prompt cards, Agent Specs, Runtime Specs, CCRA reviewer specs |
| Canonical prompt/runtime authority | `ccpe-system` | supplier requests under `requirements/ccpe/` | copied canonical artifacts treated as local truth |
| Deterministic automation | `skills-vault` | supplier requests under `requirements/skills-vault/` | reusable Skill source, generic validators, reusable CLIs |
## Product Repository Scope
This repository owns:
- product-specific runtime adapters;
- sample run inputs and outputs;
- manual run records;
- product-specific workflow glue;
- local output formats for internal trace and reader-facing explanation;
- product-side requests to CCPE and skills-vault.
This repository does not own:
- canonical Prompt Cards;
- Agent Specs;
- Runtime Specs;
- model-call protocols;
- evaluation rubrics;
- Local CCRA canonical review protocol;
- reusable deterministic automation tools.
## M2 Prompt Rule
Do not create canonical prompt files in this repository.
If `prompts/` must be created later, every file must be a product-local draft adapter and include this frontmatter:
```yaml
---
authority: product_local_adapter
status: draft
canonical_source: pending_ccpe
not_canonical_ccpe_prompt: true
---
```
Adapter files may reference pending CCPE contracts but cannot claim canonical status.
## Routing Rule
When M2 needs canonical prompt/spec/rubric/protocol authority, write a CCPE request under:
```text
requirements/ccpe/
```
When M2 needs reusable deterministic automation, write a skills-vault request under:
```text
requirements/skills-vault/
```
Do not solve supplier-owned capabilities locally unless the owner explicitly changes the boundary.
## Forbidden During M2a
M2a must not:
- create canonical prompts;
- create `ccra_review_bundle/`;
- start Local CCRA;
- import old prompt packs from the previous project;
- implement a full selector;
- implement reusable validators locally;
- expand the model set.
## Revised M2a Plan
Goal: correct M2 authority boundaries before any prompt/runtime skeleton work.
Deliverables:
- `docs/PROMPT_AUTHORITY_BOUNDARY.md`;
- M2 boundary decisions in `docs/DECISIONS.md`;
- CCPE request for cognitive runtime prompt contracts;
- skills-vault request for deterministic adapter/run manifest tooling if needed;
- request-channel READMEs.
Acceptance:
- no `prompts/` directory is required;
- no canonical CCPE artifact is copied into this repository;
- any missing canonical prompt/spec is represented as a supplier request;
- any reusable deterministic tool is represented as a supplier request.
## Revised M2b Plan
Goal: create only product-local runtime material after M2a boundaries are accepted.
Allowed M2b work:
1. Create product-local draft adapters only if the owner confirms adapter work should start before CCPE supplies canonical Prompt Cards.
2. Use the mandatory adapter frontmatter from this document.
3. Define product-local run input/output shapes for:
- intake/value assessment;
- QPI;
- lens orchestration;
- Intellectual Archaeology;
- synthesis/calibration;
- reader translation;
- feedback/asset decision.
4. Run one minimal manual sample only after adapters and run format are clearly product-local.
5. Record the run as product evidence, not as review evidence.
M2b must still not start Local CCRA. Local CCRA waits until boundary correction and one minimal manual sample are complete.

156
requirements/ccpe/2026-06-20-m2-cognitive-runtime-prompt-contracts.md
View File

@ -1,156 +0,0 @@
# CCPE Request: M2 Cognitive Runtime Prompt Contracts
Date: 2026-06-20
Client repository:
```text
C:\Users\wangq\Documents\Codex\work-projects\Cognitive-OS-Wantsong
```
Requested supplier repository:
```text
C:\Users\wangq\Documents\Codex\ccpe-system
```
## 1. Product Context
`Cognitive-OS-Wantsong` is a new product-runtime repository for a lightweight cognitive-processing flow.
The product repo currently owns M0-M1 boundary docs, QPI and Intellectual Archaeology model cards, and the model registry.
The next planned phase is M2, but the GPT-authored M2 plan proposed prompt files without separating:
- product-local runtime adapters;
- canonical Prompt Cards;
- Agent Specs;
- Runtime Specs;
- model-call protocols;
- evaluation rubrics;
- Local CCRA review protocol.
This request asks CCPE to own the canonical contract layer before the product repo creates any canonical-looking prompt assets.
## 2. Needed Capability
CCPE should define the canonical prompt/runtime contract set for the Cognitive-OS M2 runtime.
Needed canonical artifacts:
1. Prompt Card contract for Intake / Value Assessment.
2. Prompt Card contract for QPI routing.
3. Prompt Card contract for Lens Orchestration.
4. Prompt Card contract for Intellectual Archaeology runner.
5. Prompt Card contract for Synthesis and Calibration.
6. Prompt Card contract for Reader Translation.
7. Prompt Card contract for Feedback and Asset Decision.
8. Runtime Spec for chaining these cards in a manual or semi-automated run.
9. Model-call protocol describing how product-local adapters may invoke or reference canonical prompt contracts.
10. Evaluation rubric for judging internal trace and reader-facing output quality.
11. Boundary rule for when Local CCRA can review the milestone.
## 3. Why This Belongs In CCPE
This work defines canonical prompt authority, runtime protocol, evaluation rubric, and review criteria.
Those are CCPE responsibilities. The product repo should only hold product-local adapters, sample runs, local output formats, and supplier requests.
## 4. Current Blocked Task
The product repo should not create canonical prompt files for M2 until the CCPE contract exists.
Allowed interim product work:
- document prompt authority boundaries;
- create product-local draft adapters only with explicit adapter frontmatter;
- run a minimal manual sample only after adapter status is unambiguous.
Blocked canonical work:
```text
prompts/intake-value-assessor.md
prompts/qpi-router.md
prompts/lens-orchestrator.md
prompts/intellectual-archaeology-runner.md
prompts/synthesis-engine.md
prompts/reader-translation-engine.md
prompts/calibration-checker.md
```
These filenames may exist later only as product-local adapters unless CCPE explicitly supplies canonical placement rules.
## 5. Input Files And Source Paths
Product repo files:
```text
README.md
AGENTS.md
PROJECTS.md
docs/PROJECT_BRIEF.md
docs/COGNITIVE_WORKFLOW_V0.md
docs/MODEL_MANAGEMENT_V0.md
docs/MODEL_ORCHESTRATION_V0.md
docs/READER_TRANSLATION_LAYER_V0.md
docs/LOCAL_CCRA_MILESTONE_PROTOCOL.md
docs/ASSET_MIGRATION_POLICY.md
docs/DECISIONS.md
models/qpi.md
models/intellectual-archaeology.md
models/model-registry.json
```
Planning/source references:
```text
C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\Cognitive-OS-Wantsong项目总计划 v0.1.md
C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\PROJECTS.md
C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\requirements\
```
## 6. Expected Output Artifacts
CCPE should provide or register:
- canonical Prompt Card templates or concrete cards for the seven M2 runtime steps;
- a Runtime Spec for manual chaining and later automation;
- model-call protocol covering model registry lookup, primary/support role limits, and reader translation handoff;
- evaluation rubric for:
- QPI routing quality;
- Intellectual Archaeology depth quality;
- synthesis/calibration quality;
- reader translation quality;
- evidence/action-boundary quality;
- Local CCRA milestone-readiness criteria for after the first minimal manual sample.
## 7. Required Human Gate
Owner approval is required before:
- treating any product-local adapter as canonical;
- copying any CCPE-supplied artifact into this product repo;
- starting Local CCRA;
- expanding beyond QPI and Intellectual Archaeology;
- turning M2 output into stable model governance.
## 8. Prohibited Behavior
CCPE output should not require this product repo to:
- store canonical Prompt Cards as local truth;
- create a full selector;
- create a full regression suite;
- start Local CCRA before a minimal manual sample;
- recreate old review-bundle or Round Conductor workflows;
- use `lite` suffixes for model filenames or model IDs.
## 9. Urgency And Dependency
Urgency: high before M2 prompt work.
Dependency:
- M2a boundary correction can complete immediately in this product repo.
- M2b product-local adapter work can proceed only if adapter authority is clearly marked.
- Canonical prompt/runtime authority waits for CCPE.

45
requirements/ccpe/README.md
View File

@ -1,45 +0,0 @@
# CCPE Capability Requests
This directory holds supplier requests for capabilities that should be designed or maintained in:
```text
C:\Users\wangq\Documents\Codex\ccpe-system
```
Use this channel when `Cognitive-OS-Wantsong` needs:
- canonical Prompt Card;
- Agent Spec;
- Runtime Spec;
- model-call protocol;
- evaluation rubric;
- Local CCRA canonical review protocol;
- lifecycle or milestone authority rule;
- integration registration guidance.
Do not place canonical CCPE artifacts in this repository. Store the client request here, then let `ccpe-system` own the supplied artifact.
## Request Format
Use one Markdown file per request.
Recommended filename:
```text
YYYY-MM-DD-short-request-name.md
```
Each request should include:
- product context;
- needed capability;
- why this belongs in CCPE;
- current blocked task;
- input files or source paths;
- expected output artifact;
- required human gate;
- urgency and dependency.
## Pause Rule
If product work depends on a missing CCPE capability, write the request here and pause the dependent step unless the owner explicitly says to solve it inside this repository.

121
requirements/skills-vault/2026-06-20-m2-runtime-run-logger-and-adapter-manifest-checker.md
View File

@ -1,121 +0,0 @@
# Skills-Vault Request: M2 Runtime Run Logger And Adapter Manifest Checker
Date: 2026-06-20
Client repository:
```text
C:\Users\wangq\Documents\Codex\work-projects\Cognitive-OS-Wantsong
```
Requested supplier repository:
```text
C:\Users\wangq\Documents\Codex\skills-vault
```
## 1. Product Context
`Cognitive-OS-Wantsong` will enter M2 after boundary correction.
M2 should create product-local runtime adapters and eventually run one minimal manual sample. It must not create canonical CCPE prompt artifacts.
This creates a deterministic validation need: adapter files and run records should be checked for authority metadata, manifest completeness, and path consistency without judging model quality.
## 2. Repeated Action Or Friction Point
Likely repeated checks:
- product-local adapter frontmatter includes the required authority fields;
- no adapter claims canonical CCPE prompt status;
- run manifest lists all runtime steps and output files;
- run log paths exist;
- sample input, internal trace, reader output, and owner note are cross-linked consistently;
- Local CCRA is not started before the required milestone conditions.
These checks are deterministic. They should not become product repo scripts unless the owner explicitly asks.
## 3. Proposed Skill Name
Candidate name:
```text
cognitive-runtime-manifest-checker
```
Alternative names:
```text
prompt-adapter-boundary-checker
runtime-run-log-validator
```
## 4. Inputs
The Skill should accept:
- repository root;
- optional adapter directory path;
- optional run directory path;
- expected authority policy.
Expected adapter frontmatter policy:
```yaml
authority: product_local_adapter
status: draft
canonical_source: pending_ccpe
not_canonical_ccpe_prompt: true
```
## 5. Expected Outputs
The Skill should produce:
- a PASS / FAIL summary;
- a machine-readable JSON report;
- finding list with file paths and line numbers when possible.
Suggested report fields:
```json
{
"status": "PASS",
"adapter_files_scanned": 0,
"run_files_scanned": 0,
"blocking_findings": [],
"warnings": []
}
```
## 6. Safety Boundaries
- Read-only by default.
- No content generation.
- No prompt rewriting.
- No model-quality judgment.
- No Local CCRA judgment.
- No file edits unless a future explicit `--write-report` option is requested.
## 7. Validation Expectation
Minimum validation cases:
- adapter with correct frontmatter passes;
- adapter missing `not_canonical_ccpe_prompt: true` fails;
- adapter claiming `authority: ccpe_canonical` fails inside the product repo;
- missing run output path fails;
- Local CCRA directory present before the allowed milestone warns or fails according to config;
- JSON report is stable and machine-readable.
## 8. Why This Should Become Reusable Automation
The operation is deterministic metadata and manifest checking. It does not depend on QPI content quality or Intellectual Archaeology reasoning.
It is likely reusable for other product repos that consume CCPE canonical prompt contracts while keeping product-local adapters separate.
## 9. Current Blocked Task
This is not blocking M2a boundary correction.
It may become useful before M2b manual sample execution, especially if multiple adapter and run files are created.

43
requirements/skills-vault/README.md
View File

@ -1,43 +0,0 @@
# Skills-Vault Capability Requests
This directory holds supplier requests for deterministic automation that should be implemented or maintained in:
```text
C:\Users\wangq\Documents\Codex\skills-vault
```
Use this channel when `Cognitive-OS-Wantsong` needs:
- prompt adapter validator;
- run logger;
- manifest checker;
- review context builder;
- deterministic file transformer;
- reusable CLI or installable Skill.
Do not place reusable automation Skill source in this repository. Store the client request here, then let `skills-vault` own implementation source if the need becomes stable and reusable.
## Request Format
Use one Markdown file per request.
Recommended filename:
```text
YYYY-MM-DD-short-request-name.md
```
Each request should include:
- product context;
- repeated action or friction point;
- input files and expected outputs;
- safety boundaries;
- whether file edits are allowed;
- validation expectation;
- why this should become reusable automation;
- current blocked task.
## Pause Rule
If product work depends on a missing reusable automation capability, write the request here and pause the dependent step unless the owner explicitly says to solve it inside this repository.