chore: initialize model library mvp
This commit is contained in:
commit
524ed68dbd
|
|
@ -0,0 +1,256 @@
|
||||||
|
# AGENTS.md
|
||||||
|
|
||||||
|
## 1. Role
|
||||||
|
|
||||||
|
You are Codex working inside the `the-mindscape-of-bro-tsong` repository.
|
||||||
|
|
||||||
|
Your role is to implement the engineering structure for a file-first cognitive model library MVP.
|
||||||
|
|
||||||
|
You are not responsible for product strategy, marketing, sales, UI design, or broad feature invention.
|
||||||
|
|
||||||
|
Product planning decisions come from the project owner and CCRA / ChatGPT-side architecture work.
|
||||||
|
|
||||||
|
## 2. Project Goal
|
||||||
|
|
||||||
|
Build a minimal, file-first model library system that can represent cognitive models as:
|
||||||
|
|
||||||
|
- Human-readable Markdown model cards
|
||||||
|
- Machine-readable JSON model specs
|
||||||
|
- Source article records
|
||||||
|
- Source evidence excerpts
|
||||||
|
- Regression test cases
|
||||||
|
- Minimal model selector examples
|
||||||
|
|
||||||
|
The current phase is `model_library_mvp`.
|
||||||
|
|
||||||
|
The first sample models are:
|
||||||
|
|
||||||
|
- QPI
|
||||||
|
- Intellectual Archaeology
|
||||||
|
|
||||||
|
## 3. Core Principle
|
||||||
|
|
||||||
|
Do not overbuild.
|
||||||
|
|
||||||
|
The goal is not to create a full platform.
|
||||||
|
|
||||||
|
The goal is to create a stable model asset foundation.
|
||||||
|
|
||||||
|
Prefer:
|
||||||
|
|
||||||
|
- JSON over database
|
||||||
|
- Markdown over UI
|
||||||
|
- Explicit schema over hidden convention
|
||||||
|
- Simple scripts over complex services
|
||||||
|
- Traceability over automation
|
||||||
|
- Validation over feature expansion
|
||||||
|
|
||||||
|
## 4. Non-Goals
|
||||||
|
|
||||||
|
Do not implement:
|
||||||
|
|
||||||
|
- Full frontend application
|
||||||
|
- Backend service
|
||||||
|
- Database
|
||||||
|
- Vector database
|
||||||
|
- Full RAG system
|
||||||
|
- User accounts
|
||||||
|
- Authentication
|
||||||
|
- Payment
|
||||||
|
- Public platform
|
||||||
|
- Multi-user collaboration
|
||||||
|
- Complete knowledge graph
|
||||||
|
- Automatic extraction from all articles
|
||||||
|
- Full question-answering system
|
||||||
|
|
||||||
|
If a task seems to require one of these, stop and ask for product confirmation.
|
||||||
|
|
||||||
|
## 5. Repository Layout
|
||||||
|
|
||||||
|
Expected layout:
|
||||||
|
|
||||||
|
```text
|
||||||
|
docs/
|
||||||
|
schemas/
|
||||||
|
models/
|
||||||
|
cards/
|
||||||
|
sources/
|
||||||
|
tests/
|
||||||
|
selector/
|
||||||
|
scripts/
|
||||||
|
reports/
|
||||||
|
```
|
||||||
|
|
||||||
|
Each folder should contain a README explaining its purpose.
|
||||||
|
|
||||||
|
Do not create a nested `model_library_mvp/` directory unless the project owner explicitly changes the repository strategy.
|
||||||
|
|
||||||
|
## 6. Data Rules
|
||||||
|
|
||||||
|
Machine-readable files should use JSON.
|
||||||
|
|
||||||
|
Human-readable model cards and documentation should use Markdown.
|
||||||
|
|
||||||
|
Every model must eventually have:
|
||||||
|
|
||||||
|
- `model_id`
|
||||||
|
- `model_name`
|
||||||
|
- `model_type`
|
||||||
|
- `pipeline_position`
|
||||||
|
- `one_sentence_definition`
|
||||||
|
- `core_question`
|
||||||
|
- `core_mechanism`
|
||||||
|
- `source_articles`
|
||||||
|
- `source_evidence`
|
||||||
|
- `input_types`
|
||||||
|
- `output_types`
|
||||||
|
- `call_when`
|
||||||
|
- `do_not_call_when`
|
||||||
|
- `common_misuses`
|
||||||
|
- `failure_modes`
|
||||||
|
- `selection_priority`
|
||||||
|
- `confidence_level`
|
||||||
|
- `stability_profile`
|
||||||
|
- `regression_status`
|
||||||
|
- `productization_notes`
|
||||||
|
|
||||||
|
## 7. Source Traceability Rules
|
||||||
|
|
||||||
|
Every model should reference source article IDs.
|
||||||
|
|
||||||
|
Every model should reference source evidence excerpt IDs.
|
||||||
|
|
||||||
|
Do not invent source IDs without adding matching records in `sources/source_articles.json` or `sources/source_excerpts.json`.
|
||||||
|
|
||||||
|
If source content is not yet available, use placeholder records with clear notes such as:
|
||||||
|
|
||||||
|
```text
|
||||||
|
raw_excerpt: "待填入原文片段"
|
||||||
|
```
|
||||||
|
|
||||||
|
Do not pretend placeholder excerpts are verified evidence.
|
||||||
|
|
||||||
|
## 8. Regression Test Rules
|
||||||
|
|
||||||
|
Every core model should have at least five regression cases:
|
||||||
|
|
||||||
|
- Positive cases
|
||||||
|
- Boundary cases
|
||||||
|
- Misuse cases
|
||||||
|
|
||||||
|
Regression tests should check whether the model is being used appropriately.
|
||||||
|
|
||||||
|
They are not unit tests for code only. They are also product tests for cognitive model stability.
|
||||||
|
|
||||||
|
## 9. Selector Rules
|
||||||
|
|
||||||
|
The minimal selector should not call an LLM in v0.1.
|
||||||
|
|
||||||
|
It should use simple matching rules:
|
||||||
|
|
||||||
|
- Trigger keywords
|
||||||
|
- Input types
|
||||||
|
- Negative triggers
|
||||||
|
- Pipeline position
|
||||||
|
- Selection priority
|
||||||
|
|
||||||
|
The selector should output:
|
||||||
|
|
||||||
|
- Recommended model IDs
|
||||||
|
- Scores
|
||||||
|
- Reasons
|
||||||
|
- Routing notes
|
||||||
|
|
||||||
|
## 10. Coding Style
|
||||||
|
|
||||||
|
Keep scripts simple and readable.
|
||||||
|
|
||||||
|
Use Python only if scripts are needed.
|
||||||
|
|
||||||
|
Avoid unnecessary dependencies.
|
||||||
|
|
||||||
|
If using Python, prefer the standard library first.
|
||||||
|
|
||||||
|
If a dependency is necessary, document it in README.
|
||||||
|
|
||||||
|
## 11. Validation Expectations
|
||||||
|
|
||||||
|
Validation should eventually check:
|
||||||
|
|
||||||
|
- JSON schema compliance
|
||||||
|
- Unique model IDs
|
||||||
|
- Valid source article references
|
||||||
|
- Valid evidence excerpt references
|
||||||
|
- Valid regression test model references
|
||||||
|
- Required fields
|
||||||
|
- Enum values
|
||||||
|
|
||||||
|
Validation output should be written to:
|
||||||
|
|
||||||
|
```text
|
||||||
|
reports/validation_report.md
|
||||||
|
```
|
||||||
|
|
||||||
|
## 12. Documentation Expectations
|
||||||
|
|
||||||
|
When adding or changing structure, update relevant documentation.
|
||||||
|
|
||||||
|
At minimum, keep these files consistent:
|
||||||
|
|
||||||
|
- `README.md`
|
||||||
|
- `AGENTS.md`
|
||||||
|
- `docs/PROJECT_BRIEF.md`
|
||||||
|
- `docs/DATA_CONTRACT.md`
|
||||||
|
- `docs/WORKFLOW.md`
|
||||||
|
- `docs/DECISIONS.md`
|
||||||
|
|
||||||
|
## 13. Decision Logging
|
||||||
|
|
||||||
|
Any structural decision should be recorded in:
|
||||||
|
|
||||||
|
```text
|
||||||
|
docs/DECISIONS.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
|
||||||
|
- Why JSON is used instead of YAML
|
||||||
|
- Why no database is used in v0.1
|
||||||
|
- Why QPI and Intellectual Archaeology are the first sample models
|
||||||
|
- Why selector is rule-based in v0.1
|
||||||
|
- Why `model_library_mvp` is a phase name rather than a nested repository root
|
||||||
|
|
||||||
|
## 14. Definition of Done
|
||||||
|
|
||||||
|
A task is done only when:
|
||||||
|
|
||||||
|
- Files are created in the expected location
|
||||||
|
- README or folder README is updated
|
||||||
|
- JSON files are valid or clearly marked as draft
|
||||||
|
- References between files are consistent
|
||||||
|
- Validation status is documented
|
||||||
|
- Non-goals have not been violated
|
||||||
|
- Any open questions are listed in the handoff document
|
||||||
|
|
||||||
|
## 15. Handoff Requirement
|
||||||
|
|
||||||
|
At the end of a work session, create or update:
|
||||||
|
|
||||||
|
```text
|
||||||
|
docs/HANDOFF_TEMPLATE.md
|
||||||
|
```
|
||||||
|
|
||||||
|
or a concrete handoff file such as:
|
||||||
|
|
||||||
|
```text
|
||||||
|
reports/Codex_工程产物摘要_v0.1.md
|
||||||
|
```
|
||||||
|
|
||||||
|
The handoff should include:
|
||||||
|
|
||||||
|
- What was completed
|
||||||
|
- What files changed
|
||||||
|
- What assumptions were made
|
||||||
|
- What does not yet work
|
||||||
|
- What needs product judgment
|
||||||
|
- Suggested next tasks
|
||||||
|
|
@ -0,0 +1,148 @@
|
||||||
|
# The Mindscape of Bro Tsong
|
||||||
|
|
||||||
|
Project: The Mindscape of Bro Tsong
|
||||||
|
|
||||||
|
Current phase: `model_library_mvp`
|
||||||
|
|
||||||
|
Current subsystem: Model Library / Model Management MVP
|
||||||
|
|
||||||
|
## 1. Project Definition
|
||||||
|
|
||||||
|
This project is a file-first MVP for a cognitive model library.
|
||||||
|
|
||||||
|
It turns core cognitive models into structured, traceable, callable, and testable model assets.
|
||||||
|
|
||||||
|
The first version validates the workflow with two sample models:
|
||||||
|
|
||||||
|
- QPI
|
||||||
|
- Intellectual Archaeology
|
||||||
|
|
||||||
|
## 2. What This Project Is
|
||||||
|
|
||||||
|
This project is:
|
||||||
|
|
||||||
|
- A model asset library
|
||||||
|
- A model card system
|
||||||
|
- A source evidence index
|
||||||
|
- A regression test container
|
||||||
|
- A minimal model selection demo foundation
|
||||||
|
- A foundation for a future question-answering / cognitive processing system
|
||||||
|
|
||||||
|
## 3. What This Project Is Not
|
||||||
|
|
||||||
|
This project is not:
|
||||||
|
|
||||||
|
- A full model management platform
|
||||||
|
- A public SaaS product
|
||||||
|
- A user-facing application
|
||||||
|
- A complete knowledge graph
|
||||||
|
- A full RAG system
|
||||||
|
- A commercial platform
|
||||||
|
- A multi-user collaboration system
|
||||||
|
- A complete question-answering system
|
||||||
|
|
||||||
|
## 4. Current MVP Goal
|
||||||
|
|
||||||
|
The current MVP tests whether a small number of core cognitive models can be represented as:
|
||||||
|
|
||||||
|
- Human-readable model cards
|
||||||
|
- Machine-readable JSON model specs
|
||||||
|
- Source article records
|
||||||
|
- Source evidence excerpts
|
||||||
|
- Regression test cases
|
||||||
|
- Minimal selector inputs and outputs
|
||||||
|
|
||||||
|
## 5. First Sample Models
|
||||||
|
|
||||||
|
### QPI
|
||||||
|
|
||||||
|
QPI is a routing model that classifies a user input as:
|
||||||
|
|
||||||
|
- Question: lack of information
|
||||||
|
- Problem: lack of path or method
|
||||||
|
- Issue: lack of stability, consensus, or dynamic balance
|
||||||
|
|
||||||
|
### Intellectual Archaeology
|
||||||
|
|
||||||
|
Intellectual Archaeology is a deep modeling model that analyzes a topic through multiple depth layers, from surface application to mechanism, purpose, human capability, and philosophical assumptions.
|
||||||
|
|
||||||
|
## 6. Repository Structure
|
||||||
|
|
||||||
|
```text
|
||||||
|
docs/ Project rules, contracts, workflow notes, decisions, non-goals, and handoff templates.
|
||||||
|
schemas/ JSON Schema files for model specs, source records, source excerpts, and regression cases.
|
||||||
|
models/ Machine-readable JSON model specifications.
|
||||||
|
cards/ Human-readable Markdown model cards.
|
||||||
|
sources/ Source article records and source evidence excerpts.
|
||||||
|
tests/ Regression cases for model use, misuse, and boundary checks.
|
||||||
|
selector/ Rule-based selector configuration and examples.
|
||||||
|
scripts/ Local validation and selector demo scripts.
|
||||||
|
reports/ Validation reports, extraction notes, and concrete session handoffs.
|
||||||
|
```
|
||||||
|
|
||||||
|
## 7. Data Format
|
||||||
|
|
||||||
|
The project uses JSON as the machine-readable source format.
|
||||||
|
|
||||||
|
Markdown files are used for human-readable model cards and documentation.
|
||||||
|
|
||||||
|
## 8. Validation
|
||||||
|
|
||||||
|
All model JSON files should eventually pass schema validation.
|
||||||
|
|
||||||
|
Validation should check:
|
||||||
|
|
||||||
|
- Required fields
|
||||||
|
- Enum values
|
||||||
|
- Unique model IDs
|
||||||
|
- Source article references
|
||||||
|
- Source evidence references
|
||||||
|
- Regression test references
|
||||||
|
|
||||||
|
## 9. Minimal Selector
|
||||||
|
|
||||||
|
The selector is not a full AI system.
|
||||||
|
|
||||||
|
It is a simple demo that recommends candidate models based on:
|
||||||
|
|
||||||
|
- Trigger keywords
|
||||||
|
- Input type match
|
||||||
|
- Negative triggers
|
||||||
|
- Pipeline position
|
||||||
|
- Selection priority
|
||||||
|
|
||||||
|
## 10. Development Principles
|
||||||
|
|
||||||
|
- Keep the MVP small.
|
||||||
|
- Prefer files over databases.
|
||||||
|
- Prefer explicit schema over implicit conventions.
|
||||||
|
- Prefer traceability over automation.
|
||||||
|
- Prefer testability over expressive writing.
|
||||||
|
- Do not expand to many models before the sample models are stable.
|
||||||
|
- Treat `model_library_mvp` as the current phase, not as a nested project root.
|
||||||
|
|
||||||
|
## 11. Related Projects
|
||||||
|
|
||||||
|
- `knowledge-vault`: source archive, discussion records, and durable upstream documentation.
|
||||||
|
- `ccpe-system`: expert-agent, runtime, model, and protocol specification workbench.
|
||||||
|
- `skills-vault`: canonical source for reusable automation skills.
|
||||||
|
- `writing-workbench`: deep writing production workspace.
|
||||||
|
- `video-workbench`: dimensional output workspace for scripts, presentations, and videos.
|
||||||
|
|
||||||
|
This repository consumes selected source material and model definitions from the surrounding ecosystem, but it remains the product/system boundary for The Mindscape of Bro Tsong.
|
||||||
|
|
||||||
|
## 12. Current Status
|
||||||
|
|
||||||
|
Initial project setup.
|
||||||
|
|
||||||
|
## 13. Next Steps
|
||||||
|
|
||||||
|
1. Confirm directory structure.
|
||||||
|
2. Confirm schema files.
|
||||||
|
3. Add QPI model JSON.
|
||||||
|
4. Add Intellectual Archaeology model JSON.
|
||||||
|
5. Add human-readable model cards.
|
||||||
|
6. Add source records and evidence excerpts.
|
||||||
|
7. Add regression cases.
|
||||||
|
8. Add validation scripts.
|
||||||
|
9. Add minimal selector demo.
|
||||||
|
|
@ -0,0 +1,10 @@
|
||||||
|
# Cards
|
||||||
|
|
||||||
|
This folder will contain human-readable Markdown model cards.
|
||||||
|
|
||||||
|
The first expected cards are:
|
||||||
|
|
||||||
|
- `qpi.card.md`
|
||||||
|
- `intellectual_archaeology.card.md`
|
||||||
|
|
||||||
|
Model cards should explain model purpose, mechanism, usage boundaries, misuse risks, source traceability, and productization notes.
|
||||||
|
|
@ -0,0 +1,108 @@
|
||||||
|
# Data Contract
|
||||||
|
|
||||||
|
## 1. Machine-Readable Format
|
||||||
|
|
||||||
|
Use JSON for machine-readable data.
|
||||||
|
|
||||||
|
Main JSON objects:
|
||||||
|
|
||||||
|
- Model spec
|
||||||
|
- Source article
|
||||||
|
- Source excerpt
|
||||||
|
- Regression case
|
||||||
|
- Selector example
|
||||||
|
|
||||||
|
## 2. Human-Readable Format
|
||||||
|
|
||||||
|
Use Markdown for:
|
||||||
|
|
||||||
|
- Model cards
|
||||||
|
- Project documentation
|
||||||
|
- Extraction notes
|
||||||
|
- Validation reports
|
||||||
|
- Handoff reports
|
||||||
|
|
||||||
|
## 3. Model Spec Contract
|
||||||
|
|
||||||
|
Every model JSON should include:
|
||||||
|
|
||||||
|
- `model_id`
|
||||||
|
- `model_name`
|
||||||
|
- `model_type`
|
||||||
|
- `pipeline_position`
|
||||||
|
- `one_sentence_definition`
|
||||||
|
- `core_question`
|
||||||
|
- `core_mechanism`
|
||||||
|
- `source_articles`
|
||||||
|
- `source_evidence`
|
||||||
|
- `input_types`
|
||||||
|
- `output_types`
|
||||||
|
- `call_when`
|
||||||
|
- `do_not_call_when`
|
||||||
|
- `common_misuses`
|
||||||
|
- `failure_modes`
|
||||||
|
- `selection_priority`
|
||||||
|
- `confidence_level`
|
||||||
|
- `stability_profile`
|
||||||
|
- `regression_status`
|
||||||
|
- `productization_notes`
|
||||||
|
|
||||||
|
## 4. Source Article Contract
|
||||||
|
|
||||||
|
Every source article should include:
|
||||||
|
|
||||||
|
- `source_id`
|
||||||
|
- `title`
|
||||||
|
- `source_type`
|
||||||
|
- `related_models`
|
||||||
|
- `source_status`
|
||||||
|
|
||||||
|
Optional:
|
||||||
|
|
||||||
|
- `author`
|
||||||
|
- `date`
|
||||||
|
- `file_path`
|
||||||
|
- `notes`
|
||||||
|
|
||||||
|
## 5. Source Excerpt Contract
|
||||||
|
|
||||||
|
Every source excerpt should include:
|
||||||
|
|
||||||
|
- `excerpt_id`
|
||||||
|
- `source_id`
|
||||||
|
- `related_model_id`
|
||||||
|
- `excerpt_type`
|
||||||
|
- `summary`
|
||||||
|
- `used_for`
|
||||||
|
|
||||||
|
Optional:
|
||||||
|
|
||||||
|
- `raw_excerpt`
|
||||||
|
- `confidence`
|
||||||
|
- `notes`
|
||||||
|
|
||||||
|
## 6. Regression Case Contract
|
||||||
|
|
||||||
|
Every regression case should include:
|
||||||
|
|
||||||
|
- `case_id`
|
||||||
|
- `model_id`
|
||||||
|
- `case_type`
|
||||||
|
- `input`
|
||||||
|
- `expected_behavior`
|
||||||
|
- `failure_signal`
|
||||||
|
|
||||||
|
Optional:
|
||||||
|
|
||||||
|
- `expected_output_elements`
|
||||||
|
- `notes`
|
||||||
|
|
||||||
|
## 7. Reference Integrity
|
||||||
|
|
||||||
|
The following references must be valid:
|
||||||
|
|
||||||
|
- `model.source_articles` -> `sources/source_articles.json`
|
||||||
|
- `model.source_evidence` -> `sources/source_excerpts.json`
|
||||||
|
- `regression_case.model_id` -> `models/*.model.json`
|
||||||
|
- `source_excerpt.source_id` -> `sources/source_articles.json`
|
||||||
|
- `source_excerpt.related_model_id` -> `models/*.model.json`
|
||||||
|
|
@ -0,0 +1,59 @@
|
||||||
|
# Decision Log
|
||||||
|
|
||||||
|
## Decision 001: File-first architecture
|
||||||
|
|
||||||
|
Status: Accepted
|
||||||
|
|
||||||
|
Reason:
|
||||||
|
|
||||||
|
The MVP should remain simple, local, transparent, and easy to inspect.
|
||||||
|
|
||||||
|
A database is unnecessary before the model card schema and extraction protocol are stable.
|
||||||
|
|
||||||
|
## Decision 002: JSON for machine-readable model data
|
||||||
|
|
||||||
|
Status: Accepted
|
||||||
|
|
||||||
|
Reason:
|
||||||
|
|
||||||
|
JSON is easy to validate with JSON Schema and suitable for later integration into scripts, selectors, or applications.
|
||||||
|
|
||||||
|
## Decision 003: Markdown for human-readable model cards
|
||||||
|
|
||||||
|
Status: Accepted
|
||||||
|
|
||||||
|
Reason:
|
||||||
|
|
||||||
|
Markdown is easier for the project owner to read, edit, and review.
|
||||||
|
|
||||||
|
## Decision 004: QPI and Intellectual Archaeology as first sample models
|
||||||
|
|
||||||
|
Status: Accepted
|
||||||
|
|
||||||
|
Reason:
|
||||||
|
|
||||||
|
QPI represents a routing model.
|
||||||
|
|
||||||
|
Intellectual Archaeology represents a deep modeling model.
|
||||||
|
|
||||||
|
Together they test two different kinds of model structures.
|
||||||
|
|
||||||
|
## Decision 005: Rule-based selector in v0.1
|
||||||
|
|
||||||
|
Status: Accepted
|
||||||
|
|
||||||
|
Reason:
|
||||||
|
|
||||||
|
The first selector should validate data structure and model routing logic without relying on LLM calls.
|
||||||
|
|
||||||
|
## Decision 006: Use product root instead of a nested phase directory
|
||||||
|
|
||||||
|
Status: Accepted
|
||||||
|
|
||||||
|
Reason:
|
||||||
|
|
||||||
|
`the-mindscape-of-bro-tsong` is the product and system boundary.
|
||||||
|
|
||||||
|
`model_library_mvp` is the current phase and subsystem goal, not a separate root project.
|
||||||
|
|
||||||
|
The repository should not start as `the-mindscape-of-bro-tsong/model_library_mvp/` because that would add unnecessary root-vs-subproject ambiguity before the product needs a monorepo layout.
|
||||||
|
|
@ -0,0 +1,45 @@
|
||||||
|
# Codex Handoff Template
|
||||||
|
|
||||||
|
## 1. Current Work Session
|
||||||
|
|
||||||
|
Date:
|
||||||
|
|
||||||
|
Task:
|
||||||
|
|
||||||
|
## 2. Completed Work
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
## 3. Files Created
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
## 4. Files Modified
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
## 5. Validation Status
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
## 6. Assumptions Made
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
## 7. Deviations From Plan
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
## 8. Known Issues
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
## 9. Questions for Product / CCRA
|
||||||
|
|
||||||
|
-
|
||||||
|
|
||||||
|
## 10. Suggested Next Tasks
|
||||||
|
|
||||||
|
1.
|
||||||
|
2.
|
||||||
|
3.
|
||||||
|
|
@ -0,0 +1,43 @@
|
||||||
|
# Non-Goals
|
||||||
|
|
||||||
|
The following are explicitly out of scope for v0.1.
|
||||||
|
|
||||||
|
## 1. Platform Features
|
||||||
|
|
||||||
|
- User accounts
|
||||||
|
- Authentication
|
||||||
|
- Authorization
|
||||||
|
- Payment
|
||||||
|
- Public website
|
||||||
|
- Admin dashboard
|
||||||
|
- Multi-user collaboration
|
||||||
|
|
||||||
|
## 2. Knowledge Infrastructure
|
||||||
|
|
||||||
|
- Full knowledge graph
|
||||||
|
- Vector database
|
||||||
|
- Large-scale RAG
|
||||||
|
- Automatic article ingestion
|
||||||
|
- Automatic model extraction from all articles
|
||||||
|
|
||||||
|
## 3. AI Workflow
|
||||||
|
|
||||||
|
- Full multi-agent pipeline
|
||||||
|
- LLM-based model selector
|
||||||
|
- Complete question-answering system
|
||||||
|
- Automated red-team review
|
||||||
|
- Automated model stabilization
|
||||||
|
|
||||||
|
## 4. Content Scope
|
||||||
|
|
||||||
|
- Managing all 100+ models
|
||||||
|
- Importing all historical articles
|
||||||
|
- Generating marketing content
|
||||||
|
- Generating sales copy
|
||||||
|
|
||||||
|
## 5. UI Scope
|
||||||
|
|
||||||
|
- Complex frontend
|
||||||
|
- Visual graph editor
|
||||||
|
- Drag-and-drop model editor
|
||||||
|
- Dashboard analytics
|
||||||
|
|
@ -0,0 +1,62 @@
|
||||||
|
# Project Brief
|
||||||
|
|
||||||
|
## 1. Product Context
|
||||||
|
|
||||||
|
This repository is the MVP foundation for The Mindscape of Bro Tsong.
|
||||||
|
|
||||||
|
The current phase is the cognitive model management subsystem MVP, also called `model_library_mvp`.
|
||||||
|
|
||||||
|
It supports a future problem-answering / cognitive-processing system that will use selected cognitive models to analyze user inputs.
|
||||||
|
|
||||||
|
## 2. First User
|
||||||
|
|
||||||
|
The first user is the project owner.
|
||||||
|
|
||||||
|
This is an OPC-oriented product workflow.
|
||||||
|
|
||||||
|
The system should reduce the burden of managing, testing, and reusing cognitive models as a one-person company.
|
||||||
|
|
||||||
|
## 3. Core Need
|
||||||
|
|
||||||
|
The project solves a model asset management problem:
|
||||||
|
|
||||||
|
- Existing cognitive models are scattered across articles and previous model indexes.
|
||||||
|
- Model cards need stronger source traceability.
|
||||||
|
- Some early models require regression testing and stabilization.
|
||||||
|
- The future question-answering system needs callable model specifications.
|
||||||
|
|
||||||
|
## 4. MVP Focus
|
||||||
|
|
||||||
|
The MVP focuses on two models:
|
||||||
|
|
||||||
|
- QPI
|
||||||
|
- Intellectual Archaeology
|
||||||
|
|
||||||
|
These two models are used to validate the model extraction protocol.
|
||||||
|
|
||||||
|
## 5. Long-Term Direction
|
||||||
|
|
||||||
|
Future versions may support:
|
||||||
|
|
||||||
|
- 8-10 core models
|
||||||
|
- 20 extended models
|
||||||
|
- Model selector
|
||||||
|
- Multi-lens analysis workflow
|
||||||
|
- Conflict summarization
|
||||||
|
- Integrated question-answering system
|
||||||
|
- Source article integration
|
||||||
|
- Model regression dashboard
|
||||||
|
|
||||||
|
These are not part of v0.1 unless explicitly requested.
|
||||||
|
|
||||||
|
## 6. Project Ecosystem
|
||||||
|
|
||||||
|
This repository is separate from but related to:
|
||||||
|
|
||||||
|
- `knowledge-vault`: upstream source archive and discussion records.
|
||||||
|
- `ccpe-system`: expert-agent and runtime specification workspace.
|
||||||
|
- `skills-vault`: canonical source for reusable automation skills.
|
||||||
|
- `writing-workbench`: deep writing production workspace.
|
||||||
|
- `video-workbench`: dimensional output workspace.
|
||||||
|
|
||||||
|
This project may reference artifacts from those repositories, but its own boundary is the model asset foundation for The Mindscape of Bro Tsong.
|
||||||
|
|
@ -0,0 +1,61 @@
|
||||||
|
# Workflow
|
||||||
|
|
||||||
|
## 1. Model Extraction Workflow
|
||||||
|
|
||||||
|
The project follows this flow:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Original article / representative text
|
||||||
|
-> source article record
|
||||||
|
-> source evidence excerpts
|
||||||
|
-> human-readable model card
|
||||||
|
-> machine-readable model JSON
|
||||||
|
-> regression cases
|
||||||
|
-> selector examples
|
||||||
|
-> validation report
|
||||||
|
```
|
||||||
|
|
||||||
|
## 2. Development Workflow
|
||||||
|
|
||||||
|
For each task:
|
||||||
|
|
||||||
|
1. Read `README.md` and `AGENTS.md`.
|
||||||
|
2. Check `docs/PROJECT_BRIEF.md`.
|
||||||
|
3. Modify the smallest necessary set of files.
|
||||||
|
4. Keep JSON and Markdown versions consistent.
|
||||||
|
5. Run or update validation.
|
||||||
|
6. Update reports or handoff notes.
|
||||||
|
7. Do not expand scope without confirmation.
|
||||||
|
|
||||||
|
## 3. Model Addition Workflow
|
||||||
|
|
||||||
|
When adding a new model:
|
||||||
|
|
||||||
|
1. Create a model JSON file in `models/`.
|
||||||
|
2. Create a human-readable card in `cards/`.
|
||||||
|
3. Add source article records.
|
||||||
|
4. Add source evidence excerpts.
|
||||||
|
5. Add regression cases.
|
||||||
|
6. Add selector examples if relevant.
|
||||||
|
7. Run validation.
|
||||||
|
8. Update documentation.
|
||||||
|
|
||||||
|
## 4. Stabilization Workflow
|
||||||
|
|
||||||
|
If a model is unstable:
|
||||||
|
|
||||||
|
1. Mark `needs_stabilization: true`.
|
||||||
|
2. Add risks in `stability_profile.main_risks`.
|
||||||
|
3. Add boundary and misuse regression cases.
|
||||||
|
4. Do not upgrade to stability level A until tests pass.
|
||||||
|
|
||||||
|
## 5. Handoff Workflow
|
||||||
|
|
||||||
|
At the end of each work session:
|
||||||
|
|
||||||
|
1. Summarize what changed.
|
||||||
|
2. List created and modified files.
|
||||||
|
3. Record validation status.
|
||||||
|
4. Separate assumptions from verified facts.
|
||||||
|
5. List questions that require product or CCRA judgment.
|
||||||
|
6. Suggest the smallest useful next tasks.
|
||||||
|
|
@ -0,0 +1,142 @@
|
||||||
|
# Project Initialization Implementation Plan
|
||||||
|
|
||||||
|
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||||
|
|
||||||
|
**Goal:** Initialize The Mindscape of Bro Tsong as a file-first cognitive model library MVP repository.
|
||||||
|
|
||||||
|
**Architecture:** The repository root is the product boundary. `model_library_mvp` is recorded as the current phase rather than implemented as a nested directory. The first commit creates documentation, rules, directory purpose files, and a concrete handoff without implementing model extraction.
|
||||||
|
|
||||||
|
**Tech Stack:** Markdown, JSON-ready folder structure, Git.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Task 1: Create Root Documentation
|
||||||
|
|
||||||
|
**Files:**
|
||||||
|
|
||||||
|
- Create: `README.md`
|
||||||
|
- Create: `AGENTS.md`
|
||||||
|
|
||||||
|
- [x] **Step 1: Write project README**
|
||||||
|
|
||||||
|
Create `README.md` with project definition, phase name, first sample models, non-goals, repository structure, validation expectations, and next steps.
|
||||||
|
|
||||||
|
- [x] **Step 2: Write Codex working rules**
|
||||||
|
|
||||||
|
Create `AGENTS.md` with role boundaries, non-goals, data rules, source traceability rules, regression expectations, selector expectations, validation expectations, and handoff requirements.
|
||||||
|
|
||||||
|
### Task 2: Create Rule Documents
|
||||||
|
|
||||||
|
**Files:**
|
||||||
|
|
||||||
|
- Create: `docs/PROJECT_BRIEF.md`
|
||||||
|
- Create: `docs/DATA_CONTRACT.md`
|
||||||
|
- Create: `docs/WORKFLOW.md`
|
||||||
|
- Create: `docs/DECISIONS.md`
|
||||||
|
- Create: `docs/NON_GOALS.md`
|
||||||
|
- Create: `docs/HANDOFF_TEMPLATE.md`
|
||||||
|
|
||||||
|
- [x] **Step 1: Create project brief**
|
||||||
|
|
||||||
|
Document product context, first user, core need, MVP focus, long-term direction, and related project boundaries.
|
||||||
|
|
||||||
|
- [x] **Step 2: Create data contract**
|
||||||
|
|
||||||
|
Document JSON and Markdown responsibilities plus required fields for model specs, source articles, source excerpts, and regression cases.
|
||||||
|
|
||||||
|
- [x] **Step 3: Create workflow rules**
|
||||||
|
|
||||||
|
Document model extraction, development, model addition, stabilization, and handoff workflows.
|
||||||
|
|
||||||
|
- [x] **Step 4: Create decision log**
|
||||||
|
|
||||||
|
Record accepted structural decisions, including file-first architecture, JSON, Markdown, first sample models, rule-based selector, and flattened repository layout.
|
||||||
|
|
||||||
|
- [x] **Step 5: Create non-goals and handoff template**
|
||||||
|
|
||||||
|
Document v0.1 exclusions and a reusable handoff template.
|
||||||
|
|
||||||
|
### Task 3: Create Folder Purpose Files
|
||||||
|
|
||||||
|
**Files:**
|
||||||
|
|
||||||
|
- Create: `schemas/README.md`
|
||||||
|
- Create: `models/README.md`
|
||||||
|
- Create: `cards/README.md`
|
||||||
|
- Create: `sources/README.md`
|
||||||
|
- Create: `tests/README.md`
|
||||||
|
- Create: `selector/README.md`
|
||||||
|
- Create: `scripts/README.md`
|
||||||
|
- Create: `reports/README.md`
|
||||||
|
|
||||||
|
- [x] **Step 1: Create folder READMEs**
|
||||||
|
|
||||||
|
Create one README per initial folder so Git tracks the intended structure without adding empty placeholder data files.
|
||||||
|
|
||||||
|
### Task 4: Create Session Handoff
|
||||||
|
|
||||||
|
**Files:**
|
||||||
|
|
||||||
|
- Create: `reports/Codex_工程产物摘要_v0.1.md`
|
||||||
|
|
||||||
|
- [x] **Step 1: Write concrete session handoff**
|
||||||
|
|
||||||
|
Record completed work, created files, validation status, assumptions, deviations, known issues, product questions, and suggested next tasks.
|
||||||
|
|
||||||
|
### Task 5: Publish Initialization
|
||||||
|
|
||||||
|
**Files:**
|
||||||
|
|
||||||
|
- Git metadata only
|
||||||
|
|
||||||
|
- [ ] **Step 1: Initialize Git repository**
|
||||||
|
|
||||||
|
Run: `git init`
|
||||||
|
|
||||||
|
Expected: repository initialized in the current project root.
|
||||||
|
|
||||||
|
- [ ] **Step 2: Set default branch to main**
|
||||||
|
|
||||||
|
Run: `git branch -M main`
|
||||||
|
|
||||||
|
Expected: current branch is `main`.
|
||||||
|
|
||||||
|
- [ ] **Step 3: Add remote**
|
||||||
|
|
||||||
|
Run: `git remote add origin https://git.wantsong.life/wantsong/the-mindscape-of-bro-tsong.git`
|
||||||
|
|
||||||
|
Expected: `origin` points to the project remote.
|
||||||
|
|
||||||
|
- [ ] **Step 4: Verify structure**
|
||||||
|
|
||||||
|
Run: path checks for root files, docs files, and folder README files.
|
||||||
|
|
||||||
|
Expected: all expected files exist.
|
||||||
|
|
||||||
|
- [ ] **Step 5: Commit initialization**
|
||||||
|
|
||||||
|
Run:
|
||||||
|
|
||||||
|
```text
|
||||||
|
git add README.md AGENTS.md docs schemas models cards sources tests selector scripts reports
|
||||||
|
git commit -m "chore: initialize model library mvp"
|
||||||
|
```
|
||||||
|
|
||||||
|
Expected: a root commit containing the initialization files.
|
||||||
|
|
||||||
|
- [ ] **Step 6: Tag initialization**
|
||||||
|
|
||||||
|
Run: `git tag model-library-mvp-init-v0.1`
|
||||||
|
|
||||||
|
Expected: local tag created on the initialization commit.
|
||||||
|
|
||||||
|
- [ ] **Step 7: Push branch and tag**
|
||||||
|
|
||||||
|
Run:
|
||||||
|
|
||||||
|
```text
|
||||||
|
git push -u origin main
|
||||||
|
git push origin model-library-mvp-init-v0.1
|
||||||
|
```
|
||||||
|
|
||||||
|
Expected: branch and tag are available on the remote repository.
|
||||||
|
|
@ -0,0 +1,10 @@
|
||||||
|
# Models
|
||||||
|
|
||||||
|
This folder will contain machine-readable JSON model specifications.
|
||||||
|
|
||||||
|
The first expected sample models are:
|
||||||
|
|
||||||
|
- `qpi.model.json`
|
||||||
|
- `intellectual_archaeology.model.json`
|
||||||
|
|
||||||
|
Each model file must follow `docs/DATA_CONTRACT.md` and reference valid source and evidence records.
|
||||||
|
|
@ -0,0 +1,79 @@
|
||||||
|
# Codex 工程产物摘要 v0.1
|
||||||
|
|
||||||
|
## 1. Current Work Session
|
||||||
|
|
||||||
|
Date: 2026-06-16
|
||||||
|
|
||||||
|
Task: Initialize The Mindscape of Bro Tsong repository for the `model_library_mvp` phase.
|
||||||
|
|
||||||
|
## 2. Completed Work
|
||||||
|
|
||||||
|
- Initialized the project as a file-first cognitive model library MVP.
|
||||||
|
- Kept `model_library_mvp` as the current phase name instead of creating a nested project directory.
|
||||||
|
- Added root project documentation.
|
||||||
|
- Added Codex working rules.
|
||||||
|
- Added docs for project brief, data contract, workflow, decisions, non-goals, and handoff template.
|
||||||
|
- Added purpose README files for all initial project folders.
|
||||||
|
|
||||||
|
## 3. Files Created
|
||||||
|
|
||||||
|
- `README.md`
|
||||||
|
- `AGENTS.md`
|
||||||
|
- `docs/PROJECT_BRIEF.md`
|
||||||
|
- `docs/DATA_CONTRACT.md`
|
||||||
|
- `docs/WORKFLOW.md`
|
||||||
|
- `docs/DECISIONS.md`
|
||||||
|
- `docs/NON_GOALS.md`
|
||||||
|
- `docs/HANDOFF_TEMPLATE.md`
|
||||||
|
- `schemas/README.md`
|
||||||
|
- `models/README.md`
|
||||||
|
- `cards/README.md`
|
||||||
|
- `sources/README.md`
|
||||||
|
- `tests/README.md`
|
||||||
|
- `selector/README.md`
|
||||||
|
- `scripts/README.md`
|
||||||
|
- `reports/README.md`
|
||||||
|
- `reports/Codex_工程产物摘要_v0.1.md`
|
||||||
|
|
||||||
|
## 4. Files Modified
|
||||||
|
|
||||||
|
- None. This was the initial file creation.
|
||||||
|
|
||||||
|
## 5. Validation Status
|
||||||
|
|
||||||
|
- Directory structure created.
|
||||||
|
- Markdown documentation created.
|
||||||
|
- No schema, model JSON, selector config, or Python scripts have been implemented yet.
|
||||||
|
- No runtime validation is available yet.
|
||||||
|
|
||||||
|
## 6. Assumptions Made
|
||||||
|
|
||||||
|
- The repository root is `the-mindscape-of-bro-tsong`.
|
||||||
|
- `model_library_mvp` is the current phase and subsystem goal, not a nested directory.
|
||||||
|
- The first model extraction phase will focus on QPI and Intellectual Archaeology.
|
||||||
|
- External source archives remain in `knowledge-vault`; this project stores selected model assets and source references needed for the product.
|
||||||
|
|
||||||
|
## 7. Deviations From Plan
|
||||||
|
|
||||||
|
- The recommended nested `model_library_mvp/` path from the source initialization brief was intentionally flattened based on the project-root discussion.
|
||||||
|
- Schema files and sample model JSON files were not created during initialization because the next phase will perform concrete model extraction.
|
||||||
|
|
||||||
|
## 8. Known Issues
|
||||||
|
|
||||||
|
- JSON schemas do not exist yet.
|
||||||
|
- QPI and Intellectual Archaeology model files do not exist yet.
|
||||||
|
- Source article and source excerpt records do not exist yet.
|
||||||
|
- Regression cases do not exist yet.
|
||||||
|
- Selector rules do not exist yet.
|
||||||
|
|
||||||
|
## 9. Questions for Product / CCRA
|
||||||
|
|
||||||
|
- Which source articles should be treated as canonical evidence for QPI?
|
||||||
|
- Which source articles should be treated as canonical evidence for Intellectual Archaeology?
|
||||||
|
- Should model IDs use English slugs only, or allow bilingual aliases in metadata?
|
||||||
|
|
||||||
|
## 10. Suggested Next Tasks
|
||||||
|
|
||||||
|
1. Define JSON schemas for model specs, source articles, source excerpts, and regression cases.
|
||||||
|
2. Extract the QPI model card and model JSON from canonical source material.
|
||||||
|
3. Extract the Intellectual Archaeology model card and model JSON from canonical source material.
|
||||||
|
|
@ -0,0 +1,11 @@
|
||||||
|
# Reports
|
||||||
|
|
||||||
|
This folder will contain generated or manually written project reports.
|
||||||
|
|
||||||
|
Expected future files:
|
||||||
|
|
||||||
|
- `validation_report.md`
|
||||||
|
- `extraction_notes.md`
|
||||||
|
- Concrete Codex handoff reports
|
||||||
|
|
||||||
|
Reports should separate verified facts, assumptions, unresolved questions, and suggested next tasks.
|
||||||
|
|
@ -0,0 +1,12 @@
|
||||||
|
# Schemas
|
||||||
|
|
||||||
|
This folder will contain JSON Schema files for machine-readable project data.
|
||||||
|
|
||||||
|
Expected future files:
|
||||||
|
|
||||||
|
- `model_card.schema.json`
|
||||||
|
- `source_article.schema.json`
|
||||||
|
- `source_excerpt.schema.json`
|
||||||
|
- `regression_case.schema.json`
|
||||||
|
|
||||||
|
Do not add schema complexity before the first two sample models are stable enough to validate.
|
||||||
|
|
@ -0,0 +1,12 @@
|
||||||
|
# Scripts
|
||||||
|
|
||||||
|
This folder will contain simple local scripts for validation and selector demos.
|
||||||
|
|
||||||
|
Expected future scripts:
|
||||||
|
|
||||||
|
- `validate_models.py`
|
||||||
|
- `validate_sources.py`
|
||||||
|
- `validate_tests.py`
|
||||||
|
- `run_selector_demo.py`
|
||||||
|
|
||||||
|
Prefer Python standard library before adding dependencies.
|
||||||
|
|
@ -0,0 +1,13 @@
|
||||||
|
# Selector
|
||||||
|
|
||||||
|
This folder will contain rule-based selector configuration and examples.
|
||||||
|
|
||||||
|
The v0.1 selector should not call an LLM.
|
||||||
|
|
||||||
|
It should use simple matching rules:
|
||||||
|
|
||||||
|
- Trigger keywords
|
||||||
|
- Input types
|
||||||
|
- Negative triggers
|
||||||
|
- Pipeline position
|
||||||
|
- Selection priority
|
||||||
|
|
@ -0,0 +1,10 @@
|
||||||
|
# Sources
|
||||||
|
|
||||||
|
This folder will contain source records and source evidence excerpts.
|
||||||
|
|
||||||
|
Expected future files:
|
||||||
|
|
||||||
|
- `source_articles.json`
|
||||||
|
- `source_excerpts.json`
|
||||||
|
|
||||||
|
Do not treat placeholder source records as verified evidence. Mark incomplete source material clearly.
|
||||||
|
|
@ -0,0 +1,11 @@
|
||||||
|
# Tests
|
||||||
|
|
||||||
|
This folder will contain regression cases for cognitive model use.
|
||||||
|
|
||||||
|
Regression cases are not only code tests. They are also product tests for whether a model is called appropriately.
|
||||||
|
|
||||||
|
Each core model should eventually include:
|
||||||
|
|
||||||
|
- Positive cases
|
||||||
|
- Boundary cases
|
||||||
|
- Misuse cases
|
||||||
Loading…
Reference in New Issue