feat: add conductor audit command for architecture documentation

[dudujuju828]

Audit command

Adds a new /conductor:audit command that analyzes the current codebase. It generates or updates conductor/architecture.md as a persistent context artifact alongside the existing product, tech-stack, and workflow definitions. The audit covers directory layout, module boundaries, data flow, API surfaces, security boundaries, and architectural health. The command is re-runnable. When conductor/architecture.md already exists, a subsequent run performs a fresh analysis. It adds a “Changes Since Last Audit” section that summarizes differences. The audit also ensures the architecture document is discoverable from Conductor’s index. It does this by adding a link in conductor/index.md if one is not already present.

This PR also registers the Architecture artifact path in GEMINI.md and the setup index template (setup.toml), and documents the command in README.md.

Motivation

The existing commands cover the lifecycle of track-scoped work. setup scaffolds the project environment. newTrack generates specs and an implementation plan. implement executes planned tasks sequentially. status reports track progress. review checks completed work against guidelines. revert rolls back prior work using git history. All of these operate on tracks, these are scoped units of change. /conductor:audit adds a different axis. It analyzes the codebase itself, independent of any track. It produces a persistent architecture document.

Trade-offs

1. Token cost. The analysis protocol is a multi-pass sweep. It includes file discovery, structure analysis, pattern recognition, dependency tracing, data flow, API surface cataloging, security boundary mapping, and anti-pattern detection. On large codebases, this can consume a significant number of tokens in a single invocation. The flash model constraint mitigates cost per token. It does not reduce the volume of content the agent must read.

2. Full re-analysis on every run. Re-audits perform a complete fresh analysis, then diff against the previous document. There is no option to audit a subset of the codebase or a single module. On large projects where only one area changed, this is redundant work.

3. Analysis quality depends on the agent and context limits. The spec asks the agent to identify design patterns, trace request lifecycles, detect anti-patterns, and assess architectural health in a single session. On complex codebases, some sections may be shallow or inaccurate. This depends on how much of the codebase fits within the agent’s context window. The spec has no mechanism to signal low-confidence sections.

4. Point-in-time snapshot. The architecture document reflects the codebase at the time of the audit. There is no trigger to re-run when the codebase changes significantly. The document can go stale silently between runs.

Evidence

Audit ran on the conductor repo.
Evidence: sample output generated by /conductor:audit (permalink): conductor/architecture.md

As an additional validation, I ran /conductor:audit on my (C++) HTTP server repository to cover a more complex architecture then conductor itself (permalink): conductor/architecture.md

Weakpoints

Based on the evidence above, the generated document has room to improve. It could be more concise. It should also make it clearer where each feature lives in the codebase.

1. Not tied enough to concrete code locations, so the agent can’t easily verify claims.
2. A lot of prose and not enough “where to change what”, so it’s harder to act on.
3. Could be more thorough in what it extracts. This could be addressed with an optional flag or config setting that controls audit depth/strength.

Overall, this feels like a reasonable starting point for Conductor’s audit capability, if this feature is in scope.