feat: integrate framework files into monorepo under packages/mosaic/framework/
Moves all Mosaic framework runtime files from the separate bootstrap repo into the monorepo as canonical source. The @mosaic/mosaic npm package now ships the complete framework — bin scripts, runtime configs, tools, and templates — enabling standalone installation via npm install. Structure: packages/mosaic/framework/ ├── bin/ 28 CLI scripts (mosaic, mosaic-doctor, mosaic-sync-skills, etc.) ├── runtime/ Runtime adapters (claude, codex, opencode, pi, mcp) ├── tools/ Shell tooling (git, prdy, orchestrator, quality, etc.) ├── templates/ Agent and repo templates ├── defaults/ Default identity files (AGENTS.md, STANDARDS.md, SOUL.md, etc.) ├── install.sh Legacy bash installer └── remote-install.sh One-liner remote installer Key files with Pi support and recent fixes: - bin/mosaic: launch_pi() with skills-local loop - bin/mosaic-doctor: --fix auto-wiring for all 4 harnesses - bin/mosaic-sync-skills: Pi as 4th link target, symlink-aware find - bin/mosaic-link-runtime-assets: Pi settings.json patching - bin/mosaic-migrate-local-skills: Pi skill roots, symlink find - runtime/pi/RUNTIME.md + mosaic-extension.ts Package ships 251 framework files in the npm tarball (278KB compressed).
This commit is contained in:
75
packages/mosaic/framework/templates/docs/PRD.md.template
Normal file
75
packages/mosaic/framework/templates/docs/PRD.md.template
Normal file
@@ -0,0 +1,75 @@
|
||||
# PRD: {PROJECT_OR_FEATURE_NAME}
|
||||
|
||||
## Metadata
|
||||
|
||||
- Owner: {owner}
|
||||
- Date: {yyyy-mm-dd}
|
||||
- Status: draft|approved|in-progress|completed
|
||||
- Best-Guess Mode: true|false
|
||||
|
||||
## Problem Statement
|
||||
|
||||
{what problem is being solved and why now}
|
||||
|
||||
## Objectives
|
||||
|
||||
1. {objective-1}
|
||||
2. {objective-2}
|
||||
|
||||
## Scope
|
||||
|
||||
### In Scope
|
||||
|
||||
1. {in-scope-item}
|
||||
|
||||
### Out of Scope
|
||||
|
||||
1. {out-of-scope-item}
|
||||
|
||||
## User/Stakeholder Requirements
|
||||
|
||||
1. {requirement}
|
||||
|
||||
## Functional Requirements
|
||||
|
||||
1. {functional-requirement}
|
||||
|
||||
## Non-Functional Requirements
|
||||
|
||||
1. Security: {requirements}
|
||||
2. Performance: {requirements}
|
||||
3. Reliability: {requirements}
|
||||
4. Observability: {requirements}
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
1. {ac-1}
|
||||
2. {ac-2}
|
||||
|
||||
## Constraints and Dependencies
|
||||
|
||||
1. {constraint-or-dependency}
|
||||
|
||||
## Risks and Open Questions
|
||||
|
||||
1. Risk: {risk}
|
||||
2. Open Question: {question}
|
||||
|
||||
## Testing and Verification Expectations
|
||||
|
||||
1. Baseline checks: {lint/type/unit/integration expectations}
|
||||
2. Situational testing: {required situational checks}
|
||||
3. Evidence format: {how verification will be reported}
|
||||
|
||||
## Milestone / Delivery Intent
|
||||
|
||||
1. Target milestone/version: {e.g., 0.0.2}
|
||||
2. Definition of done: {completion conditions}
|
||||
|
||||
## Assumptions
|
||||
|
||||
List only if Best-Guess Mode is true.
|
||||
Prefix each entry with `ASSUMPTION:`.
|
||||
|
||||
1. ASSUMPTION: {guessed decision and rationale}
|
||||
|
||||
Reference in New Issue
Block a user