# Project Analysis Profile

```yaml
roles:
  - role: analyser
    min: 2
    recommended: 3
    max: 5
    duty: analysis-worker
  - role: report-writer
    min: 1
    recommended: 1
    max: 1
    duty: report-writer
  - role: verifier
    min: 0
    recommended: 0
    max: 0
    duty: reverification-worker
    dynamic: true
```

- Purpose: map a bounded project area so later work can navigate components, dependencies, entry points, repositories, and external integrations without changing the source
- Required workers:
  - claude
  - codex
  - report-writer
- Optional workers (opt-in via `--workers`):
  - antigravity
  - grok — optional adversarial analyser/critic through the Grok CLI wrapper
  - kimi — optional long-context analyser/critic through the Kimi CLI wrapper
{{INCLUDE:_common-contract.md}}
- Phase 1.5 questions:
  - Which repositories, directories, and external systems are inside the scan scope?
  - Which components or feature areas must remain shallow rather than receiving a detailed analysis?
  - Which user intent and preserved boundaries constrain this map?
- Required report blocks:
  - scan scope and excluded areas
  - components, dependency directions, entry points, repositories, and external integrations
  - shallow feature index and unresolved navigation questions
- Fill these when the repository states them; leave a block out rather than guessing at it:
  - `projectAnalysis.techStack` — the languages the project is written in with their
    versions, the frameworks it runs on, and the package manager, build, test, lint,
    typecheck, format, CI and container tools. Record where each version was read via
    `versionSource`: a manifest range (`^1.17.0`) and a lockfile pin are different facts,
    and a mismatch between a pinned server image and a ranged client is a real
    compatibility risk that collapses if both are written the same way. A tool the
    project does not have is not a row — its absence belongs in `qualityCoverage`.
  - `projectAnalysis.internalInterfaces` — the seams components call across, with the
    signature a caller writes against. `kind` is what the seam is, not where its file
    sits: `port` for an abstraction a domain declares, `adapter` for an implementation
    that satisfies one. `ownerComponentId` and every `consumers` entry must name a
    component this report declares.
  - `projectAnalysis.workflows` — one run of real work through the system, start to
    finish: what triggers it and which component does what, in order. This is the only
    block that says how the parts are used rather than how they are arranged, so a
    reader can follow a request without reconstructing it from the dependency graph.
    Each step's `componentId` must name a declared component.
- Cross-verification mode:
  - Phase 5.5 convergence runs in adversarial mode (`convergence.adversarial=true`).
- Non-goals:
  - source or configuration edits
  - tests, builds, migrations, or deployments
  - implementation alternatives, file change specifications, or execution plans