poko8nada/overview

Project Overview

Purpose of docs/overview.md

This document captures the irreducible knowledge that cannot be derived from code, tests, or ADRs — the Why and Why Not behind the project's existence. Agents use it to understand intent when making architectural decisions.

What to write

• Problem: What problem does this project solve? For whom?
• Goals: What does success look like?
• Non-goals: What is explicitly out of scope, and why?
• Constraints: External constraints (legal, organizational, SLA, third-party).
• Key decisions: Why this tech stack over alternatives? Link to ADRs for details.

What NOT to write

• Current system state — code and tests are the source of truth
• Directory structure — agents can read the filesystem
• How features work — that belongs in code and tests
• Anything that will change as implementation evolves

Do not use overview as a substitute for spec or ADR. If implementation requires exact values such as route names, binding names, object keys, or error policy, put those in docs/spec.md or docs/adr/*.md.

Format

This document should be written in Japanese.

---
last-validated: YYYY-MM-DD
phase: current
---

# [Project Name]

## Problem

[1-3 sentences: what problem, for whom]

## Goals

- [Specific, measurable goal]
- [Specific, measurable goal]

## Non-goals

- [What is out of scope and why]

## Constraints

- [External constraint: legal, SLA, org policy, etc.]

## Tech Stack Rationale

- [Choice]: [Why this over alternatives] → see ADR-NNNN

Maintenance rule

Update last-validated whenever you verify the document still reflects reality. If any section no longer holds, update it or supersede with a new version. A stale last-validated is a signal the document may have rotted.