Chapter 24: Required Product Artifacts

Last Updated: 2026-03

24.2 The Five Required Artifacts

File	Purpose	Location
CLAUDE.md	AI context file — read at session start	Project root
REQUIREMENTS.md	User stories with acceptance criteria	Project root
ARCHITECTURE.md	Technical decisions, patterns, structure	Project root
DEPLOY.md	Deployment instructions, env vars, rollback	Project root
THIRD_PARTY.md	Dependency registry with audit dates	Project root

---

24.3 REQUIREMENTS.md

Documents what the product is supposed to do from the user’s perspective.

Format

# Requirements — [Product Name]

## User Stories

### US-001: [Story Title]
**As a** [type of user],
**I want to** [perform some action],
**So that** [I can achieve some goal].

**Acceptance Criteria:**
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]

**Status:** Pending / In Progress / Complete
**Priority:** P1 (must have) / P2 (should have) / P3 (nice to have)

---

### US-002: [Story Title]
...

Rules for requirements

• Write acceptance criteria as testable statements. “The form validates email format” — not “The form works.”
• Link each acceptance criterion to a test case when tests are written.
• Mark stories as complete only when all acceptance criteria pass.
• Add new stories as requirements evolve; never delete completed stories (they are the historical record).

---

24.4 ARCHITECTURE.md

Documents technical decisions so future developers understand why the code is structured the way it is.

Format

# Architecture — [Product Name]

## Overview
Brief description of the system architecture.

## Tech Stack
| Layer | Technology | Version | Notes |
|-------|-----------|---------|-------|
| Backend | PHP | 8.2 | WordPress plugin |
| AI | Claude Opus 4.5 | via n8n | |
| Database | MySQL | 8.0 | Via WordPress wpdb |

## Key Design Decisions

### Decision 1: [Title]
**Context:** What situation prompted this decision?
**Decision:** What was decided?
**Consequences:** What are the trade-offs?

### Decision 2: [Title]
...

## Shared Library Usage
Which components from ITI/shared/ are used and how.

## Data Flow
Describe the main data flows through the system (text or diagram).

## Directory Structure

---

24.5 DEPLOY.md

Documents exactly how to deploy the product, including all required environment variables.

Format

# Deployment — [Product Name]

## Platform
WordPress plugin / Tauri app / Flask service / etc.

## Prerequisites
- WordPress 6.0+
- PHP 8.2+
- n8n workflow [Workflow Name] published and active

## Environment Variables / Configuration

| Variable | Description | Example |
|----------|-------------|---------|
| `ITI_N8N_BASE_URL` | n8n webhook base URL | `http://localhost:5678` |
| `ITI_ANTHROPIC_API_KEY` | Anthropic API key | Set in WordPress options (encrypted) |

## Deployment Steps

1. Download the plugin zip from [location].
2. Upload via WordPress Admin > Plugins > Add New > Upload Plugin.
3. Activate the plugin.
4. Navigate to Settings > [Plugin Name] > enter API keys.
5. Verify n8n webhook connection: [how to test].

## Rollback Procedure
1. Deactivate the plugin.
2. Restore previous version from backup.
3. Re-activate.

## Known Issues
Any known deployment gotchas.

---

24.6 THIRD_PARTY.md

Tracks every external dependency and its security audit status.

Format

# Third-Party Dependencies — [Product Name]

## Policy
Before adding any new dependency, apply the `dependency-hygiene` skill.

## Dependencies

| Package | Version | License | Purpose | Last Audited | Notes |
|---------|---------|---------|---------|-------------|-------|
| `anthropic` | `^0.40` | MIT | Claude API client | 2026-03 | |
| `httpx` | `^0.27` | BSD | Async HTTP client | 2026-03 | |

## Dependency Hygiene Rules
- Pin major versions (^X.Y style)
- Audit before adding any new dependency
- Review for security advisories quarterly
- Remove unused dependencies promptly

---

24.7 Checking Artifact Completeness

Run this check before any release:

# Navigate to product root
cd ITI/products/my-product/

# Verify all five files exist
for f in CLAUDE.md REQUIREMENTS.md ARCHITECTURE.md DEPLOY.md THIRD_PARTY.md; do
    if [ -f "$f" ]; then
        echo "✓ $f"
    else
        echo "✗ MISSING: $f"
    fi
done

Or ask the Vibe Coding Guardian agent:

“Run a vibe coding guardrail audit on my-product — check artifact completeness.”

---

Previous: Chapter 23 — Build Session Protocol | Next: Chapter 25 — Testing