feat: Oracle CRM Page, Synthetic Client Data and Live Snapshot when hitting emotion hotpoint
This commit is contained in:
116
.Agent Context/Sprint 1/Templates/00 - Template Pack Guide.md
Normal file
116
.Agent Context/Sprint 1/Templates/00 - Template Pack Guide.md
Normal file
@@ -0,0 +1,116 @@
|
||||
# Biomimetic Agentic Orchestration Layer Template Pack Guide
|
||||
|
||||
**Date:** [YYYY-MM-DD]
|
||||
**Status:** Reusable template pack
|
||||
**Purpose:** Provide a repeatable document system for assigning, executing, reviewing, and shipping biomimetic orchestration work across the Project Velocity team.
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This folder is the reusable counterpart to the completed biomimetic orchestration artifact set.
|
||||
|
||||
It exists so the team can produce future work packets with the same document discipline instead of rewriting structure from scratch every time.
|
||||
|
||||
## 2. What This Pack Mirrors
|
||||
|
||||
This pack mirrors the current artifact system in:
|
||||
|
||||
- `Biomimetic Agentic Orchestration Layer`
|
||||
|
||||
The original set is the filled example. This folder is the reusable skeleton.
|
||||
|
||||
## 3. How to Use the Pack
|
||||
|
||||
Use this sequence:
|
||||
|
||||
1. duplicate the template file you need
|
||||
2. rename it to the target workstream, subsystem, or sprint deliverable
|
||||
3. fill metadata first
|
||||
4. fill sections in order
|
||||
5. remove any section that is truly out of scope only after the owner and reviewer agree
|
||||
|
||||
## 4. Mandatory Metadata for Every Filled Document
|
||||
|
||||
Every derived document must include:
|
||||
|
||||
- title
|
||||
- date
|
||||
- status
|
||||
- owner
|
||||
- reviewers
|
||||
- scope
|
||||
- purpose
|
||||
- decision boundary
|
||||
|
||||
## 5. Document Map
|
||||
|
||||
Use these templates for these outcomes:
|
||||
|
||||
- `01 - First Principles and Product Understanding Template.md`
|
||||
- use for concept, problem framing, architecture intent, and design logic
|
||||
- `02 - PRD Template.md`
|
||||
- use for product goals, value, user outcomes, and release framing
|
||||
- `03 - SRS Template.md`
|
||||
- use for system requirements, interfaces, NFRs, and acceptance criteria
|
||||
- `04 - Sprint Plan Template.md`
|
||||
- use for sprint-level scope, milestones, and acceptance
|
||||
- `05 - Implementation Blueprint Template.md`
|
||||
- use for repository mapping and runtime shape
|
||||
- `06 - Execution Backlog Template.md`
|
||||
- use for sequenced delivery program, ownership, and sales gates
|
||||
- `07 - Mission Contracts and JSON Schemas Template.md`
|
||||
- use for schema and artifact contract design
|
||||
- `08 - Adapter Detailed Implementation Spec Template.md`
|
||||
- use for Oracle, CRM, Catalyst, Sentinel, or future adapters
|
||||
- `09 - Colony Database Schema and Root API Spec Template.md`
|
||||
- use for SQL shape, repository methods, API surface, and lifecycle states
|
||||
- `10 - TypeScript Colony Service Internal Module Spec Template.md`
|
||||
- use for service internals and module boundaries
|
||||
- `11 - Prompt Master Librarian Researcher Role Spec Template.md`
|
||||
- use for role-specific operating contracts
|
||||
- `12 - Deployment Operations and Release Readiness Template.md`
|
||||
- use for deployment, runbooks, rollout, and sales safety
|
||||
- `13 - Implementation Ticket Breakdown and Dependency Matrix Template.md`
|
||||
- use for ticket slicing and dependency control
|
||||
|
||||
## 6. Ownership Rule
|
||||
|
||||
One document must have one accountable owner.
|
||||
|
||||
Contributors may write sections, but one person owns:
|
||||
|
||||
- coherence
|
||||
- contradiction removal
|
||||
- final review submission
|
||||
|
||||
## 7. Review Rule
|
||||
|
||||
Every filled document should be reviewed by:
|
||||
|
||||
- one domain owner
|
||||
- one integration owner
|
||||
- one delivery or product reviewer when the artifact affects roadmap or demos
|
||||
|
||||
## 8. Quality Rule
|
||||
|
||||
A filled document is not complete if it still contains:
|
||||
|
||||
- vague placeholders
|
||||
- contradictory scope
|
||||
- missing acceptance criteria
|
||||
- file paths with no intended owner
|
||||
- runtime decisions with no migration path
|
||||
|
||||
## 9. Recommended Working Method
|
||||
|
||||
Best working method for this pack:
|
||||
|
||||
- fill top-level narrative first
|
||||
- then file and interface details
|
||||
- then acceptance gates
|
||||
- then operational and sales-readiness checks
|
||||
|
||||
This keeps the documents aligned instead of producing isolated technical fragments.
|
||||
|
||||
## 10. Bottom Line
|
||||
|
||||
The goal of this pack is not to standardize formatting for its own sake. The goal is to standardize decision quality, implementation clarity, and handoff readiness.
|
||||
Reference in New Issue
Block a user