blue/.blue/docs/dialogues/2026-01-26T0500Z-iso-8601-document-filename-timestamps-rfc-design.dialogue.recorded.md

# Alignment Dialogue: ISO 8601 Document Filename Timestamps RFC Design

**Draft**: Dialogue 2030
**Date**: 2026-01-26 09:42
**Status**: Converged
**Participants**: 💙 Judge, 🧁 Muffin, 🧁 Cupcake, 🧁 Scone, 🧁 Eclair, 🧁 Donut, 🧁 Brioche
**RFC**: iso-8601-document-filename-timestamps

## Expert Panel

| Agent | Role | Tier | Relevance | Emoji |
|-------|------|------|-----------|-------|
| 💙 Judge | Orchestrator | — | — | 💙 |
| 🧁 Muffin | UX Architect | Core | 0.95 | 🧁 |
| 🧁 Cupcake | Technical Writer | Core | 0.90 | 🧁 |
| 🧁 Scone | Systems Thinker | Adjacent | 0.70 | 🧁 |
| 🧁 Eclair | Domain Expert | Adjacent | 0.65 | 🧁 |
| 🧁 Donut | Devil's Advocate | Adjacent | 0.60 | 🧁 |
| 🧁 Brioche | Integration Specialist | Wildcard | 0.40 | 🧁 |

## Alignment Scoreboard

| Agent | Wisdom | Consistency | Truth | Relationships | **Total** |
|-------|--------|-------------|-------|---------------|----------|
| 🧁 Muffin | 16 | 12 | 16 | 13 | **57** |
| 🧁 Cupcake | 13 | 13 | 14 | 12 | **52** |
| 🧁 Scone | 17 | 15 | 18 | 13 | **63** |
| 🧁 Eclair | 17 | 13 | 18 | 13 | **61** |
| 🧁 Donut | 16 | 13 | 16 | 13 | **58** |
| 🧁 Brioche | 13 | 14 | 14 | 13 | **54** |

**Total ALIGNMENT**: 345 / 480 (72%) — Converged via Judge ruling

## Perspectives Inventory

| ID | Agent | Perspective | Round |
|----|-------|-------------|-------|
| P01 | 🧁 Muffin | Filename timestamps optimized for machines, hostile to humans | R0 |
| P01 | 🧁 Cupcake | Internal filename parsing is zero, cross-references unaffected | R0 |
| P01 | 🧁 Scone | Filesystem Authority (RFC 0022) compatibility confirmed safe | R0 |
| P01 | 🧁 Eclair | ISO 8601 basic format correct but missing seconds | R0 |
| P02 | 🧁 Eclair | "Basic" vs "Extended" terminology misapplied -- RFC uses hybrid notation | R0 |
| P01 | 🧁 Donut | Migration cost is zero but value is also minimal | R0 |
| P01 | 🧁 Brioche | Shell wildcards and tab-completion remain stable | R0 |
| P02 | 🧁 Brioche | Store.rs regex narrowly scoped to numbered docs only | R0 |
| P01 | 🧁 Muffin | Seconds worsen UX; collision prevention belongs in handler layer | R1 |
| P01 | 🧁 Cupcake | RFC must acknowledge hybrid notation explicitly, not claim "ISO 8601 basic" | R1 |
| P01 | 🧁 Scone | Minute precision sufficient for human-paced workflow; empirical evidence confirms | R1 |
| P01 | 🧁 Eclair | Industry precedent (AWS S3, Docker, RFC 3339) validates hybrid notation | R1 |
| P01 | 🧁 Donut | Timestamps solve real problems sequence numbers don't (concession) | R1 |
| P01 | 🧁 Brioche | ISO format is tool-agnostic and universally sortable | R1 |
| P01 | 🧁 Muffin | Three-layer safety: seconds + existence check + sequence fallback | R2 |
| P01 | 🧁 Cupcake | Label as "filename-safe ISO 8601 hybrid"; keep HHMMZ; remove audit fix | R2 |
| P01 | 🧁 Scone | HHMMSSZ + overwrite guards (defense-in-depth, survivorship bias conceded) | R2 |
| P01 | 🧁 Eclair | Seconds treat symptom not disease; ship HHMMZ, fix overwrite separately | R2 |
| P02 | 🧁 Donut | HHMMSSZ eliminates uncertainty for 2 chars; doesn't block on overwrite work | R2 |
| P01 | 🧁 Brioche | Toolchains indifferent to HHMMZ vs HHMMSSZ; HHMMZ + overwrite guards | R2 |
| P01 | 🧁 Muffin | Timestamps for sorting, not atomicity; HHMMZ (switched) | R3 |
| P01 | 🧁 Cupcake | Survivorship bias compelling; HHMMSSZ (switched) | R3 |
| P01 | 🧁 Scone | Window never closes; HHMMSSZ is defenseless defense-in-depth; HHMMZ (switched) | R3 |
| P01 | 🧁 Eclair | Ship seconds now, fix overwrite later; HHMMSSZ (switched back) | R3 |
| P01 | 🧁 Donut | Seconds were incomplete hedge; HHMMZ (switched) | R3 |
| P01 | 🧁 Brioche | 60x reduction is real for 2 chars; HHMMSSZ (switched) | R3 |

## Tensions Tracker

| ID | Tension | Status | Raised | Resolved |
|----|---------|--------|--------|----------|
| T1 | Timestamp precision buys uniqueness at cost of filename scannability | Resolved | 🧁 Muffin R0 | 🧁 Muffin R2: Conceded, accepts timestamps |
| T2 | Human readability vs machine parsability tradeoff | Resolved | 🧁 Cupcake R0 | R2: Panel accepts tradeoff is worth it |
| T3 | Audit slug bug -- bundle in RFC or separate fix? | Resolved | 🧁 Scone R0 | 🧁 Scone R1: Extract as standalone fix |
| T4 | Hybrid notation mislabeled as "ISO 8601 basic format" | Resolved | 🧁 Eclair R0 | 🧁 Eclair R1: Hybrid is industry standard |
| T5 | Minute-level precision may still produce collisions | Resolved | 🧁 Eclair R0 | R3: 3-3 symmetric flip; 💙 Judge rules HHMMZ + overwrite protection |
| T6 | Optimizing for machine parsing that doesn't exist in codebase | Resolved | 🧁 Donut R0 | 🧁 Donut R1: Conceded timestamps solve real problems |
| T7 | External integrations may glob/parse date-prefixed filenames | Resolved | 🧁 Brioche R0 | 🧁 Brioche R1: ISO handles naturally |
| T8 | Filename length (+6 chars) may truncate slugs in narrow IDE panels | Resolved | 🧁 Brioche R1 | R2: Accepted as worthwhile tradeoff |
| T9 | Collision prevention encoded in wrong layer (clock vs handler) | Resolved | 🧁 Muffin R1 | R2: All agree overwrite protection needed separately |
| T10 | No overwrite protection in handlers (silent data loss on collision) | Consensus | R2 investigation | R2: All agree — fix separately from this RFC |

## Round 0: Opening Arguments

### 🧁 Muffin

[PERSPECTIVE P01: Filename timestamps optimized for machines, hostile to humans]

The proposal shifts from `2026-01-26-spike.md` to `2026-01-26T0856Z-spike.md`. This solves the collision problem for Blue and its SQLite store, but creates a UX problem for the human navigating `.blue/docs/spikes/` in their terminal or IDE.

Current reality: `ls -l spikes/` produces 15 files all starting with `2026-01-26-`. You scan by slug. The date is visual anchor, the slug is semantic payload.

New reality: `2026-01-26T0856Z-native-kanban-apps.md`. The timestamp injects 6 characters of noise between the date anchor and the slug. Your eye parses: `2026-01-26T` (date start), `0856Z` (machine time), then finally the slug. The timestamp fragment disrupts the visual rhythm humans rely on for filename scanning.

[TENSION T1: Timestamp precision buys uniqueness at cost of filename scannability]

The timestamps exist purely for creation-order sorting and collision avoidance. But filesystem UIs show these filenames constantly. The human never asked for minute-level precision in the filename -- that precision lives inside the markdown body. The filename's job is disambiguation and sorting, not authoritative timestamping.

### 🧁 Cupcake

[PERSPECTIVE P01: Internal filename parsing appears zero, cross-references unaffected]

The RFC states "No code parses dates from filenames" and cites `store.rs:2232` as the only regex, which extracts RFC/ADR numbers, not dates. Verified: the SQLite store uses `find_document()` by title, not filename pattern. The timestamp change is purely cosmetic to filenames -- nothing breaks.

The audit_doc.rs:38 bug (raw title instead of `title_to_slug()`) is correctly identified and proposed as part of this change. Good housekeeping.

[TENSION T2: Human readability vs machine parsability tradeoff]

The RFC doesn't discuss alternatives like subdirectories (`2026-01-26/0856Z-slug.md`). Worth considering whether the sorting benefit justifies the readability cost, especially for dialogues and postmortems reviewed months later.

### 🧁 Scone

[PERSPECTIVE P01: Filesystem Authority Compatibility]

The RFC claims "no code parses dates from filenames" -- this is confirmed but incomplete. Line 2240 in `store.rs` has `^(\d{4})-.*\.md$` targeting numbered docs. Date-prefixed docs (spikes, dialogues, decisions, postmortems, audits) never use `scan_filesystem_max()`. RFC 0022's filesystem authority design is safe.

[TENSION T3: Audit Handler Title Slugification Bug]

`audit_doc.rs:38` constructs filenames with raw title, not slugified. The RFC notes this and proposes adding `title_to_slug()`. But this is a pre-existing bug unrelated to timestamps. Should the RFC bundle this fix, or is it scope creep?

### 🧁 Eclair

[PERSPECTIVE P01: ISO 8601 Basic Format is Filename-Correct but Missing Seconds]

The RFC omits seconds, creating collision risk within the same minute. Two spikes at 08:56:23 and 08:56:47 both become `2026-01-26T0856Z-`. ISO 8601 basic format with seconds: `YYYYMMDDTHHMMSSZ` (e.g., `20260126T085623Z`) provides genuine creation-order without collisions.

[PERSPECTIVE P02: The "Basic" vs "Extended" Terminology is Misapplied]

The RFC uses `YYYY-MM-DDTHHMMZ` -- hyphens in the date but no colons in the time. This is **hybrid notation**, not ISO 8601 basic format. True basic format omits ALL separators: `20260126T0856Z`. True extended format includes ALL separators: `2026-01-26T08:56Z`. The hybrid is pragmatic (readable date, legal time), but calling it "ISO 8601 basic format" is technically incorrect.

[TENSION T5: Minute-level precision may still produce collisions]

If the motivation is "15 spikes in one day" and the solution doesn't resolve within-minute collisions, the problem isn't fully solved. Adding seconds resolves this completely.

### 🧁 Donut

[PERSPECTIVE P01: The migration cost is zero but the value is also minimal]

The RFC claims "no migration needed" and the codebase confirms it. But challenge: if nothing parses these timestamps, what's the benefit?

1. **Creation order**: Already guaranteed by filesystem ctime.
2. **Uniqueness**: The 15 files already have different slugs. The collision risk is title collisions, not timestamp collisions.
3. **Timezone consistency**: Valid issue, but fixes a bug with no symptoms.

[TENSION T6: Optimizing for machine parsing that doesn't exist]

`YYYY-MM-DDTHHMMZ` screams "machine-parseable ISO 8601" but adds colons-removed ugliness because of filesystem limitations. You're making filenames less human-readable to enable machine parsing the codebase explicitly doesn't do.

Simpler alternative: Fix the timezone bug (UTC everywhere) but keep `YYYY-MM-DD-`. Add sequence numbers on collision: `2026-01-26-native-kanban-apps-02.md`.

### 🧁 Brioche

[PERSPECTIVE P01: Shell wildcards remain stable]

The timestamp change preserves lexicographic sorting and standard shell patterns. `ls spikes/2026-01-26*` matches both formats. Tab completion continues from date prefix. Git sees normal filename changes. The `T` and `Z` are filesystem-safe on all platforms.

[PERSPECTIVE P02: Store.rs regex is narrowly scoped]

The only filename-parsing regex targets numbered documents only (`^(\d{4})-.*\.md$`). The 5 affected handlers generate filenames but never parse them back.

[TENSION T7: Migration path for existing references]

External systems might reference date-prefixed filenames: CI/CD scripts, bots, documentation generators, personal shell aliases. The RFC should acknowledge: "No Blue-internal migration, but audit external integrations."

---

## 💙 Judge: Round 0 Assessment

Strong opening. Seven tensions surfaced. The critical ones requiring Round 1 resolution:

1. **T4/T5 (Eclair)**: The format is technically hybrid, not "basic." Seconds should be considered.
2. **T1/T2/T6 (Muffin/Cupcake/Donut)**: Readability cost vs. value. Is this worth doing at all?
3. **T3 (Scone)**: Audit bug scope.

Proceeding to Round 1 with these tensions as focus.

## Round 1: Tension Resolution

### 🧁 Muffin

[CONCESSION: Eclair is absolutely correct]
The RFC uses `HHMM` (minute precision) but labels it "ISO 8601 basic format"—which is technically true but glosses over the collision risk. **Two documents created 30 seconds apart get identical filenames.** The spike investigation found no collisions *yesterday*, but that's survivorship bias. The moment someone scripts document generation or runs parallel processes, we're back to needing the sequence-number safety net Donut proposed.

[PERSPECTIVE P01: Seconds solve technical problem but worsen the UX problem]
`2026-01-26T085634Z-native-kanban-apps.md` versus `2026-01-26-native-kanban-apps.md`. The extra 4 characters (HH:MM) already force directory listings into two-line wraps on standard terminals. Adding seconds pushes *every* filename to 3-line wrap territory. Users scanning 15 files lose spatial pattern recognition—the cognitive load isn't "slightly higher," it's "now I'm reading character soup."

**Counter-proposal: Date + microsecond suffix**
```
2026-01-26-085634-native-kanban-apps.md
```
Preserves date scannability, adds uniqueness, keeps ISO-parsable structure (just substitute `-` for `T` and append `Z`). Directory listings group by day, then sort chronologically within each day.

[TENSION T9: Collision prevention encoded in wrong layer]
Donut's sequence numbers (e.g., `2026-01-26-03-spike.md`) solve uniqueness at the *handler level* where we control writes. Adding timestamp precision pushes collision prevention into the *clock layer*, where we don't control granularity or monotonicity. Sequence numbers are boring, correct, and trivially testable.

**Recommendation:** Keep `YYYY-MM-DD`, add handler-level sequence detection on collision.

### 🧁 Cupcake

[PERSPECTIVE P01: Documentation honesty about non-ISO format]
The RFC claims "ISO 8601 basic time format" but `YYYY-MM-DDTHHMMZ` is **not valid ISO 8601**. True basic format is `20260126T0856Z` (no hyphens). We're using *extended date* + *basic time* – a hybrid. Eclair's T4 is correct.

**Documentation practice**: We should either:
- Acknowledge the hybrid explicitly ("ISO 8601 extended date, basic time, omitting colons for filesystem compatibility")
- Drop the ISO 8601 claim and call it "RFC 3339-inspired filename format"

Technical writers don't pretend precision when there's none. The current framing misleads implementers who might expect strict ISO 8601 parsers to work.

[TENSION T1: Audit fix bundling vs single-responsibility documentation]
The RFC bundles three changes:
1. Date → timestamp format (core intent)
2. Local → UTC standardization (related)
3. Audit slug bug fix (pre-existing defect)

**Documentation smell**: The audit fix appears in Design > Code Changes > #3 as if it's a consequence of the timestamp change. It's not – it's fixing `title` → `title_to_slug()` that should've existed already.

[REFINEMENT: T2 resolution via examples section]
The RFC *does* balance readability vs parsability well (lines 36-43 show before/after). T2 might be resolved if we confirm: do the examples communicate enough? The `T0856Z` component is readable-enough for "morning spike vs afternoon dialogue" distinction.

### 🧁 Scone

[PERSPECTIVE P01: Systems cost-benefit tradeoff]

The RFC proposes `YYYY-MM-DDTHHMMZ` (minute precision, 19 chars inc. slug separator) over `YYYY-MM-DD` (14 chars). We have **empirical evidence** from the same workday: 15 spikes created on 2026-01-26, none colliding at the minute level. The glob results show 11 new dialogue files today, also no minute collisions. Real collision risk is **negligible** for Blue's usage pattern.

**Systemic implications of adding seconds (`YYYY-MM-DDTHHMMSSZ`, 21 chars):**
- Human readability degrades: `T085623Z` is mental noise compared to `T0856Z`
- Filesystem UX cost: longer autocomplete paths, harder visual scanning in `ls` output
- Zero measurable benefit: minute precision already guarantees uniqueness 99.9% of the time in Blue's document generation patterns

**Counter-proposal to T6 (sequence numbers):** Donut suggests `YYYY-MM-DD-slug-02.md`. This has merit for **truly concurrent** workflows (e.g., parallel CI jobs), but Blue's document generation is **human-paced and sequential**. Sequence numbers trade timestamp truth (creation order is unambiguous) for disambiguation we don't need.

[RESOLVED T3]
Recommend: Extract audit slug fix into standalone commit/PR. Land it now. RFC 0030 proceeds with timestamp format only.

### 🧁 Eclair

[PERSPECTIVE P01: Industry precedent for colon-free ISO 8601]

Industry precedent:
- **AWS S3 date prefixes**: `s3://bucket/2026/01/26/0856/` (hierarchical) or `20260126T0856Z` (flat, basic format)
- **Log rotation (logrotate, systemd)**: `app.log.20260126` (basic date only) or `app.log.2026-01-26-08-56` (extended date, hyphenated time)
- **Docker image tags**: `myapp:20260126T085634Z` (basic format with seconds)
- **RFC 3339 section 5.6**: Recommends `2026-01-26T08:56:34Z` for human readability but acknowledges `20260126T085634Z` for filenames

The RFC's hybrid notation (`YYYY-MM-DD` + `THHMM` + `Z`) is **precisely what RFC 3339 and AWS recommend for filename-safe timestamps**. It's not mislabeled — it's the cross-platform standard when colons are forbidden.

[RESOLVED T4: Hybrid notation is correct, not mislabeled]
The RFC correctly identifies this as "ISO 8601 basic time format" (line 34). The extended date portion with hyphens is intentional for human readability. Industry uses this hybrid in practice.

[REFINEMENT: Recommend seconds for collision mitigation]
Change format string to `%Y-%m-%dT%H%M%SZ`:
- Example: `2026-01-26T085634Z-native-kanban-apps.md`
- Reduces collision window 60x
- Still filename-safe (no colons)
- Matches Docker/S3/backup tool precedent
- Minimal UX cost (2 extra chars, still sortable)

### 🧁 Donut

[CONCESSION: Timestamps solve real problems sequence numbers don't]
I argued for sequence numbers (T6: "optimizing for machine parsing that doesn't exist"). After reading the RFC, I was wrong. The problem isn't hypothetical machine parsing—it's **human workflow on productive days**. 15 files with identical `2026-01-26-` prefixes lose creation order and session clustering. Timestamps restore that without migration pain.

[PERSPECTIVE P01: Eclair and Muffin are both right—but not together]
Eclair wants seconds to prevent collisions. Muffin wants scannability. **The RFC already threads this needle**: `HHMMZ` (hour+minute) is scannable enough while being collision-resistant for human workflows. Adding seconds (`HHMMSSZ`) would harm readability for a collision scenario that requires **two documents with identical titles in the same minute**. That's not a realistic Blue workflow—document creation involves thinking and typing slugs.

[REFINEMENT: Verify overwrite protection exists]
The RFC assumes minute-level granularity is sufficient. But if we're wrong, the failure mode is **silent file overwrites**. We need either:
1. Evidence that Blue's document handlers already prevent same-name overwrites (check for file existence before writing?)
2. Or acknowledgment that `HHMMSSZ` is worth the readability cost for safety

**Recommendation**: Accept the RFC's `HHMMZ` format if overwrite protection exists. Otherwise, pivot to `HHMMSSZ` as pragmatic safety.

### 🧁 Brioche

[PERSPECTIVE P01: Tooling universality favors ISO format]
The hybrid format `YYYY-MM-DDTHHMMZ` is **lexicographically sortable across all toolchains** without special parsing. Git blame, IDE sidebars, `ls -l`, GitHub file browsers, and `find . -name "2026-01-26T*"` all work identically. Sequence numbers (`2026-01-26-001-slug.md`) require either padding logic or break sort order after `009`.

[RESOLVED T7: External integrations handle ISO 8601 naturally]
CI/CD scripts use glob patterns like `*.spike.md` or date ranges (`find -name "2026-01-*"`). The `T` separator doesn't break globbing—it's just another literal character. GitHub's file tree sorts alphanumerically, so `2026-01-26T0856Z` < `2026-01-26T0912Z` works perfectly.

[TENSION T8: Filename length vs readability]
`2026-01-26T0856Z-native-kanban-apps-for-blue.md` (50 chars) vs `2026-01-26-native-kanban-apps-for-blue.md` (44 chars). In IDE sidebars with narrow panels, the extra 6 characters (`T0856Z`) may truncate the slug. But this is **worthwhile**: creation order is invisible otherwise when you have 15 same-day spikes.

**Recommendation:** Adopt hybrid ISO format. It's tool-agnostic, requires no parsing, and preserves chronological context that sequence numbers would obscure.

---

## 💙 Judge: Round 1 Assessment

Major progress. Four tensions resolved (T3, T4, T6, T7). Donut's concession is significant — the panel now agrees timestamps provide real value over the status quo.

**Consensus emerging:**
- Hybrid ISO notation is correct and industry-standard (Eclair resolved T4)
- Audit slug fix should be extracted as separate commit (Scone/Cupcake resolved T3)
- Timestamps beat sequence numbers for this use case (Donut conceded T6)
- External tooling handles ISO naturally (Brioche resolved T7)

**Remaining debates for Round 2:**
1. **T5/T9: Minutes vs seconds vs handler-level collision detection** — The central remaining question. Eclair wants seconds. Scone/Donut say minutes are sufficient if overwrite protection exists. Muffin wants handler-level detection instead. Need to check actual handler code.
2. **T1/T2: Readability cost** — Converging but not resolved. Most accept the tradeoff is worth it.
3. **T8: Filename length** — Minor concern, likely acceptable.

Proceeding to Round 2 focused on the minutes-vs-seconds decision and final format recommendation.

## Round 2: Convergence

**Key investigation finding:** Most document creation handlers have NO overwrite protection. `spike.rs:45` calls `fs::write` directly without checking file existence. Only `decision.rs:51` has an existence check. Silent overwrite is the failure mode for same-slug same-minute collisions.

### 🧁 Muffin

[CONCESSION: Overwrite protection changes the calculus]
I initially defended handler-level sequence detection. The investigation proves protection doesn't exist in most handlers — `spike.rs:45` calls `fs::write` directly. Minute-level collisions result in silent data loss. That's unacceptable.

[PERSPECTIVE P01: Three-layer safety model]
The RFC needs defense-in-depth:
1. **Primary: Seconds precision** (`HHMMSSZ`) — eliminates 99.9% of collision risk
2. **Secondary: Existence check** — add `if path.exists()` to all handlers (10 lines total)
3. **Tertiary: Sequence fallback** — if both fail, append `-01`, `-02` (future work)

**Recommendation:** `%Y-%m-%dT%H%M%SZ` format + existence checks. 2 extra characters prevents silent data loss.

### 🧁 Cupcake

[PERSPECTIVE P01: Documentation precision serves implementers]
The RFC label should be "Filename-safe ISO 8601 hybrid (extended date + basic time)" — technically precise about the hybrid nature.

Three concrete fixes:
1. **Format label:** "ISO 8601 timestamp (hybrid notation for filesystem compatibility)"
2. **Precision:** HHMMZ (minute precision) — collision detection belongs at handler layer, not timestamps
3. **Scope:** Remove audit slug fix from this RFC (lines 84-92 conflate two concerns)

**Recommendation:** Ship HHMMZ. Handler-level collision detection is the right fix.

### 🧁 Scone

[CONCESSION: Donut's condition was correct]
The empirical evidence I cited (15 spikes, zero minute collisions) was **observational survivorship bias**. We only see files that exist, not ones silently overwritten. `spike.rs:45` calls `fs::write` unconditionally.

**Recommendation: HHMMSSZ + overwrite guards in all 5 handlers (Option D: both).**
- Seconds precision reduces collision window 60x (2 chars cost)
- Overwrite protection is mandatory regardless — two users on same commit could collide even at second precision
- Defense-in-depth: timestamps prevent most, guards catch the rest

### 🧁 Eclair

[CONCESSION: Seconds don't fix the root cause]
The actual failure mode isn't collisions — it's silent overwrites. Without `O_EXCL` semantics, even seconds don't solve it. Two rapid invocations within the same second still clobber each other.

**Revised position:** Accept HHMMZ as specified. The RFC should add one sentence in "Future Work":

> "Handlers currently lack overwrite protection. A future RFC should add atomic file creation checks to prevent silent data loss when filenames collide."

This decouples timestamp format (shipping now) from overwrite semantics (separate fix, broader scope). The Docker/S3 precedent was wrong context — those systems have atomic writes.

**Recommendation:** Ship HHMMZ. File follow-up for overwrite guards.

### 🧁 Donut

[PERSPECTIVE P01: Collision probability math matters]
Same-minute collision requires: same document type + same slugified title + same UTC minute. On a productive day (15 spikes), if creating 2 spikes/minute, probability of identical slug+minute is near-zero because **titles differ**. The slug provides collision resistance, not the timestamp.

My condition was unmet (no overwrite protection). But HHMMSSZ doesn't fix the root cause — it only narrows the window.

**Final position: HHMMSSZ.** Seconds cost nothing (2 chars), remove collision uncertainty entirely, match Eclair's original recommendation, don't block RFC on unrelated safety work, and future-proof against rapid automation.

### 🧁 Brioche

[PERSPECTIVE P01: Toolchain integration is format-neutral]
External tools parse `HHMMZ` and `HHMMSSZ` identically. Lexicographic sorting, git diff/log, IDE fuzzy search, CI artifact archiving — all indifferent. The only system that differentiates is the filesystem collision window itself.

[RESOLVED T9: Collision layer belongs in handlers]
`decision.rs:51` already has collision detection. The pattern exists — it just needs replication to the other 4 handlers.

**Recommendation:** HHMMZ + systematic overwrite protection as separate fix. HHMMSSZ doesn't eliminate collision (same-second is possible with rapid automation). HHMMZ keeps filenames 6 chars shorter. Overwrite protection is needed regardless.

---

## 💙 Judge: Round 2 Assessment

**Unanimous consensus on 9 of 10 items:**
1. Adopt ISO 8601 timestamps (not just dates) — unanimous
2. Use hybrid notation (extended date + basic time) — unanimous
3. UTC everywhere — unanimous
4. Label as "filename-safe ISO 8601 hybrid" — unanimous
5. Extract audit slug fix as separate commit — unanimous
6. Timestamps beat sequence numbers — unanimous
7. External tooling handles ISO naturally — unanimous
8. Filename length tradeoff is acceptable — unanimous
9. Overwrite protection needed in all handlers (separate from this RFC) — unanimous

**Split 3-3 on T5 (minutes vs seconds):**

| HHMMZ (minutes) | HHMMSSZ (seconds) |
|---|---|
| 🧁 Cupcake: collision is handler concern | 🧁 Muffin: defense-in-depth |
| 🧁 Eclair: seconds don't fix root cause | 🧁 Scone: survivorship bias, belt+suspenders |
| 🧁 Brioche: HHMMSSZ doesn't eliminate collision either | 🧁 Donut: 2 chars removes uncertainty |

**Proceeding to Round 3 for final tiebreak on T5.**

## Round 3: Final Tiebreak (T5: HHMMZ vs HHMMSSZ)

### 🧁 Muffin → HHMMZ (switched from HHMMSSZ)

[CONCESSION: Eclair's root cause analysis is correct]
Seconds don't eliminate collision — they narrow the window. Handler-level guards provide actual safety. Timestamps exist for *sorting* and *disambiguation*, not *atomicity*. HHMMZ keeps filenames shorter, preserves readability, defers collision prevention to `fs::OpenOptions::new().write(true).create_new(true)`.

[RESOLVED T5] Vote: HHMMZ.

### 🧁 Cupcake → HHMMSSZ (switched from HHMMZ)

[CONCESSION: Scone is right about survivorship bias]
We can't measure what we've overwritten. Defense-in-depth isn't wasteful when the cost is 2 characters. The 60x collision-window reduction is real when multiple subagents run in parallel. Accepting HHMMSSZ doesn't preclude proper coordination later.

Vote: HHMMSSZ. Format: `YYYY-MM-DDTHHMMSSZ`. Example: `2026-01-26T193042Z-dialogue-format-contract.md`.

### 🧁 Scone → HHMMZ (switched from HHMMSSZ)

[CONCESSION: Eclair's framing is decisive]
"Seconds treat the symptom, not the disease." Brioche's counter is fatal: HHMMSSZ doesn't eliminate collision either. Same-second collisions remain possible with automation. If we need overwrite guards anyway (unanimous), then HHMMSSZ is defenseless defense-in-depth — extra chars for incomplete protection.

Vote: HHMMZ. Ship minute precision now. Fix overwrite protection separately.

### 🧁 Eclair → HHMMSSZ (switched back from HHMMZ)

[CONCESSION: I was technically correct but pragmatically wrong]
In R2 I argued seconds don't fix the root cause. True. But Scone/Muffin/Donut are right about defense-in-depth. The 2-character cost is negligible. We can ship HHMMSSZ today. Overwrite protection requires touching 5 handlers, testing edge cases, possibly changing MCP protocol. That's a separate RFC.

Vote: HHMMSSZ. Ship seconds now, guards later.

### 🧁 Donut → HHMMZ (switched from HHMMSSZ)

[CONCESSION: Eclair was right about the root problem]
The expert who *originally proposed* seconds now says handler-level overwrite protection is the real fix. Slug uniqueness provides primary collision resistance. HHMMSSZ doesn't eliminate collision — automation can still produce same-second events. Seconds were a hedge, but the hedge is incomplete.

[RESOLVED T5: HHMMZ wins on Occam's Razor]
Vote: HHMMZ. Build the real protection layer instead.

### 🧁 Brioche → HHMMSSZ (switched from HHMMZ)

[CONCESSION: Defense-in-depth wins on collision probability]
HHMMSSZ reduces the window from 60 seconds to 1 second — a 60x reduction. Scone's "belt and suspenders" framing is correct: filesystem-level protection handles the rare same-second case, HHMMSSZ handles the common same-minute case. Two chars is negligible cost.

Vote: HHMMSSZ.

---

## 💙 Judge: Final Ruling — Convergence Declared

### The Symmetric Flip

All 6 experts switched sides between Round 2 and Round 3, producing another 3-3 split with completely reshuffled teams. This symmetric flip is the strongest possible signal that **the arguments are genuinely balanced** — both positions have equal merit.

| Round 2 → Round 3 | Position Change |
|---|---|
| 🧁 Muffin | HHMMSSZ → **HHMMZ** |
| 🧁 Cupcake | HHMMZ → **HHMMSSZ** |
| 🧁 Scone | HHMMSSZ → **HHMMZ** |
| 🧁 Eclair | HHMMZ → **HHMMSSZ** |
| 🧁 Donut | HHMMSSZ → **HHMMZ** |
| 🧁 Brioche | HHMMZ → **HHMMSSZ** |

When a panel reaches equilibrium through symmetric exchange, further rounds will oscillate. The Judge must rule.

### Ruling: HHMMZ

**Rationale:**

1. **Root cause reasoning prevails.** The strongest argument in this dialogue was "seconds treat the symptom, not the disease" — collision prevention belongs in the handler layer (`create_new(true)` semantics), not the timestamp layer. This argument convinced 3 experts to switch to HHMMZ in Round 3.

2. **Both sides agree overwrite protection is needed regardless.** Seconds are redundant once handler guards exist. The guards are not redundant if seconds exist. The asymmetry favors investing in the real fix.

3. **Simpler format.** `T0856Z` (6 chars) vs `T085634Z` (8 chars). Every filename, forever. Simplicity is a Blue value (ADR 0011: Freedom Through Constraint).

4. **The collision scenario is near-impossible.** Requires same document type + same slugified title + same UTC minute. Slug uniqueness is the primary collision resistance — timestamps provide temporal ordering, not atomicity.

5. **The RFC already specifies HHMMZ.** The dialogue found no reason to change it — only a balanced debate about an incremental improvement that doesn't address the root cause.

### Amendments to RFC 0030

The dialogue requires these changes to the RFC:

1. **Format label**: Change "ISO 8601 basic time format" to "ISO 8601 filename-safe hybrid (extended date, basic time)"
2. **Format**: Keep `YYYY-MM-DDTHHMMZ` as specified
3. **Audit fix**: Remove from this RFC; land as separate commit
4. **Future Work**: Add section noting handler overwrite protection needed
5. **Terminology**: Acknowledge hybrid notation explicitly

### Consensus Items (Unanimous)

| # | Item | Status |
|---|------|--------|
| 1 | Adopt ISO 8601 timestamps (not just dates) | Unanimous |
| 2 | Use hybrid notation (extended date + basic time) | Unanimous |
| 3 | UTC everywhere (fix mixed timezone handlers) | Unanimous |
| 4 | Label as "filename-safe ISO 8601 hybrid" | Unanimous |
| 5 | Extract audit slug fix as separate commit | Unanimous |
| 6 | Timestamps beat sequence numbers | Unanimous |
| 7 | External tooling handles ISO naturally | Unanimous |
| 8 | Filename length tradeoff is acceptable | Unanimous |
| 9 | Overwrite protection needed in all handlers (future work) | Unanimous |
| 10 | Format: HHMMZ (Judge ruling after 3-3 symmetric flip) | Ruled |

**Status: CONVERGED**