agent-enderun 1.1.1 → 1.1.3

package/.enderun/knowledge/context_boundary_rules.md

@@ -1,57 +0,0 @@
-# Context Boundaries & Constitution Caching Standard
-
-> **Trace ID:** 01HGT8J5E2N0W0W0W0W0W0W0W4  
-> **Status:** ACTIVE  
-> **Applicability:** All Agent Enderun Framework Components and Subagents
-
----
-
-## 🏛️ 1. Overview & Core Philosophy
-
-In large-scale enterprise projects, keeping the AI's context window clean and lightweight is critical. Overloading the context with unnecessary files (like bulk package lockfiles, build artifacts, or duplicated rule documents) wastes tokens, slows down execution, and dilutes the AI's attention.
-
-This standard establishes:
-1. **The Constitution Caching Rule:** Reading `.enderun/ENDERUN.md` is strictly optimized.
-2. **File & Folder Read Boundaries:** Defines allowed vs. ignored paths to protect context integrity.
-3. **Search-Before-Reading Discipline:** Mandatory search heuristics.
-
----
-
-## 🔒 2. The Constitution Caching Rule (Initial Read Only)
-
-To prevent severe token-bloat and redundant file I/O operations, the supreme constitution (`.enderun/ENDERUN.md`) must be loaded efficiently:
-
-- **The Initial Read Mandate:** The AI agent must read `{{FRAMEWORK_DIR}}/ENDERUN.md` **exactly once** at the very beginning of the session (during initial bootstrap/startup). This loads all rules into the active system/warm context.
-- **The Read Prohibition:** For all subsequent turns, tasks, and file modifications in that session, the AI agent **is strictly prohibited from calling `read_file` on `ENDERUN.md` again**.
-- **Memory Graph Cache:** The CLI/MCP runtime maintains a session flag (`CONSTITUTION_LOADED: true`) in `{{FRAMEWORK_DIR}}/memory-graph/` to signal that the rules are already active in the warm prompt, rendering repeated reads unnecessary.
-
----
-
-## 🚫 3. Path-Based Read Boundaries
-
-To prevent token waste, agents must strictly ignore the following directories and files during read/analysis operations. Here, `{{FRAMEWORK_DIR}}` is dynamically resolved at runtime to whichever folder the framework is initialized in (e.g., `.enderun`, `.gemini`, `.claude`, or `.agent`).
-
-### ❌ Ignored Paths (Strictly Prohibited for AI Read)
-* **`node_modules/`** — Massive dependency tree. Absolutely out of bounds.
-* **`dist/`, `build/`, `out/`** — Transpiled/compiled production bundles.
-* **`.git/`** — Version control internal database files.
-* **`package-lock.json`** — Extremely large lockfile (can easily exceed 150KB+). Reading this is forbidden unless explicitly diagnosing a deep dependency lock drift.
-* **`.DS_Store`, `.vscode/`, `.idea/`** — OS and IDE-specific metadata.
-* **`{{FRAMEWORK_DIR}}/logs/`** — Historical execution logs (except the active agent's own log file during write-updates).
-
-### 🟢 Allowed Paths (Active Context Space)
-* **`{{BACKEND_DIR}}/src/`** and **`{{FRONTEND_DIR}}/src/`** — Active user code.
-* **`{{DOCS_DIR}}/`** — Project architecture, guides, and requirements.
-* **`package.json`** — Workspace configurations and script references.
-* **`panda.config.ts`, `tsconfig.json`, `eslint.config.js`** — Design and compiler options.
-* **`{{FRAMEWORK_DIR}}/STATUS.md` & `{{FRAMEWORK_DIR}}/PROJECT_MEMORY.md`** — Live status and SSOT.
-* **`{{FRAMEWORK_DIR}}/agents/{active_agent}.md`** — The active agent instruction prompt.
-
----
-
-## 🕵️ 4. Search-Before-Reading Protocol
-
-To ensure minimal and clean context usage:
-- **Rule:** Never open or read a file blindly.
-- **Heuristic:** Use `search_codebase` or `grep_search` to identify exact matches, line numbers, or specific functions first.
-- **Action:** Read *only* the specific lines or narrow ranges of target files instead of reading large, full-length files by default.

package/.enderun/knowledge/corporate-governance/analyst-contract-integrity-guide.md

@@ -1,92 +0,0 @@
-# Contract Integrity & Governance Compliance Verification Guide (@analyst)
-
-**Role**: @analyst is the independent verifier of governance and contract health in corporate projects.
-
-**Goal**: Provide clear, actionable rules and processes for maintaining contract integrity and enforcing corporate governance standards.
-
----
-
-## 1. Core Responsibilities
-
-- Detect contract drift between `apps/backend/src/types` and frontend copies.
-- Verify that high-risk endpoints properly implement `managerApproval` validation.
-- Ensure audit logging is present for all privileged operations.
-- Confirm that typed Domain Errors are used instead of generic errors.
-- Validate that Branded Types are correctly applied in public APIs and services.
-
----
-
-## 2. Mandatory Checks on Every Relevant Change
-
-### Contract Changes
-- Run diff between backend types and all frontend copies.
-- Verify `contract.version.json` was updated (MINOR for additive, MAJOR for breaking).
-- Confirm that @backend sent a Hermes notification before implementation.
-
-### High-Risk Endpoints
-- Every new or modified privileged endpoint must:
-  - Require `isHighRiskAdminAction: true`
-  - Require valid `managerApproval` structure
-  - Throw `HighRiskActionRequiresApprovalError` on failure
-  - Create an audit log entry
-
-### Error Handling
-- No raw `throw new Error(...)` in business logic.
-- All domain errors must extend `DomainError`.
-- Error responses must not leak internal details.
-
----
-
-## 3. Automated & Manual Verification Process
-
-**Automated (recommended)**:
-- Static analysis for branded type usage.
-- Contract hash comparison script between backend and frontend.
-
-**Manual (every sprint or major feature)**:
-- Review all new high-risk endpoints.
-- Sample audit logs for privileged actions.
-- Check that governance decisions are documented in `docs/architecture/decisions/`.
-
----
-
-## 4. Escalation Rules
-
-When violations are found:
-1. Immediately notify @manager via Hermes.
-2. Provide clear evidence (file paths, code snippets, missing fields).
-3. Recommend specific corrective actions.
-4. Do not approve feature completion until issues are resolved.
-
-**@analyst has authority to block merge** on governance or contract violations in corporate projects.
-
----
-
-## 5. Reference Knowledge Files (Must Read)
-
-- `branded-types-law.md`
-- `high-risk-actions-managerapproval.md`
-- `domain-error-handling-standard.md`
-- `audit-logging-standard.md`
-- `corporate-project-scaffolding-sop.md`
-- `contract-drift-detection-simulation.md`
-
----
-
-## 6. Reporting Template
-
-When reporting an issue to @manager, use this structure:
-
-```
-Contract/Governance Issue Report
-
-Trace ID: ...
-Severity: High / Medium / Low
-Affected Area: ...
-Violation: ...
-Evidence: ...
-Recommended Fix: ...
-Impact if not fixed: ...
-```
-
-This ensures consistent, professional communication.

package/.enderun/knowledge/corporate-governance/audit-logging-standard.md

@@ -1,59 +0,0 @@
-# Audit Logging Standard
-
-**Applies to**: All privileged, high-risk, or compliance-relevant operations in enterprise projects using Agent Enderun.
-
-## Purpose
-Every significant administrative or security-relevant action must leave a tamper-evident, queryable audit trail. This is a non-negotiable requirement for corporate and regulated environments.
-
-## Core Requirements
-
-1. **What Must Be Logged**
-   - All high-risk administrative actions (role changes, configuration modifications, bulk operations, data exports).
-   - Authentication and authorization events (login, token issuance, permission checks).
-   - Any action performed using a `managerApproval` token.
-   - Failed attempts to perform privileged operations.
-
-2. **Minimum Information per Log Entry**
-   - Timestamp (ISO-8601, UTC)
-   - Trace ID (linked to the originating Hermes trace when applicable)
-   - Actor (UserID of the person or system performing the action)
-   - Action type (e.g., `USER_ROLE_ELEVATED`, `SYSTEM_CONFIG_UPDATED`)
-   - Target resource (e.g., affected UserID or configuration key)
-   - Before and after state (when relevant and not containing secrets)
-   - `managerApproval` details (approvalId, reason, approver) if the action was high-risk
-   - Outcome (success / failure + error code if applicable)
-
-3. **Storage and Integrity**
-   - Audit logs must be stored separately from operational data when possible.
-   - Logs must be append-only. Updates or deletions of existing log entries are forbidden.
-   - In production systems, logs should be shipped to a tamper-resistant store (e.g., dedicated database table with row-level security, or external logging service).
-
-4. **Access Control**
-   - Reading full audit logs is itself a high-risk operation and must follow the `managerApproval` process.
-   - Regular users should never have direct access to raw audit logs.
-
-## Implementation Guidelines for @backend
-
-- Create a dedicated `AuditLog` domain entity and repository.
-- Use a structured logging approach (never unstructured strings for critical fields).
-- Every high-risk service method must create an audit entry as part of the same transaction (or as a guaranteed side effect).
-- Never log sensitive data (passwords, tokens, PII) in plaintext.
-
-## Implementation Guidelines for @frontend
-
-- Administrative UIs that trigger high-risk actions must clearly indicate that the action will be audited.
-- Audit log viewing interfaces (when built) must themselves be protected by the high-risk approval flow.
-
-## Relationship to Other Standards
-
-- Works together with the `ManagerApproval` pattern: every approved high-risk action must produce a corresponding audit entry that references the `approvalId`.
-- Supports the Branded Types Law: `ActorID`, `TargetID`, and `ApprovalID` in audit records must be properly branded types.
-
-## Anti-Patterns
-
-- Logging only to console or ephemeral files in production.
-- Making audit logs mutable.
-- Skipping audit entries for “internal” or “trusted” admin users.
-- Storing audit data in the same tables as operational data without clear separation.
-
-This standard is mandatory for any project that claims enterprise or regulated status under Agent Enderun.

package/.enderun/knowledge/corporate-governance/backend-high-risk-endpoint-guide.md

@@ -1,125 +0,0 @@
-# High-Risk Endpoint Implementation Guide (@backend)
-
-**Applies to**: Any backend endpoint that performs privileged or high-risk administrative actions.
-
-**Goal**: Provide @backend with a concrete, production-grade implementation pattern that strictly enforces corporate governance.
-
----
-
-## 1. Required Imports and Types
-
-```ts
-import { 
-  UserID, 
-  RoleID, 
-  ManagerApproval, 
-  HighRiskActionPayload 
-} from '../types';
-import { HighRiskActionRequiresApprovalError } from '../types/errors';
-import { auditLogRepository } from '../repositories/audit-log.repository';
-```
-
----
-
-## 2. High-Risk Endpoint Pattern (Recommended Structure)
-
-```ts
-// apps/backend/src/routes/users/promote-to-superadmin.route.ts
-
-interface PromoteToSuperAdminBody extends HighRiskActionPayload {
-  userId: UserID;
-  newRole: 'SuperAdmin';
-}
-
-fastify.post('/api/v1/users/:id/promote-to-superadmin', async (request, reply) => {
-  const { id } = request.params;
-  const body = request.body as PromoteToSuperAdminBody;
-
-  // === MANDATORY HIGH-RISK GOVERNANCE CHECK ===
-  if (!body.isHighRiskAdminAction || !body.managerApproval) {
-    throw new HighRiskActionRequiresApprovalError(
-      'Promotion to SuperAdmin is a high-risk action',
-      { requiredFields: ['isHighRiskAdminAction', 'managerApproval'] }
-    );
-  }
-
-  // Validate managerApproval structure
-  const approval = body.managerApproval;
-  if (approval.approvedBy !== 'manager') {
-    throw new HighRiskActionRequiresApprovalError('Approval must be issued by @manager');
-  }
-
-  // Optional: Add time-based or policy-based validation here
-  // (e.g., approval must be less than 15 minutes old)
-
-  const targetUserId = id as UserID;
-
-  // === EXECUTE THE PRIVILEGED ACTION ===
-  const updatedUser = await userService.promoteToSuperAdmin(targetUserId);
-
-  // === AUDIT LOGGING (MANDATORY) ===
-  await auditLogRepository.create({
-    traceId: approval.traceId,
-    actorId: request.user.id as UserID,           // the person who triggered the action
-    action: 'USER_PROMOTED_TO_SUPERADMIN',
-    targetId: targetUserId,
-    beforeState: { role: updatedUser.previousRole },
-    afterState: { role: 'SuperAdmin' },
-    managerApprovalId: approval.approvalId,
-    reason: approval.reason,
-  });
-
-  return {
-    success: true,
-    user: updatedUser,
-    approvalUsed: approval.approvalId,
-  };
-});
-```
-
----
-
-## 3. Error Handling
-
-Always throw typed domain errors:
-
-- Use `HighRiskActionRequiresApprovalError` when governance requirements are not met.
-- Never return generic 403 or 400 with vague messages.
-
----
-
-## 4. Testing Requirements (Testable Rules)
-
-Every high-risk endpoint **must** have the following test cases:
-
-- [ ] Request without `isHighRiskAdminAction` → `HighRiskActionRequiresApprovalError`
-- [ ] Request without `managerApproval` → `HighRiskActionRequiresApprovalError`
-- [ ] `managerApproval.approvedBy !== 'manager'` → `HighRiskActionRequiresApprovalError`
-- [ ] Valid approval token → Action succeeds + audit log is created
-- [ ] Valid approval but action fails later → Audit log still created with failure status (if possible)
-
----
-
-## 5. Anti-Patterns (Strictly Forbidden)
-
-- Bypassing validation “because the frontend already checked”
-- Logging the full `managerApproval.signature` in normal logs
-- Skipping audit logging for “internal admin users”
-- Using plain `string` for `userId` or `approvalId` inside the endpoint
-- Returning raw error objects to the client
-
----
-
-## 6. Integration Points
-
-This pattern must be combined with:
-- `domain-error-handling-standard.md`
-- `audit-logging-standard.md`
-- `branded-types-law.md`
-
-@backend is responsible for refusing to implement any high-risk feature until the above three standards are satisfied in the design.
-
-**Reference files** (must be read before implementation):
-- `high-risk-actions-managerapproval.md`
-- `high-risk-action-approval-flow-simulation.md`
-- `corporate-project-scaffolding-sop.md`

package/.enderun/knowledge/corporate-governance/branded-types-law.md

@@ -1,77 +0,0 @@
-# Branded Types Law
-
-**Status:** Mandatory — Zero Tolerance
-
-## Why This Exists
-Plain `string` or `number` for identifiers (user IDs, role IDs, approval tokens, etc.) is a major source of bugs and security issues in large systems. Agent Enderun enforces **Branded Types** to make domain identifiers type-safe at compile time.
-
-## Definition
-```ts
-type Brand<T, BrandName extends string> = T & { readonly __brand: BrandName };
-
-type UserID = Brand<string, 'UserID'>;
-type RoleID = Brand<string, 'RoleID'>;
-type ApprovalID = Brand<string, 'ApprovalID'>;
-```
-
-## Rules
-1. Every identifier that represents a domain entity **must** be a branded type.
-2. Backend is the source of truth (`apps/backend/src/types`).
-3. Frontend must maintain an exact local copy and update it when notified via Hermes.
-4. Never cast `as any` or use `string` directly when a branded type is available.
-5. Database columns can remain as strings, but the TypeScript layer must brand them immediately after reading.
-
-## Enforcement
-- @backend must refuse to implement any feature that introduces non-branded IDs.
-- @analyst will run static analysis to detect violations.
-- Any PR that introduces plain strings for IDs must be rejected.
-
-## Example Correct Usage
-```ts
-const promoteUser = async (userId: UserID, newRole: SystemRole, approval: ManagerApproval) => { ... }
-```
-
-## Recommended Folder Structure
-
-```
-apps/backend/src/types/
-├── brand.ts                 # Generic Brand utility
-├── identifiers.ts           # UserID, RoleID, ApprovalID, TraceID...
-├── approval.ts              # ManagerApproval + HighRiskActionPayload
-├── errors.ts                # DomainError hierarchy
-├── user.ts
-├── role.ts
-└── index.ts                 # Re-exports
-```
-
-## Concrete Implementation Examples
-
-**brand.ts**
-```ts
-export type Brand<T, BrandName extends string> = T & { readonly __brand: BrandName };
-```
-
-**identifiers.ts**
-```ts
-import { Brand } from './brand';
-
-export type UserID = Brand<string, 'UserID'>;
-export type RoleID = Brand<string, 'RoleID'>;
-export type ApprovalID = Brand<string, 'ApprovalID'>;
-export type TraceID = Brand<string, 'TraceID'>;
-```
-
-## Common Anti-Patterns (Forbidden)
-- `userId: string`
-- `roleId: number`
-- Passing raw database rows directly to the frontend without branding
-- Using `as any` to bypass branded type checks
-- Casting database IDs directly without branding at the repository layer
-
-## Testable Rules (for @analyst)
-
-- Static analysis must fail on any non-branded identifier used in public APIs or service methods.
-- All identifiers in `apps/backend/src/types` must extend the `Brand` utility.
-- Frontend type copies must match backend branded types exactly (contract drift detection).
-
-This law is non-negotiable for any project using Agent Enderun at enterprise scale.

package/.enderun/knowledge/corporate-governance/contract-drift-detection-simulation.md

@@ -1,92 +0,0 @@
-# Contract Drift Detection & Resolution Simulation
-
-**Purpose**: This simulation shows how @analyst, @backend, @frontend, and @manager should handle a contract drift situation in a corporate project according to Agent Enderun standards.
-
-**Scenario**: During development of the User Management module, @backend adds a new required field `lastLoginAt` to the `User` type without notifying the team.
-
----
-
-## Step 1 – Drift is Detected
-
-**@analyst** runs the contract integrity check (as per its responsibilities in the Corporate Project Scaffolding SOP).
-
-**Detection**:
-- `apps/backend/src/types/user.ts` has changed.
-- `apps/web/src/types/api-contracts.ts` (frontend copy) does not contain the new field.
-- Hash in `contract.version.json` has not been updated.
-
-**@analyst** sends a Hermes message to @manager and @frontend:
-
-```json
-{
-  "type": "contract_drift_detected",
-  "traceId": "TRACE-20260525-CONTRACT-DRIFT-007",
-  "payload": {
-    "changedFile": "apps/backend/src/types/user.ts",
-    "newField": "lastLoginAt: string",
-    "frontendCopyStatus": "outdated",
-    "severity": "high"
-  }
-}
-```
-
----
-
-## Step 2 – @manager Assessment
-
-**@manager** receives the notification and loads:
-- `branded-types-law.md`
-- `corporate-project-scaffolding-sop.md`
-
-**@manager response**:
-
-This is a contract drift. Per our governance rules, no one may continue implementation on the affected feature until the drift is resolved.
-
-**Immediate actions**:
-1. @backend must pause any work depending on the new field.
-2. @frontend must be briefed to update the local type copy.
-3. @analyst will verify the fix and update the contract version.
-
-I am now issuing a formal pause on the User detail feature until resolution.
-
----
-
-## Step 3 – Resolution Process
-
-**@backend** (after receiving the briefing):
-
-Understood. I will not merge or continue work using the new field until the contract is synchronized.
-
-**@frontend**:
-
-I have updated `apps/web/src/types/api-contracts.ts` to include `lastLoginAt`.
-
-**@analyst**:
-
-- Verified that both backend and frontend types now match.
-- Updated `contract.version.json` (MINOR version bump).
-- Confirmed no other files are affected.
-
-**@manager** (final resolution message):
-
-Contract drift resolved.
-
-- Backend and frontend types are now in sync.
-- Contract version updated.
-- Feature development on the affected area may resume.
-
-All future type changes must follow the Hermes notification process defined in the Scaffolding SOP.
-
----
-
-## Lessons from This Simulation
-
-- Contract drift is treated as a serious governance issue.
-- @analyst has real authority to pause work.
-- @manager uses the standards to protect the project from technical debt.
-- Resolution must be documented (even if small) in PROJECT_MEMORY.md.
-
-**Reference files**:
-- `branded-types-law.md`
-- `corporate-project-scaffolding-sop.md`
-- `corporate-project-kickoff-checklist.md`

package/.enderun/knowledge/corporate-governance/corporate-governance-playbook.md

@@ -1,89 +0,0 @@
-# Corporate Governance Playbook
-
-**Version**: 1.0  
-**Purpose**: This is the single master reference that ties together all corporate governance standards for Agent Enderun. It provides navigation, summaries, and the recommended order of study for agents and teams.
-
----
-
-## Core Philosophy
-
-We do not ship pre-built applications.  
-We internalize strong governance patterns into the agents so they can guide any corporate project correctly from the first day.
-
----
-
-## Document Hierarchy
-
-### Foundational Laws & Standards
-| Document | Focus | Must Read By |
-|----------|-------|--------------|
-| `branded-types-law.md` | Compile-time safety for identifiers | All agents |
-| `high-risk-actions-managerapproval.md` | Protection of privileged operations | All agents |
-| `domain-error-handling-standard.md` | Typed, safe error system | @backend, @analyst |
-| `audit-logging-standard.md` | Tamper-evident privileged action records | @backend, @analyst, @manager |
-
-### UI & Coordination Patterns
-| Document | Focus | Must Read By |
-|----------|-------|--------------|
-| `high-risk-security-modal-hermes-flow.md` | Frontend high-risk action handling | @frontend, @manager |
-| `frontend-high-risk-modal-guide.md` | Concrete component + hook implementation | @frontend |
-
-### Backend Implementation
-| Document | Focus | Must Read By |
-|----------|-------|--------------|
-| `backend-high-risk-endpoint-guide.md` | Production-grade high-risk endpoint pattern | @backend |
-
-### Process & Scaffolding
-| Document | Focus | Must Read By |
-|----------|-------|--------------|
-| `corporate-project-scaffolding-sop.md` | Step-by-step process for new corporate projects | @manager (primary) |
-| `corporate-project-kickoff-checklist.md` | Mandatory checklist at project start | @manager + team |
-| `governance-baseline-briefing-template.md` | First-day briefing text | @manager |
-| `manager-first-three-briefings.md` | Ready templates for early project phases | @manager |
-
-### Simulations (Learning & Reference)
-| Document | Focus |
-|----------|-------|
-| `corporate-project-kickoff-simulation.md` | Full multi-session project start example |
-| `high-risk-action-approval-flow-simulation.md` | End-to-end high-risk action cycle |
-| `contract-drift-detection-simulation.md` | How to detect and resolve contract drift |
-
-### Analyst & Compliance
-| Document | Focus |
-|----------|-------|
-| `analyst-contract-integrity-guide.md` | @analyst’s verification responsibilities and processes |
-
----
-
-## Recommended Reading Order (for New Projects)
-
-1. **@manager** (before anything else)
-   - `corporate-project-scaffolding-sop.md`
-   - `corporate-project-kickoff-checklist.md`
-   - `governance-baseline-briefing-template.md`
-
-2. **All Agents**
-   - `branded-types-law.md`
-   - `high-risk-actions-managerapproval.md`
-
-3. **Specialist Agents**
-   - @backend → `backend-high-risk-endpoint-guide.md` + `domain-error-handling-standard.md`
-   - @frontend → `frontend-high-risk-modal-guide.md`
-   - @analyst → `analyst-contract-integrity-guide.md`
-
-4. **Simulations** (for deeper understanding)
-   - Start with `corporate-project-kickoff-simulation.md`
-
----
-
-## When to Reference This Playbook
-
-- At the start of every new corporate project
-- When any high-risk feature is being planned
-- During contract changes
-- When @analyst detects governance or contract issues
-- During project retrospectives
-
----
-
-**This playbook is the single source of truth for corporate governance in Agent Enderun.**

package/.enderun/knowledge/corporate-governance/corporate-project-kickoff-checklist.md

@@ -1,56 +0,0 @@
-# Corporate Project Kickoff Checklist
-
-**Owner:** @manager  
-**Audience:** Human user + all specialist agents
-
-This checklist must be completed (and documented in `PROJECT_MEMORY.md`) at the very beginning of any corporate or enterprise-grade project.
-
----
-
-## Phase 0 – Governance Alignment
-
-- [ ] @manager has read all files in `.enderun/knowledge/corporate-governance/`
-- [ ] User has been given the Governance Baseline Briefing
-- [ ] User has explicitly acknowledged the corporate standards
-- [ ] Decision recorded in `PROJECT_MEMORY.md` under "Critical Decisions"
-
-## Phase 1 – Project Structure & Contracts
-
-- [ ] `apps/backend/src/types` folder structure created
-- [ ] Branded Types utility + core identifiers defined
-- [ ] `ManagerApproval` and `HighRiskActionPayload` interfaces defined
-- [ ] `contract.version.json` initialized
-- [ ] @frontend has created matching type copies in `apps/web/src/types`
-- [ ] @analyst has been briefed on contract integrity responsibility
-
-## Phase 2 – High-Risk Governance Infrastructure (if privileged operations expected)
-
-- [ ] High-risk validation logic designed for @backend
-- [ ] Security Modal + Hermes briefing flow designed for @frontend
-- [ ] Audit logging strategy defined (see audit-logging-standard.md)
-- [ ] Domain Error hierarchy created (including `HighRiskActionRequiresApprovalError`)
-- [ ] Both @backend and @frontend agents have received explicit briefings referencing the knowledge files
-
-## Phase 3 – Tooling & Process
-
-- [ ] @analyst has confirmed contract drift detection process
-- [ ] Documentation ownership rule explained (all architecture decisions go to `docs/architecture/decisions/`)
-- [ ] First ADR (Architecture Decision Record) created for governance baseline
-- [ ] @manager has updated `PROJECT_MEMORY.md` with initial trace and active tasks
-
-## Phase 4 – Team Alignment
-
-- [ ] All active agents have loaded the latest versions of:
-  - `branded-types-law.md`
-  - `high-risk-actions-managerapproval.md`
-  - `high-risk-security-modal-hermes-flow.md`
-  - `audit-logging-standard.md`
-  - `domain-error-handling-standard.md`
-- [ ] @manager has confirmed that no specialist agent may begin implementation work until the above items are complete
-
----
-
-**@manager Note**:  
-Do not proceed to feature development until this checklist is fully completed and acknowledged by the user. Shortcuts at this stage create expensive technical debt later.
-
-Mark items as done in `PROJECT_MEMORY.md` under a dedicated "Kickoff Checklist" section.