feat: Oracle CRM Page, Synthetic Client Data and Live Snapshot when hitting emotion hotpoint

.Agent Context/Sprint 1/Templates/00 - Template Pack Guide.md

@@ -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.

.Agent Context/Sprint 1/Templates/01 - First Principles and Product Understanding Template.md

@@ -0,0 +1,170 @@
+# [System or Workstream Name] - First Principles and Product Understanding
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Subsystem, mission class, runtime layer, or product surface]  
+**Purpose:** Define the problem, intended product behavior, and architectural logic from first principles before implementation begins.
+
+## Executive Summary
+
+State:
+
+- what this system is
+- why it matters
+- why current architecture is insufficient
+- what the target improvement is
+
+## Assumptions and Constraints
+
+### Assumptions
+
+State the assumptions that must be true for this design to hold.
+
+### Constraints
+
+State the technical, organizational, legal, runtime, and infrastructure constraints that shape the solution.
+
+## Reference Sources and Rationale
+
+### Local Sources
+
+List:
+
+- current repo files
+- existing design docs
+- prior integration artifacts
+
+Explain why each source matters.
+
+### Upstream or External Sources
+
+List:
+
+- upstream frameworks
+- public reference repos
+- external standards or papers if used
+
+Explain what is being borrowed and what is not.
+
+## Problem Statement
+
+Describe the underlying problem in plain terms:
+
+- current failure mode
+- why it exists
+- what business or product damage it causes
+- why the current team cannot just “work around” it forever
+
+## System Vision
+
+Describe the intended end state:
+
+- operator experience
+- internal execution model
+- auditability and safety expectations
+- where this system fits inside Project Velocity
+
+## Core Metaphor or Design Lens
+
+If using a metaphor such as biomimicry, define:
+
+- the mapping from metaphor to real system parts
+- what the metaphor clarifies
+- what the metaphor must not be allowed to distort
+
+## First-Principles Architecture
+
+Document the foundational principles that should govern all implementation.
+
+### Principle 1
+
+Name the principle and explain:
+
+- what it means
+- why it matters
+- what tradeoff it creates
+
+### Principle 2
+
+Repeat.
+
+### Principle 3
+
+Repeat.
+
+Add as many principles as the work requires.
+
+## Functional Architecture and Key Roles
+
+Describe the main runtime layers and their responsibilities.
+
+For each role or layer, state:
+
+- purpose
+- inputs
+- outputs
+- hard boundaries
+- failure modes
+
+## Data Model and Interfaces
+
+List the major internal artifacts or interfaces that this system depends on.
+
+For each artifact, describe:
+
+- identity fields
+- producer
+- consumer
+- why it exists
+
+## Interaction and Workflow Description
+
+Describe the standard operational flow from input to output.
+
+Then describe:
+
+- exceptional flows
+- failure handling
+- review or escalation path
+
+## Improvements and Recommendations
+
+List the recommended design improvements over a naive implementation.
+
+For each improvement, explain:
+
+- what changes
+- why it is better
+- what it costs
+
+## Migration and Fork Strategy
+
+Describe:
+
+- what to reuse
+- what to fork
+- what not to inherit
+- how to preserve provenance and licensing clarity
+
+## What This Means for Project Velocity
+
+State the direct product and implementation implications:
+
+- what becomes easier
+- what becomes safer
+- what becomes sellable
+- what still remains out of scope
+
+## Recommended Initial Scope
+
+Define the minimum mission classes, modules, or surfaces to start with.
+
+## Open Questions
+
+List the unresolved issues that need explicit follow-up.
+
+## Bottom Line
+
+Summarize the design truth in one or two paragraphs.

.Agent Context/Sprint 1/Templates/02 - PRD Template.md

@@ -0,0 +1,105 @@
+# Product Requirements Document (PRD)_ [System or Workstream Name]
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Product slice or release boundary]  
+**Purpose:** Define the product intent, value, scope, and release criteria for the target system.
+
+## 1. Purpose
+
+State what product problem this work solves and why it exists now.
+
+## 2. Background
+
+Describe:
+
+- current product state
+- why existing flows are insufficient
+- what changed to make this work necessary
+
+## 3. Problem Statement
+
+Define the concrete product and operator pain points.
+
+## 4. Product Goal
+
+Define the primary product goal in one paragraph.
+
+## 5. Target Users and Stakeholders
+
+List:
+
+- primary users
+- internal operators
+- reviewers or approvers
+- sales or demo stakeholders
+
+## 6. In-Scope Outcomes
+
+State the capabilities that must exist in the release.
+
+## 7. Out-of-Scope Items
+
+State what this release will explicitly not solve.
+
+## 8. Product Experience
+
+Describe what the user or operator should see and do from start to finish.
+
+## 9. Functional Requirements
+
+For each functional requirement, state:
+
+- requirement ID
+- description
+- rationale
+- acceptance signal
+
+## 10. System Behavior
+
+Describe:
+
+- happy path
+- failure path
+- approval path
+- audit path
+
+## 11. Success Metrics
+
+Define measurable product outcomes such as:
+
+- completion rate
+- operator effort reduction
+- citation coverage
+- mission latency
+- demo success rate
+
+## 12. Risks
+
+List product, technical, governance, and adoption risks.
+
+## 13. Release Plan
+
+Describe:
+
+- release phases
+- feature gating
+- assisted mode vs autonomous mode
+
+## 14. Sales Readiness
+
+Define what must be true for this work to be demo-safe and commercially useful.
+
+## 15. Dependencies
+
+List upstream systems, teams, or documents this PRD depends on.
+
+## 16. Acceptance Criteria
+
+State the release-level acceptance criteria.
+
+## 17. Bottom Line
+
+Summarize the product decision in plain language.

.Agent Context/Sprint 1/Templates/03 - SRS Template.md

@@ -0,0 +1,106 @@
+# Software Requirements Specification (SRS)_ [System or Workstream Name]
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Technical system boundary]  
+**Purpose:** Define the technical requirements, interfaces, constraints, and acceptance criteria for implementation.
+
+## 1. Purpose
+
+State what technical system is being specified and why.
+
+## 2. System Context
+
+Describe where the system lives inside Project Velocity and what it integrates with.
+
+## 3. Assumptions and Constraints
+
+State:
+
+- runtime assumptions
+- infrastructure assumptions
+- compatibility constraints
+- legal or licensing constraints
+
+## 4. Functional Architecture
+
+Describe the runtime layers, modules, or services.
+
+## 5. Functional Requirements
+
+For each requirement, include:
+
+- requirement ID
+- description
+- producer and consumer if relevant
+- acceptance criteria
+
+## 6. Interface Requirements
+
+Specify:
+
+- APIs
+- internal service interfaces
+- event contracts
+- schema boundaries
+
+## 7. Data Model
+
+Describe entities, artifacts, identifiers, and lifecycle fields.
+
+## 8. Non-Functional Requirements
+
+### 8.1 Reliability
+
+Define uptime, retry, or failure-handling expectations.
+
+### 8.2 Scalability
+
+Define concurrency, throughput, or growth assumptions.
+
+### 8.3 Security
+
+Define access control, auth, and approval expectations.
+
+### 8.4 Privacy
+
+Define redaction, least-privilege, and data exposure rules.
+
+### 8.5 Observability
+
+Define metrics, traces, and logs.
+
+### 8.6 Fault Tolerance
+
+Define degraded behavior and replay strategy.
+
+### 8.7 Licensing
+
+Define upstream provenance and redistribution constraints if relevant.
+
+## 9. Evaluation and Testing Strategy
+
+Describe:
+
+- unit testing
+- integration testing
+- replay testing
+- governance testing
+
+## 10. Migration and Fork Plan
+
+Describe:
+
+- what is forked
+- what remains upstream-compatible
+- what migration path exists from current state
+
+## 11. Open Questions
+
+List unresolved technical issues.
+
+## 12. Acceptance Criteria
+
+Define the completion gate for engineering.

.Agent Context/Sprint 1/Templates/04 - Sprint Plan Template.md

@@ -0,0 +1,63 @@
+# Sprint Plan_ [System or Workstream Name]
+
+**Date:** [YYYY-MM-DD]  
+**Sprint Window:** [Start Date] to [End Date]  
+**Status:** [Draft | In Progress | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Purpose:** Define the sprint-level execution plan, scope, deliverables, dependencies, and acceptance gates.
+
+## 1. Purpose
+
+State what this sprint is intended to achieve.
+
+## 2. Sprint Goal
+
+Describe the one-sentence outcome that makes the sprint successful.
+
+## 3. Scope
+
+Describe what is included in this sprint.
+
+## 4. Non-Scope
+
+Describe what is explicitly not included.
+
+## 5. Deliverables
+
+List the concrete deliverables:
+
+- docs
+- code
+- routes
+- schemas
+- test suites
+- demos
+
+## 6. Milestones
+
+Define milestone checkpoints in order.
+
+## 7. Integration Points
+
+List the current Project Velocity files, services, or modules affected.
+
+## 8. Risks and Dependencies
+
+List risks, blockers, and external dependencies.
+
+## 9. Acceptance Gates
+
+Define the gates that must pass before the sprint is considered complete.
+
+## 10. Ownership
+
+Assign one accountable owner per workstream.
+
+## 11. Timeline
+
+Describe the expected order of delivery inside the sprint.
+
+## 12. Bottom Line
+
+Summarize the sprint contract.

.Agent Context/Sprint 1/Templates/05 - Implementation Blueprint Template.md

@@ -0,0 +1,97 @@
+# Implementation Blueprint_ Repository and Runtime Mapping
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Subsystem or runtime boundary]  
+**Purpose:** Convert the design into a repository-level implementation skeleton tied to the current codebase.
+
+## 1. Purpose
+
+State what this blueprint is mapping and why it exists.
+
+## 2. Current State Mapping
+
+Describe the relevant existing code and runtime truth.
+
+### 2.1 Root Backend Truth
+
+List existing routes, services, or modules that already exist.
+
+### 2.2 Domain Truth
+
+Describe current Oracle, CRM, Catalyst, Sentinel, or other subsystem state.
+
+### 2.3 Frontend Truth
+
+Describe the frontend surfaces that will eventually consume the implementation.
+
+## 3. Target Runtime Shape
+
+Define:
+
+- root authority
+- internal service authority
+- governance authority
+
+Explain why the split is correct.
+
+## 4. File-by-File Repository Blueprint
+
+List the exact directories and files to create or modify.
+
+## 5. Runtime Flow
+
+Describe the runtime path from request initiation to final output.
+
+## 6. New Root Files
+
+State:
+
+- file path
+- owner
+- purpose
+- dependencies
+
+## 7. New Service Files
+
+State:
+
+- file path
+- owner
+- purpose
+- dependencies
+
+## 8. Mission, Artifact, and Persistence Plan
+
+Define:
+
+- mission objects
+- artifact objects
+- where they persist
+- who owns them
+
+## 9. Adapter Plan
+
+Describe the domain adapter strategy and rollout order.
+
+## 10. Governance Plan
+
+Describe where policy enforcement lives and what it controls.
+
+## 11. Testing and Operationalization Plan
+
+Describe the required tests and rollout gates.
+
+## 12. Build Order
+
+State the implementation order with dependency rationale.
+
+## 13. Non-Negotiables
+
+List architecture decisions that must not be broken.
+
+## 14. Bottom Line
+
+Summarize the implementation truth.

.Agent Context/Sprint 1/Templates/06 - Execution Backlog Template.md

@@ -0,0 +1,48 @@
+# Execution Backlog_ Acceptance Ownership Sales Readiness
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Delivery program or workstream group]  
+**Purpose:** Translate the implementation blueprint into a sequenced backlog with acceptance gates, ownership, and sales-readiness checks.
+
+## 1. Purpose
+
+State what the backlog is governing.
+
+## 2. Delivery Principles
+
+List the principles that govern execution.
+
+## 3. Workstream Backlog
+
+For each workstream, include:
+
+- objective
+- tasks
+- definition of done
+
+## 4. Acceptance Gates
+
+Define the gates that must pass in sequence.
+
+## 5. Ownership Model
+
+Map workstreams to accountable owners.
+
+## 6. Sales Readiness Criteria
+
+Define what has to be true for this work to support demos or sales conversations.
+
+## 7. Risks
+
+List delivery, technical, and operational risks.
+
+## 8. Immediate Next Actions
+
+List the first concrete tasks to start now.
+
+## 9. Bottom Line
+
+Summarize the delivery program in plain terms.

.Agent Context/Sprint 1/Templates/07 - Mission Contracts and JSON Schemas Template.md

@@ -0,0 +1,62 @@
+# Mission Contracts and JSON Schemas Blueprint
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Mission family or contract layer]  
+**Purpose:** Define the internal artifact contracts, schema boundaries, versioning rules, and validation strategy.
+
+## 1. Purpose
+
+State what contract system is being defined.
+
+## 2. Contract Design Principles
+
+Describe the rules governing schema design.
+
+## 3. Canonical Artifact Set
+
+List every artifact that exists in this runtime.
+
+## 4. Schema Rules
+
+Define:
+
+- required metadata
+- versioning model
+- identity keys
+- producer and consumer rules
+
+## 5. Artifact Definitions
+
+For each artifact, include:
+
+- purpose
+- required fields
+- example JSON shape
+- validation rules
+
+## 6. Storage Mapping
+
+Map artifacts to tables, files, or services.
+
+## 7. Validation Strategy
+
+State how validation happens in:
+
+- service layer
+- root layer
+- persistence layer
+
+## 8. Compatibility Strategy
+
+Define how future schema evolution will be handled.
+
+## 9. Implementation Order
+
+State the correct order for introducing the contracts.
+
+## 10. Bottom Line
+
+Summarize the contract spine.

.Agent Context/Sprint 1/Templates/08 - Adapter Detailed Implementation Spec Template.md

@@ -0,0 +1,72 @@
+# [Domain Name] Adapter Detailed Implementation Spec
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Oracle | CRM | Catalyst | Sentinel | Other]  
+**Purpose:** Define the exact adapter behavior, request and response contracts, file placements, runtime flow, and acceptance criteria for the target domain.
+
+## 1. Purpose
+
+State what this adapter exists to translate.
+
+## 2. Adapter Strategy
+
+Describe:
+
+- why this adapter exists
+- why this domain is in scope now
+- what the adapter must not try to own
+
+## 3. Mission Type
+
+State the mission types supported by the adapter.
+
+## 4. Entry Points
+
+List:
+
+- routes
+- UI actions
+- service triggers
+
+## 5. Context Inputs
+
+List every input the adapter requires.
+
+## 6. File Placement
+
+State all Python and TypeScript files to create or modify.
+
+## 7. Mission Creation Flow
+
+Describe the exact step-by-step runtime flow.
+
+## 8. Output Contract
+
+Describe:
+
+- final answer payload
+- artifacts returned
+- writeback proposal shape
+
+## 9. Writeback Rules
+
+State what may be proposed and what approval is required.
+
+## 10. Acceptance Criteria
+
+Define the adapter completion gate.
+
+## 11. Tests
+
+List required unit, integration, and replay tests.
+
+## 12. Demo and Sales Relevance
+
+State why this adapter matters to the product and to demos.
+
+## 13. Bottom Line
+
+Summarize the adapter contract.

.Agent Context/Sprint 1/Templates/09 - Colony Database Schema and Root API Spec Template.md

@@ -0,0 +1,98 @@
+# Colony Database Schema and Root API Spec
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Mission store, root API, approval flow, or related boundary]  
+**Purpose:** Define the database schema, root repository behavior, and API surface required for the target system.
+
+## 1. Purpose
+
+State what persistence and API layer is being defined.
+
+## 2. Design Principles
+
+Define the persistence and root-ownership rules.
+
+## 3. Schema Files
+
+List the SQL files or migration units to create.
+
+## 4. Required Tables
+
+List the canonical tables needed.
+
+## 5. Detailed Table Plan
+
+For each table, include:
+
+- purpose
+- recommended columns
+- indexes
+- lifecycle notes
+
+## 6. Root Modules
+
+List:
+
+- repository module
+- gateway module
+- policy bridge
+- route module
+
+## 7. Root API Surface
+
+For each endpoint, include:
+
+- route
+- method
+- purpose
+- request shape
+- response shape
+- access control
+
+## 8. Lifecycle States
+
+Define status fields and valid transitions.
+
+## 9. Writeback Release Flow
+
+Define proposal, approval, execution, and audit sequence.
+
+## 10. Repository Contract
+
+List the required repository methods.
+
+## 11. Query Shapes
+
+Define:
+
+- summary query
+- artifact query
+- replay query
+- operator inbox query
+
+## 12. Concurrency and Idempotency Rules
+
+State retry, duplicate request, and conflict behavior.
+
+## 13. Security and Access Control
+
+Define auth, scope, redaction, and approval rules.
+
+## 14. Migration and Rollout Plan
+
+Define rollout order and enablement sequence.
+
+## 15. Acceptance Criteria
+
+Define the root-layer completion gate.
+
+## 16. Ticket Breakdown
+
+List the minimum tickets required to build this layer.
+
+## 17. Bottom Line
+
+Summarize the persistence and root API truth.

.Agent Context/Sprint 1/Templates/10 - TypeScript Colony Service Internal Module Spec Template.md

@@ -0,0 +1,124 @@
+# TypeScript Colony Service Internal Module Spec
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Internal service runtime boundary]  
+**Purpose:** Define the internal module architecture, interfaces, sequencing, and operational behavior of the TypeScript service.
+
+## 1. Purpose
+
+State what internal runtime is being described.
+
+## 2. Service Boundary
+
+Describe:
+
+- what this service owns
+- what it does not own
+- how it relates to the root
+
+## 3. Top-Level Service Tree
+
+Define the required folders and files.
+
+## 4. Core Runtime Modules
+
+For each core file, include:
+
+- purpose
+- responsibilities
+- dependencies
+
+## 5. Contract Modules
+
+List the required contract files and what each exports.
+
+## 6. Planner Modules
+
+Describe the planner-related internal modules.
+
+## 7. Prompt Master Modules
+
+Describe the prompt-generation-related internal modules.
+
+## 8. Librarian Modules
+
+Describe the internal routing modules.
+
+## 9. Researcher Modules
+
+Describe the external research modules.
+
+## 10. Worker Modules
+
+Describe worker construction and execution modules.
+
+## 11. Aggregation Modules
+
+Describe evidence aggregation modules.
+
+## 12. Review Modules
+
+Describe review, release, and gating modules.
+
+## 13. Policy Modules
+
+Describe risk, tool, model, and writeback policy modules.
+
+## 14. Adapter Modules
+
+Describe how domain adapters attach to the service.
+
+## 15. Persistence Modules
+
+Describe service-side persistence facades.
+
+## 16. Telemetry Modules
+
+Describe logs, traces, and metrics modules.
+
+## 17. Required Internal Routes
+
+State the minimum internal HTTP surface.
+
+## 18. Mission Execution Sequence
+
+Describe the fixed execution sequence.
+
+## 19. Failure Handling Rules
+
+Describe error propagation and preservation of artifacts.
+
+## 20. Required Interfaces
+
+Define the service-facing TypeScript interfaces.
+
+## 21. Dependency Rules
+
+State allowed and forbidden module dependencies.
+
+## 22. Runtime Safeguards
+
+Define concurrency, timeout, and cancellation rules.
+
+## 23. Provider Abstraction Rules
+
+Define vendor or provider seams.
+
+## 24. Testing Matrix
+
+List required unit and integration suites.
+
+## 25. Implementation Order
+
+State the correct build order inside the service.
+
+## 26. Ticket-Grade Deliverables
+
+List the minimum implementation tickets.
+
+## 27. Bottom Line
+
+Summarize the internal module truth.

.Agent Context/Sprint 1/Templates/11 - Prompt Master Librarian Researcher Role Spec Template.md

@@ -0,0 +1,66 @@
+# Prompt Master, Librarian, and Researcher Role Spec
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Role system or context-routing layer]  
+**Purpose:** Define the behavior, interfaces, and quality controls for the prompt master, librarian, and researcher roles.
+
+## 1. Purpose
+
+State why these roles need an explicit operating contract.
+
+## 2. Why These Roles Matter
+
+Explain the leverage these roles have on downstream execution quality.
+
+## 3. Prompt Master
+
+For the prompt master, define:
+
+- purpose
+- inputs
+- outputs
+- required behavior
+- forbidden behavior
+- acceptance criteria
+
+## 4. Librarian
+
+For the librarian, define:
+
+- purpose
+- inputs
+- outputs
+- pass shape
+- required behavior
+- forbidden behavior
+- acceptance criteria
+
+## 5. Researcher
+
+For the researcher, define:
+
+- purpose
+- inputs
+- outputs
+- required behavior
+- forbidden behavior
+- acceptance criteria
+
+## 6. Handshake Contract
+
+Describe the fixed handoff order and required packets before worker launch.
+
+## 7. Operational Metrics
+
+List the role-quality metrics to track.
+
+## 8. Ticket Breakdown
+
+List the minimum tickets required to implement these roles.
+
+## 9. Bottom Line
+
+Summarize the role contract.

.Agent Context/Sprint 1/Templates/12 - Deployment Operations and Release Readiness Template.md

@@ -0,0 +1,71 @@
+# Deployment, Operations, and Release Readiness Spec
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Deployment boundary, release phase, or operating model]  
+**Purpose:** Define how the target system is deployed, operated, observed, released, and judged ready for demos or early sales use.
+
+## 1. Purpose
+
+State why this deployment and release plan exists.
+
+## 2. Deployment Topology
+
+Describe:
+
+- public entrypoint
+- internal service layout
+- persistence authority
+- governance boundary
+
+## 3. Environment Contract
+
+List required environment values by service.
+
+## 4. Release Environments
+
+Describe local, staging, and production expectations.
+
+## 5. Observability Requirements
+
+Define:
+
+- logs
+- metrics
+- traces
+- dashboards
+
+## 6. Release Gates
+
+Define the gates for:
+
+- technical integrity
+- governance integrity
+- operational integrity
+- sales integrity
+
+## 7. Failure Runbooks
+
+List the failure modes and expected operator response.
+
+## 8. Rollout Strategy
+
+Describe the enablement sequence.
+
+## 9. Sales Readiness Criteria
+
+Define the minimum conditions for demo-safe or sellable operation.
+
+## 10. Ownership Model
+
+Assign root, service, policy, and product ownership.
+
+## 11. Ticket Breakdown
+
+List the minimum implementation and operations tickets.
+
+## 12. Bottom Line
+
+Summarize the release truth.

.Agent Context/Sprint 1/Templates/13 - Implementation Ticket Breakdown and Dependency Matrix Template.md

@@ -0,0 +1,42 @@
+# Implementation Ticket Breakdown and Dependency Matrix
+
+**Date:** [YYYY-MM-DD]  
+**Status:** [Draft | In Review | Approved]  
+**Owner:** [Name]  
+**Reviewers:** [Names]  
+**Scope:** [Program slice, release train, or subsystem]  
+**Purpose:** Convert the architecture into an execution-ready ticket graph with dependencies, gating logic, and safe parallelization boundaries.
+
+## 1. Purpose
+
+State what build program this ticket matrix governs.
+
+## 2. Dependency Rules
+
+Define the implementation layers in order.
+
+## 3. Ticket Matrix
+
+For each ticket, include:
+
+- ticket ID
+- scope
+- depends on
+- blocks
+- owner
+
+## 4. Parallelization Guidance
+
+State what can safely run in parallel and what must not.
+
+## 5. Acceptance Gates by Ticket Group
+
+Define the major delivery gates and the tickets they require.
+
+## 6. Suggested Ownership Split
+
+Describe the recommended team ownership model.
+
+## 7. Bottom Line
+
+Summarize the sequencing truth.