Project Execution

# Mission Report Template

Final mission report with artifacts, decisions, and evidence.

## Purpose

The Mission Report is the definitive record of a completed
mission. It documents what was delivered, why decisions were
made, how success was validated, and what follow-up is needed.
Use it to close missions and hand off to future maintainers.

## When to Use

Generate a Mission Report when:

- A mission completes successfully (outcome: success)
- A mission is terminated early (outcome: partial or failed)
- User requests a final summary
- Handing off work to another agent or session
- Archiving for future reference

Do NOT generate when:

- The mission is still in progress (use Progress Report instead)
- The work was a single trivial change

## Getting Started

1. Copy the template below
2. Fill required fields: `mission`, `duration`, `outcome`,
   `delivered_artifacts`, `decisions`, `validation_evidence`,
   `follow_ups`
3. Add optional `lessons_learned`, `blockers_resolved`, `metrics`
   if relevant
4. Store in mission archive or attach to PR/commit
5. Link from any related issues or discussions

## Why This Pattern

Mission Reports create institutional memory. Without them, the
rationale behind decisions decays: six months later, nobody
remembers why a particular approach was chosen or what alternatives
were considered.

The `decisions` field with `alternatives_considered` is especially
valuable: it prevents future contributors from re-litigating
settled questions without new information.

This pattern emerged from observing that teams with good
documentation of "why" move faster than teams who must re-derive
rationale from code archaeology.

## Template

```yaml
mission_report:
  # REQUIRED: Mission identification
  mission:
    name: "Implement user authentication"
    brief_ref: "docs/project-brief.md"
    spec_ref: "docs/specification.md"
    plan_ref: "docs/implementation-plan.md"

  # REQUIRED: Mission duration
  duration:
    start: "2024-03-20T09:00:00Z"
    end: "2024-03-20T14:30:00Z"
    total: "5h 30m"

  # REQUIRED: Mission outcome
  outcome: success | partial | failed

  # REQUIRED: What was delivered
  delivered_artifacts:
    - path: "src/auth/jwt.py"
      type: created | modified | deleted
      description: "JWT token generation and validation"
    - path: "src/api/middleware/auth.py"
      type: modified
      description: "Authentication middleware for protected routes"
    - path: "tests/auth/test_jwt.py"
      type: created
      description: "Unit tests for JWT module"

  # REQUIRED: Key decisions with rationale
  decisions:
    - decision: "Use RS256 algorithm for JWT signing"
      rationale: |
        Asymmetric encryption allows public key distribution for
        verification without exposing private key.
      alternatives_considered:
        - "HS256 (simpler but symmetric)"
        - "Opaque tokens (requires database lookup)"
      impact: "Requires key management infrastructure"

  # REQUIRED: How success was validated
  validation_evidence:
    - description: "All unit tests pass"
      evidence_type: test
      status: pass
      reference: "pytest tests/auth/ -v"
    - description: "Integration test covers full auth flow"
      evidence_type: test
      status: pass
      reference: "pytest tests/integration/test_auth.py"
    - description: "Security review completed"
      evidence_type: review
      status: pass
      reference: "docs/security-review.md"

  # REQUIRED: Recommended next steps
  follow_ups:
    - action: "Add refresh token rotation"
      priority: medium
      rationale: "Improves security posture"
      estimated_effort: small
    - action: "Implement token revocation"
      priority: low
      rationale: "Required for logout across devices"
      estimated_effort: medium

  # OPTIONAL: Lessons learned
  lessons_learned:
    - lesson: "Start with integration tests earlier"
      context: "Found integration issues late that required rework"
      application: "Write integ