# Implementation Plan: [FEATURE]

**Branch**: `[###-feature-name]` | **Date**: [DATE] | **Spec**: [link]
**Input**: Feature specification from `/specs/[###-feature-name]/spec.md`

**Note**: This template is filled in by the `/speckit.plan` command. See `.specify/templates/plan-template.md` for the execution workflow.

## Summary

[Extract from feature spec: primary requirement + technical approach from research]

## Technical Context

<!--
  ACTION REQUIRED: Replace the content in this section with the technical details
  for the project. The structure here is presented in advisory capacity to guide
  the iteration process.
-->

**Language/Version**: Python 3.13+ (backend), TypeScript (frontend Svelte 5 runes-only)  
**Primary Dependencies**: FastAPI, SQLAlchemy, APScheduler (backend); SvelteKit 5, Vite, Tailwind CSS (frontend)  
**Storage**: PostgreSQL 16  
**Testing**: pytest (backend), vitest (L1 model tests without render + L2 UX tests with @testing-library/svelte)  
**Target Platform**: Linux server (Docker), modern browsers  
**Project Type**: web application (FastAPI REST + WebSocket backend, SvelteKit SPA frontend)  
**Frontend Architecture**: TypeScript-first, model-first (Screen Models via `.svelte.ts`), runes-only (`$state`, `$derived`, `$effect`), typed callback props (no `createEventDispatcher`)  
**Performance Goals**: [domain-specific, e.g., <200ms p95 API latency, 60fps UI]  
**Constraints**: [domain-specific, e.g., <100MB memory per container, RBAC enforcement, offline-capable Docker bundle]  
**Scale/Scope**: [domain-specific, e.g., 50 concurrent users, 1000 dashboards, 10 plugins]

## Constitution Check

*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*

[Evaluate against constitution.md and semantics.md. Explicitly confirm semantic protocol compliance, complexity-driven contract coverage, TypeScript-first frontend with typed Screen Models (`.svelte.ts`), UX-state compatibility (Svelte 5 runes-only), async boundaries (FastAPI), API-wrapper rules, RBAC/security constraints (local auth + ADFS SSO), plugin lifecycle rules, and any required belief-state/logging constraints for Complexity 4/5 Python modules.]

## Project Structure

### Documentation (this feature)

```text
specs/[###-feature]/
├── plan.md              # This file (/speckit.plan command output)
├── research.md          # Phase 0 output (/speckit.plan command)
├── data-model.md        # Phase 1 output (/speckit.plan command)
├── quickstart.md        # Phase 1 output (/speckit.plan command)
├── contracts/           # Phase 1 output (/speckit.plan command)
└── tasks.md             # Phase 2 output (/speckit.tasks command - NOT created by /speckit.plan)
```

### Source Code (repository root)

```text
# Web application (default for this repository)
backend/
├── src/
│   ├── api/               # FastAPI routes
│   ├── core/              # Core services (task_manager, auth, migration, plugins)
│   ├── models/            # SQLAlchemy ORM models
│   ├── services/          # Business logic
│   └── schemas/           # Pydantic schemas
└── tests/                 # pytest tests

frontend/
├── src/
│   ├── routes/            # SvelteKit pages
│   ├── lib/
│   │   ├── components/    # Reusable Svelte 5 components (thin rendering layer)
│   │   ├── models/        # Screen Models (.svelte.ts — typed, Svelte-reactive state machines)
│   │   ├── stores/        # Svelte stores (cross-route state: auth, notifications)
│   │   └── api/           # API client modules (fetchApi/requestApi wrappers)
│   ├── types/             # TypeScript DTOs — MUST match backend Pydantic schemas
│   └── services/          # Service layer (gitService, taskService)
└── tests/                 # vitest tests

docker/                     # Docker configurations
```

**Structure Decision**: This is a web application with separate `backend/` (Python/FastAPI) and `frontend/` (SvelteKit) directories. Docker Compose orchestrates both services plus PostgreSQL.

## Semantic Contract Guidance

> Use this section to drive Phase 1 artifacts, especially `contracts/modules.md`.

- Classify each planned module/component/model with `[C:N]` complexity in the `#region` anchor.
- Use canonical anchor syntax appropriate for each context:
  - Python: `# #region ContractId [C:N] [TYPE TypeName] [SEMANTICS tags]` / `# #endregion ContractId`
  - Svelte markup: `<!-- #region ContractId [C:N] [TYPE Component] [SEMANTICS tags] -->` / `<!-- #endregion ContractId -->`
  - Svelte/TypeScript model: `// #region ModelName [C:N] [TYPE Model] [SEMANTICS tags]` / `// #endregion ModelName`
  - Markdown/ADR: `## @{ ContractId [C:N] [TYPE TypeName]` / `## @} ContractId`
- **Legacy `[DEF:id:Type]` syntax is deprecated** — use `#region` format exclusively.
- **Model files use `.svelte.ts` extension** — canonical format for contracts with Svelte reactive primitives (`$state`, `$derived`, `$effect`).
- Match contract density to complexity:
  - C1: anchors only (DTOs, simple constants)
  - C2: typically adds `@BRIEF` (utility functions, pure helpers)
  - C3: typically adds `@RELATION`; Svelte also `@UX_STATE`; TypeScript also `@STATE`/`@ACTION`
  - C4: typically adds `@PRE`, `@POST`, `@SIDE_EFFECT`; Python also `belief_scope`/`reason`/`reflect` markers; Svelte also `@UX_FEEDBACK`, `@UX_RECOVERY`, `@UX_REACTIVITY`
  - C5: C4 + `@DATA_CONTRACT`, `@INVARIANT` + `@RATIONALE`/`@REJECTED` decision memory
- **Screen Models** (`[TYPE Model]`) are C4/C5 contracts that declare screen-level state, invariants, and actions. A component that reads/writes model state declares `@RELATION BINDS_TO -> [ModelId]`. See `semantics-svelte` §IIIa.
- Write relations only in canonical form: `@RELATION PREDICATE -> TARGET_ID`
- Allowed predicates: `DEPENDS_ON`, `CALLS`, `INHERITS`, `IMPLEMENTS`, `DISPATCHES`, `BINDS_TO`, `CALLED_BY`, `VERIFIES`.
- If any relation target, DTO, or contract dependency is unknown, emit `[NEED_CONTEXT: target]` instead of inventing placeholders.

## Complexity Tracking

> **Fill ONLY if Constitution Check has violations that must be justified**

| Violation | Why Needed | Simpler Alternative Rejected Because |
|-----------|------------|-------------------------------------|
| [e.g., 4th plugin] | [current need] | [why 3 plugins insufficient] |
| [e.g., Service layer pattern] | [specific problem] | [why direct ORM access insufficient] |
