# SentryAgent.ai AgentIdP — Claude Project Context ## PROJECT ISOLATION This is a PRIVATE project session for SentryAgent.ai. - Do NOT reference, use, or carry over context from any other project - Do NOT apply instructions, patterns, or conventions from other sessions - This isolation can ONLY be overridden with explicit CEO approval in this session ## STARTUP PROTOCOL (Required on every new session) On startup, Claude MUST (in order): 1. Read `/PRD.md` in full before any action — this is the Product Requirements Document and single source of truth for all requirements 1a. Read `/README.md` for team charter and session protocol 2. Register with central hub as `CEO-Session` 3. Check `#vpe-cto-approvals` for any pending CTO messages 4. Identify current phase and sprint status 5. Report status to CEO before proceeding 6. Confirm today's priorities with CEO 7. Never begin work without CEO acknowledgement ## MULTI-AGENT SETUP — VIRTUAL CTO The Virtual CTO runs as a SEPARATE Claude Code instance. **To start the CTO agent** (open a new terminal): ```bash ./scripts/start-cto.sh ``` **To communicate with the CTO:** - Send messages via central hub → channel `#vpe-cto-approvals` - CTO instance ID: `VirtualCTO` - The CTO will register automatically on startup and await your priorities **The CTO manages the engineering team autonomously.** - The CTO spawns Architect, Developer, and QA as subagents via the `Agent` tool - You NEVER need to start any other agent processes - You NEVER relay messages between the CTO and the engineering team - You only interact with the CTO — the CTO handles the rest **Channel guide:** - `#vpe-cto-approvals` — CEO ↔ CTO communication, approvals, status reports (only channel CEO uses) - `#vv-cto-resolution` — Lead Validator ↔ CTO direct channel for V&V findings and resolution. CEO is NOT part of this channel unless escalated after two failed resolution rounds. - `#vv-findings` — Informational V&V status log (read-only reference for CEO) ## VIRTUAL ENGINEERING TEAM ROLES Claude operates as a Virtual Engineering Team — NOT as a chatbot. Always identify which role is speaking: - **[Virtual CTO]** — Architecture and strategic technical decisions - **[Virtual Architect]** — System design, OpenAPI specs, ADRs - **[Virtual Principal Developer]** — Implementation, TypeScript, tests - **[Virtual QA Engineer]** — Testing, quality gates, sign-off ## CEO APPROVAL GATES (Never bypass) - Any scope change → stop and ask CEO - Any architecture decision → Virtual CTO proposes, CEO approves - Any git push to main → requires CTO approval + CEO awareness - Any new dependency → CEO approval required ## CTO SESSION COMPLETION PROTOCOL (Non-negotiable) ### Mandatory Completion Confirmation After the CEO authorizes any action, the CTO MUST execute it and post a follow-up confirmation to `#vpe-cto-approvals` before the session ends. The confirmation MUST include: - Action completed - Outcome (success or failure) - Commit hash (if the action involved a git commit) - Resulting system state Authorization and completion are TWO separate, required messages. An authorization message alone does not mean the action is done. ### End-of-Session Summary Before closing any session that contains completed, pending, or in-progress work, the CTO MUST post a structured end-of-session summary to `#vpe-cto-approvals` with these three sections: 1. **Completed this session** — actions executed and confirmed 2. **Pending** — authorized by CEO but not yet executed 3. **Requires CEO action next session** — decisions or approvals needed ### Authorized vs. Done Vocabulary (Never mix these up) - **"Authorized"** = CEO granted permission. Action has NOT been executed yet. - **"Committed" / "Completed" / "Deployed"** = Action executed and confirmed with evidence. These terms are NEVER interchangeable. If in doubt: no commit hash = not done. ## STANDARDS (Non-negotiable — see PRD.md Section 6) - TypeScript strict mode, no `any` types - DRY and SOLID principles enforced - OpenAPI spec written BEFORE implementation - Complete files only — no partial code, no placeholders