feat(121): rename tachi commands to tachi.* dot-namespace (#122)

Rename all 6 tachi commands from hyphenated names to dot-namespace
convention (e.g., threat-model → tachi.threat-model) for consistency
with AOD's aod.* pattern. Updates all cross-references across agents,
adapters, schemas, templates, scripts, docs, and install manifest.

- Commands: threat-model, risk-score, infographic, security-report,
  compensating-controls, architecture → tachi.* namespace
- New: /tachi.architecture command (previously undocumented)
- Adapters: claude-code commands + github-actions workflow renamed
- 72 tasks completed across 5 implementation waves

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: davidmatousek

.claude/agents/tachi/control-analyzer.md

@@ -15,7 +15,7 @@ You are the tachi control analyzer -- the compensating controls analysis agent t
 
 Your output is a `compensating-controls.md` document containing a controls summary, per-threat control mappings with code evidence, residual risk scores, and prioritized recommendations, plus a `compensating-controls.sarif` file containing the same controlled findings in SARIF 2.1.0 format with extended property bags. Both files are produced in the specified output directory. All control classifications, residual scores, and recommendations MUST be consistent between the two output formats.
 
-You are the third link in tachi's analysis pipeline: `/threat-model` produces threat findings, `/risk-score` enriches them with quantitative scores, and `/compensating-controls` grounds those scores in codebase reality by detecting what security controls already exist and what gaps remain.
+You are the third link in tachi's analysis pipeline: `/tachi.threat-model` produces threat findings, `/tachi.risk-score` enriches them with quantitative scores, and `/tachi.compensating-controls` grounds those scores in codebase reality by detecting what security controls already exist and what gaps remain.
 
 You are platform-neutral. You do not reference any specific agentic coding tool, IDE, or invocation framework. Your instructions work with any LLM capable of following structured markdown prompts and reading files from a local filesystem.
 
@@ -130,7 +130,7 @@ The analysis pipeline processes scored threat findings through six sequential ph
 
 ### Processing Capacity
 
-The analysis pipeline processes findings sequentially in a single pass over the scored input, but performs parallel file reads during codebase discovery (Phase 2) and control detection (Phase 3). For threat models with up to 200 scored findings and codebases up to 500 files, this approach is expected to complete within reasonable time bounds. If context window pressure arises with very large codebases, the command layer (`/compensating-controls`) may constrain the file set via glob patterns or directory scoping. File scoping is a command-layer orchestration concern -- the agent processes whatever codebase scope it receives.
+The analysis pipeline processes findings sequentially in a single pass over the scored input, but performs parallel file reads during codebase discovery (Phase 2) and control detection (Phase 3). For threat models with up to 200 scored findings and codebases up to 500 files, this approach is expected to complete within reasonable time bounds. If context window pressure arises with very large codebases, the command layer (`/tachi.compensating-controls`) may constrain the file set via glob patterns or directory scoping. File scoping is a command-layer orchestration concern -- the agent processes whatever codebase scope it receives.
 
 ### MAESTRO Layer Propagation
 

.claude/agents/tachi/risk-scorer.md

@@ -89,7 +89,7 @@ When the input `threats.md` includes baseline frontmatter (`baseline.source` is
 
 ### Processing Capacity
 
-The scoring pipeline processes findings sequentially in a single pass. For threat models with up to 200 findings, this single-pass approach is expected to complete within the 5-minute performance target (SC-006). If context window pressure arises with very large threat models (>100 findings), the command layer (`/risk-score`) may batch invocations by threat category, invoking the scoring pipeline once per category and merging results. Batching is a command-layer orchestration concern -- the agent processes whatever finding set it receives in a single pass.
+The scoring pipeline processes findings sequentially in a single pass. For threat models with up to 200 findings, this single-pass approach is expected to complete within the 5-minute performance target (SC-006). If context window pressure arises with very large threat models (>100 findings), the command layer (`/tachi.risk-score`) may batch invocations by threat category, invoking the scoring pipeline once per category and merging results. Batching is a command-layer orchestration concern -- the agent processes whatever finding set it receives in a single pass.
 
 ### MAESTRO Layer Propagation
 

.claude/commands/tachi.architecture.md

@@ -0,0 +1,82 @@
+---
+description: Generate an architecture description for tachi threat modeling input
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+Consider user input before proceeding (if not empty).
+
+## Overview
+
+Generates a structured architecture description suitable as input for `/tachi.threat-model`. Analyzes the target codebase or project documentation to produce a DFD-style architecture description with components, data flows, trust boundaries, and external entities.
+
+**Output**: `architecture.md` — structured architecture description in the target directory.
+
+## Step 1: Determine Scope
+
+1. If `$ARGUMENTS` specifies a path or directory, use that as the analysis target
+2. Default: analyze the current working directory
+3. If `$ARGUMENTS` contains `--output <path>`:
+   - Write output to the specified path
+   - Default: `docs/security/architecture.md`
+
+## Step 2: Analyze Architecture
+
+Examine the target for architectural elements:
+
+1. **Components**: Services, modules, databases, APIs, queues, caches
+2. **Data Flows**: How data moves between components (protocols, formats)
+3. **Trust Boundaries**: Network boundaries, authentication gates, privilege transitions
+4. **External Entities**: Users, third-party APIs, external services
+5. **Data Stores**: Databases, file systems, object storage, caches
+
+Sources to examine (in priority order):
+- Existing architecture documentation (`docs/architecture/`)
+- Infrastructure files (Dockerfile, docker-compose, Kubernetes manifests, Terraform)
+- API definitions (OpenAPI specs, GraphQL schemas, protobuf)
+- Source code structure (service boundaries, module organization)
+- Configuration files (environment variables, service endpoints)
+
+## Step 3: Generate Architecture Description
+
+Produce a structured markdown document containing:
+
+1. **System Overview**: One-paragraph description of the system
+2. **Architecture Diagram**: Mermaid flowchart showing components and data flows
+3. **Components Table**: Name, type, description, technology for each component
+4. **Data Flows Table**: Source, destination, protocol, data classification
+5. **Trust Boundaries**: Named boundaries with contained components
+6. **External Entities**: Name, type, interaction pattern
+
+## Step 4: Report
+
+Display summary:
+
+```
+ARCHITECTURE DESCRIPTION GENERATED
+Output: {output_path}
+
+Components: {count}
+Data Flows: {count}
+Trust Boundaries: {count}
+External Entities: {count}
+
+Next: /tachi.threat-model {output_path}
+```
+
+## Usage Examples
+
+```bash
+# Analyze current project
+/tachi.architecture
+
+# Analyze specific directory
+/tachi.architecture src/backend/
+
+# Custom output location
+/tachi.architecture --output reports/arch.md
+```

.claude/commands/compensating-controls.md …/commands/tachi.compensating-controls.md.claude/commands/compensating-controls.md renamed to .claude/commands/tachi.compensating-controls.md .claude/commands/compensating-controls.md renamed to .claude/commands/tachi.compensating-controls.md

@@ -102,19 +102,19 @@ Tiers 1-3 solid, Tier 4 ghost:
 - **Tier 1**: Data from co-located `threats.md` Section 6
 - **Tier 2**: Data from `risk-scores.md` Section 2 (Scored Threat Table): composite score distribution
 - **Tier 3**: Label changes to "Unmitigated Risk" using Tier 2 severity data (no control reduction applied)
-- **Tier 4**: Rendered as ghost with CTA: "Run /compensating-controls to complete the funnel"
-- **Enhancement tip in spec**: "Run `/compensating-controls` to unlock the full 4-tier risk reduction funnel"
-- **Sidebar**: Shows total findings, severity distribution, "Risk Reduction: N/A -- run /compensating-controls"
+- **Tier 4**: Rendered as ghost with CTA: "Run /tachi.compensating-controls to complete the funnel"
+- **Enhancement tip in spec**: "Run `/tachi.compensating-controls` to unlock the full 4-tier risk reduction funnel"
+- **Sidebar**: Shows total findings, severity distribution, "Risk Reduction: N/A -- run /tachi.compensating-controls"
 
 #### 1-Tier Mode (threats)
 
 Tier 1 solid, Tiers 2-4 ghost:
 
 - **Tier 1**: Data from `threats.md` Section 6: total count and severity distribution
-- **Tier 2**: Ghost CTA: "Run /risk-score"
-- **Tier 3**: Ghost CTA: "Run /compensating-controls"
+- **Tier 2**: Ghost CTA: "Run /tachi.risk-score"
+- **Tier 3**: Ghost CTA: "Run /tachi.compensating-controls"
 - **Tier 4**: Ghost CTA: "Complete the pipeline"
-- **Enhancement tip in spec**: "Run `/risk-score` to begin quantifying your risk reduction funnel"
+- **Enhancement tip in spec**: "Run `/tachi.risk-score` to begin quantifying your risk reduction funnel"
 - **Sidebar**: Shows total findings and qualitative severity counts only
 
 ### Risk Funnel Edge Cases

.claude/commands/infographic.md .claude/commands/tachi.infographic.md.claude/commands/infographic.md renamed to .claude/commands/tachi.infographic.md

@@ -7,6 +7,27 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ---
 
+## [Unreleased]
+
+### Changed
+
+- **Command Namespace Migration** (Feature 121) — All tachi pipeline commands renamed from unprefixed names to `tachi.*` namespace prefix. New `/tachi.architecture` command added. Install script now cleans up deprecated command files on upgrade. See migration table below.
+
+#### Command Name Migration
+
+| Old Command | New Command |
+|-------------|-------------|
+| `/threat-model` | `/tachi.threat-model` |
+| `/risk-score` | `/tachi.risk-score` |
+| `/compensating-controls` | `/tachi.compensating-controls` |
+| `/infographic` | `/tachi.infographic` |
+| `/security-report` | `/tachi.security-report` |
+| *(new)* | `/tachi.architecture` |
+
+Upgrading: Run `install.sh` — it automatically removes old unprefixed command files and installs the new `tachi.*` versions.
+
+---
+
 ## [4.6.0](https://github.com/davidmatousek/tachi/compare/v4.5.0...v4.6.0) (2026-04-09)