Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions canon/principles/vodka-architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -145,6 +145,35 @@ Before any change to a vodka-architecture server, answer these three questions:

---

## Spec Convention — The Boundary Must Be Enumerated

A server claiming to follow vodka-architecture MUST include three enumerated sections in its spec:

### Boundary Section

`## What This Server Knows` — bullet list of every state, schema, or external resource the server understands or holds.

`## What This Server Does NOT Know` — bullet list of the domain semantics this server defers to canon or the consumer environment. **This list IS the vodka boundary, written down.**

### Non-Goals Section

`## What This Server Is NOT` — bullet list of the categories of responsibility this server explicitly refuses. Each item is a statement future PR authors must rebut to expand scope.

### Why Enumeration Matters

A boundary kept in author intuition gets violated when the author rotates out. A boundary written down survives the rotation. PR authors proposing a new tool must argue against an enumerated non-property — asymmetrically harder than arguing for a useful-sounding addition.

### Failure Mode

Implicit boundaries drift. After a few PRs, the server has accumulated "small additions" that each individually felt fine but cumulatively violate the original vodka frame. The next vodka rewrite has to undo those additions one by one. Enumeration prevents the drift at the PR-review surface, where it is cheapest to catch.

### Receipts

- `klappy/PTXprint-MCP` v1.2 §1 — enumerated boundary + non-goals, with explicit attribution that the v1.0 → v1.1 sprawl happened because the v1.0 boundary was implicit.
- *(Each subsequent vodka-compliant spec adds a row pointing at its boundary section.)*

---

## See Also

### Design Heritage — Full Articles
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ exposure: nav
tier: 3
voice: neutral
stability: evolving
tags: ["promotions", "proposed", "vodka-architecture", "spec-convention", "boundary", "non-goals", "amendment"]
promotion_status: proposed
tags: ["promotions", "accepted", "vodka-architecture", "spec-convention", "boundary", "non-goals", "amendment"]
promotion_status: accepted
---

# P0006: Vodka Boundary Enumeration — Specs Must List What the Server Knows, Doesn't Know, and Is NOT
Expand Down Expand Up @@ -103,16 +103,14 @@ Placed at the end of vodka-architecture.md (near "See Also" but above it) so the

## Status

`proposed`
`accepted` (2026-05-05)

## Review Notes

(To be filled during review)

- **Reviewer**:
- **Decision**:
- **Date**:
- **Notes**:
- **Reviewer**: klappy (operator)
- **Decision**: `accepted`
- **Date**: 2026-05-05
- **Notes**: Accepted in the 8-proposal sweep. P0006 sharpens vodka-architecture from philosophy to spec convention by requiring three enumerated sections in any compliant spec ("What This Server Knows", "What This Server Does NOT Know", "What This Server Is NOT"). Section appended before `## See Also` so the convention sits as the operationalization closure of the principle. Last of the small append-style amendments in this sweep — P0003/P0004/P0005 next create whole new canon docs.

## Execution Record

Expand Down
Loading