---
name: sdlc-project-manifest
description: >-
  Generate and read the project manifest that records which templates and patterns
  were chosen during scaffolding. This manifest is the single source of truth for
  ALL agents — Scaffolder creates it, every other agent reads it before working.
  Triggers on any scaffolding, implementation, review, or documentation task.
  Ensures cross-agent consistency for template patterns across the entire SDLC lifecycle.
version: "1.0"
author: sdlc-harness
user-invocable: false
---

# SDLC Project Manifest — Cross-Agent Pattern Persistence

## What is the project manifest?

The file `.SDLC/project-manifest.md` is generated by the **Scaffolder** during Phase 3.
It records which templates were chosen and the exact code patterns that ALL agents must follow.
This ensures the Implementer, QA Reviewers, Deployer, and Documenter all work consistently
with the same patterns the Scaffolder established.

## For the SCAFFOLDER (write mode)

After scaffolding, create `.SDLC/project-manifest.md` with this exact format:

```markdown
# Project Manifest — <ProjectName>

> Auto-generated by Scaffolder (Phase 3). All agents MUST follow these patterns.
> Last updated: YYYY-MM-DD

## Projects

| Project Folder | Template Used | Code Root | Language |
|---|---|---|---|
| src/<Name>API/ | the API template repo | app/ | Python 3.12 |
| src/<Name>Business/ | the base app template repo | src/ | Python 3.12 |
| src/<Name>Web/ | React + TypeScript | src/ | TypeScript |

## Template Patterns (fetched from the project's GitHub org repos)

### API Project: <Name>API

**Template:** `the project's API template (from copilot-instructions.md)`

**Entry point pattern:**
- `app/main.py` uses `Application()` factory (from `application.py`)
- `Application` extends `Application_Base` from `app/libs/base/`
- NEVER use bare `app = FastAPI()`

**DI container pattern:**
- Register services: `self.application_context.add_singleton(IService, Implementation)`
- Resolve in routers via `TypedFastAPI` app context
- Use Protocol interfaces in `app/services/interfaces.py`

**Framework directories:**
- `app/libs/base/` — Application_Base, TypedFastAPI
- `app/libs/application/` — AppContext, Configuration
- `app/libs/azure/` — Azure App Configuration helpers

**Router pattern:**
- Routers in `app/routers/` — one file per domain area
- Health probes in `app/routers/http_probes.py`
- Routers registered in `Application._config_routers()`

**Service pattern:**
- Interfaces: `app/services/interfaces.py` (Protocol classes)
- Implementations: `app/services/<name>_service.py`
- Registered via DI in `Application._register_dependencies()`

**Data access pattern:**
- Entities: `RootEntityBase["EntityName", KeyType]` (from `the approved Cosmos DB library`)
- Repositories: `RepositoryBase[Entity, KeyType]` (from `the approved Cosmos DB library`)
- Location: `app/domain/` or `app/business_component/`

**Dockerfile pattern:**
- Base: `mcr.microsoft.com/azurelinux/base/python:3.12`
- UV: `COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/`
- Install: `uv sync --frozen --no-cache`
- Run: `.venv/bin/uvicorn app.main:app --port 80 --host 0.0.0.0 --workers 4`

**Dependencies pattern:**
- `pyproject.toml` uses `[dependency-groups] dev` (not optional-dependencies)
- `[tool.pytest.ini_options]` with `pythonpath = ["."]`

### Business Project: <Name>Business

**Template:** `the project's app template (from copilot-instructions.md)`
[Fill with patterns from that template]

### Web Project: <Name>Web

**Template:** React + TypeScript
[Fill with patterns]

## Azure SDK Libraries

| Library | Package | Used For | Pattern |
|---|---|---|---|
| the approved Cosmos DB library | `the approved Cosmos DB library` | Cosmos DB | `RootEntityBase` + `RepositoryBase` |
| the approved Storage library | `the approved Storage library` | Blob/Queue | `AsyncStorageBlobHelper` with `async with` |

## Naming Conventions

- Project folders: `<ProjectName><Layer>` (e.g., CustomerFeedbackAPI)
- Async methods: suffix with `Async`
- Test files: `test_<module_name>.py` mirroring source structure
- API routes: `/api/v1/<resource>`
```

**CRITICAL: Read the actual template files from GitHub MCP when generating this manifest.**
Do NOT invent patterns — fetch and record what the templates actually contain.

## For ALL OTHER AGENTS (read mode)

**Before doing any work, read `.SDLC/project-manifest.md` if it exists.**

This tells you:
- Which template each project uses → follow its patterns exactly
- What DI pattern to use → `Application_Base` + `add_singleton` or plain FastAPI
- Where files go → code root, test location, service location
- What Dockerfile pattern → base image, uv installation, CMD
- What SDK patterns → `RootEntityBase`, `AsyncStorageBlobHelper`

### For the IMPLEMENTER

1. Read `.SDLC/project-manifest.md` FIRST.
2. Check which project you're working in → find its template section.
3. Follow the exact pattern listed — entry point, DI, services, data access.
4. When adding a new service: use the Protocol interface pattern from the manifest.
5. When adding a new entity: use the data access pattern from the manifest.

### For QA REVIEWERS

1. Read `.SDLC/project-manifest.md` FIRST.
2. Verify code matches the patterns recorded in the manifest.
3. Flag any deviation as an **Important** finding:
   - "Code uses bare `FastAPI()` but manifest specifies `Application_Base` pattern"
   - "Service registered directly but manifest requires Protocol interface"

### For the DEPLOYER

1. Read `.SDLC/project-manifest.md` to know which projects exist and their Dockerfile patterns.
2. Use the recorded Dockerfile pattern for `azure.yaml` service mappings.

### For the DOCUMENTER

1. Read `.SDLC/project-manifest.md` to understand the architecture.
2. Reference the correct template names and patterns in ADRs and API docs.

## If the manifest doesn't exist

If `.SDLC/project-manifest.md` doesn't exist yet (e.g., working on an existing project
that predates this skill), the agent should:

1. Read the project structure to infer which templates were used.
2. Generate the manifest based on what exists.
3. Proceed with the task.

This ensures backward compatibility with projects scaffolded before the manifest was introduced.