Feat/phase2 security boundary

.specify/memory/constitution.md

@@ -0,0 +1,51 @@
+# Roo Code Project Constitution
+
+We are building an **AI-Native IDE with Intent–Code Traceability**. All specs, plans, and implementation must align with these principles.
+
+---
+
+## I. Intent–Code Traceability (Non‑negotiable)
+
+- **All agent actions must be traceable to intent IDs.** Every action taken by the AI agent must be linkable to a specific user intent.
+- The **`.orchestration/` directory is the source of truth** for intent definitions, state machine definitions, and traceability metadata. Do not bypass or duplicate it.
+- We implement the **two-stage state machine**: **(1) intent selection** → **(2) execution**. Selection and execution are distinct phases; design and code must reflect this.
+
+---
+
+## II. Hook Middleware Pattern
+
+- We follow the **hook middleware pattern** from the challenge. Agent flows and state transitions go through this pattern; do not introduce ad-hoc or parallel patterns that skip it.
+
+---
+
+## III. TypeScript & Strictness
+
+- We use **TypeScript with strict mode** enabled. No disabling strict checks without documented justification and review.
+- Follow existing patterns in the repo (React in webview-ui, extension APIs in `src/`, shared types in `packages/types`). Prefer project tooling: ESLint, Prettier, pnpm, Turbo.
+
+---
+
+## IV. Settings View & State
+
+**Source:** [AGENTS.md](../AGENTS.md)
+
+- When working on **SettingsView** (or any settings UI that edits extension state), inputs **must** bind to the local **cachedState**, NOT the live `useExtensionState()`.
+- **cachedState** is the buffer for user edits until the user explicitly clicks **Save**. Wiring inputs directly to live state causes **race conditions**. Do not do it.
+
+---
+
+## V. Testing & Documentation
+
+- New or changed behavior should be covered by tests where practical. UI/state changes must respect the Settings View pattern (cachedState → Save) and the two-stage state machine.
+- Update AGENTS.md when introducing new patterns or constraints. Keep README and contributor docs accurate.
+
+---
+
+## VI. Scope & Simplicity
+
+- Prefer small, reviewable changes. Break large features into spec/plan/tasks with clear deliverables.
+- Avoid speculative features; tie work to concrete user or product needs.
+
+---
+
+_This constitution is the source of truth for how we build and maintain Roo Code. Specs and implementation plans must reference it and must not contradict it._

.specify/specs/001-intent-orchestration/spec.md

@@ -0,0 +1,76 @@
+# Spec: Intent orchestration and intent–code traceability
+
+**Feature:** 001-intent-orchestration  
+**Status:** Draft  
+**Constitution:** [.specify/memory/constitution.md](../../memory/constitution.md)
+
+---
+
+## 1. Overview
+
+Introduce an **orchestration layer** so that every AI agent action is tied to a specific user intent. The system uses a **two-stage state machine** (intent selection → execution) and treats **`.orchestration/`** as the source of truth for intents and traceability. This enables an AI-native IDE where “why” (intent) is always traceable to “what” (code/actions).
+
+---
+
+## 2. User stories
+
+| ID   | As a…     | I want…                                                         | So that…                                                          |
+| ---- | --------- | --------------------------------------------------------------- | ----------------------------------------------------------------- |
+| US-1 | Developer | every agent action to be tied to an intent ID                   | I can trace code and edits back to the user’s intent              |
+| US-2 | Developer | intents and the state machine to live under `.orchestration/`   | there is a single source of truth for intent definitions and flow |
+| US-3 | Developer | a clear separation between “choose intent” and “execute intent” | the system is predictable and testable                            |
+| US-4 | Developer | agent flows to go through the hook middleware pattern           | behavior is consistent and extensible                             |
+
+---
+
+## 3. Functional requirements
+
+- **FR-1** Intent selection phase: the system resolves or selects the user’s intent and assigns an **intent ID** before any execution.
+- **FR-2** Execution phase: agent actions (e.g. edits, runs, tool calls) are executed only after intent selection and must carry the **intent ID** for traceability.
+- **FR-3** `.orchestration/` contains (at least):
+    - Intent definitions (e.g. IDs, names, metadata).
+    - State machine definition (states, transitions: selection → execution).
+    - Traceability metadata linking intent IDs to actions/artifacts where applicable.
+- **FR-4** All agent flows use the **hook middleware pattern**; no bypass paths that skip this pattern.
+- **FR-5** Traceability: given an intent ID, it must be possible to determine which actions or artifacts were produced for that intent (e.g. logs, state, or references).
+
+---
+
+## 4. Acceptance criteria
+
+- [ ] Intent selection and execution are implemented as distinct phases (two-stage state machine).
+- [ ] Every agent action that affects code or UX is associated with an intent ID.
+- [ ] `.orchestration/` exists and is the only source of truth for intent definitions and state machine definition.
+- [ ] Agent flows use the hook middleware pattern; no ad-hoc paths around it.
+- [ ] TypeScript strict mode remains enabled; new code follows existing repo patterns.
+- [ ] AGENTS.md (and constitution) are not violated (e.g. Settings View still uses cachedState).
+
+---
+
+## 5. Constraints (from constitution)
+
+- TypeScript strict mode required.
+- Hook middleware pattern required for agent flows.
+- `.orchestration/` is source of truth; do not duplicate or bypass.
+- Two-stage state machine: intent selection → execution only.
+
+---
+
+## 6. Out of scope for this spec
+
+- Detailed UI for “intent picker” or intent selection UX (can be a later spec).
+- Migration of all existing agent entry points in one go (can be incremental).
+- Specific storage format inside `.orchestration/` (e.g. JSON vs YAML) — to be decided in plan.
+
+---
+
+## 7. Review & acceptance checklist
+
+- [ ] No [NEEDS CLARIFICATION] markers remain.
+- [ ] Requirements are testable and unambiguous.
+- [ ] Success criteria are measurable.
+- [ ] Aligned with constitution (Articles I–VI).
+
+---
+
+_Next step: run `/speckit.clarify` to resolve ambiguities, or `/speckit.plan` to produce the technical implementation plan._

.specify/specs/001-intent-orchestration/tasks.md

@@ -0,0 +1,42 @@
+# Tasks: 001-intent-orchestration
+
+**Spec:** [spec.md](./spec.md)  
+**Constitution:** [.specify/memory/constitution.md](../../memory/constitution.md)
+
+Tasks derived from functional requirements and acceptance criteria. Implement in dependency order; 002-intent-system tasks implement the concrete tool and schema.
+
+---
+
+## 1. Orchestration foundation
+
+| ID    | Task                                                                                                                                              | Source   | Status |
+| ----- | ------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------ |
+| 001-1 | Create `.orchestration/` directory layout (e.g. `active_intents.yaml`, optional `state machine` or metadata file) and document as source of truth | FR-3, AC | ☐      |
+| 001-2 | Implement intent selection phase: resolve/select user intent and assign intent ID before any execution                                            | FR-1     | ☐      |
+| 001-3 | Implement execution phase: allow agent actions only after intent selection; ensure actions carry intent ID for traceability                       | FR-2     | ☐      |
+| 001-4 | Define state machine (states, transitions: selection → execution) and store under `.orchestration/`                                               | FR-3     | ☐      |
+| 001-5 | Ensure all agent flows use hook middleware; audit and remove any bypass paths                                                                     | FR-4, AC | ☐      |
+| 001-6 | Implement traceability: given an intent ID, determine which actions/artifacts were produced (logs, state, or references)                          | FR-5     | ☐      |
+
+---
+
+## 2. Acceptance criteria verification
+
+| ID     | Task                                                                                           | Source | Status |
+| ------ | ---------------------------------------------------------------------------------------------- | ------ | ------ |
+| 001-7  | Verify intent selection and execution are distinct phases (two-stage state machine)            | AC     | ☐      |
+| 001-8  | Verify every agent action that affects code or UX is associated with an intent ID              | AC     | ☐      |
+| 001-9  | Verify `.orchestration/` is the only source of truth for intent definitions and state machine  | AC     | ☐      |
+| 001-10 | Verify no ad-hoc paths around hook middleware                                                  | AC     | ☐      |
+| 001-11 | Confirm TypeScript strict mode and AGENTS.md (e.g. Settings View cachedState) are not violated | AC     | ☐      |
+
+---
+
+## 3. Dependencies
+
+- **002-intent-system** implements the `select_active_intent` tool, schema for `active_intents.yaml`, and gatekeeper; those tasks satisfy 001-2, 001-3, and feed 001-4, 001-5, 001-6.
+- Complete 001-1 and 002 schema/tool tasks first, then 001-2 through 001-6, then 001-7–001-11.
+
+---
+
+_Next: run tasks in 002-intent-system for concrete implementation; use this list to verify 001 acceptance criteria._