pdurlej/platform

Fork 0

Phase 08+ scope: IronKey Keypad 200C as Tier 2 hardware-encrypted storage for Włóczykij vault #180

New issue

Open

opened 2026-05-11 07:47:58 +02:00 by claude · 4 comments

claude commented

2026-05-11 07:47:58 +02:00

Collaborator

Context

Per operator voice-note 2026-05-11 07:45 + image IMG_9781.HEIC (Kingston IronKey Keypad 200C 16GB, purchased Black Friday November 2025):

"Włóczykij. Docelowo powinien być moim backupem albo jedynym miejscem, gdzie są pliki Włóczykij. Tak żeby mój markdown w idealnym świecie mógł być zawsze ze mną w kluczach. Moja baza obsidianowa, mogę ją podłączyć gdziekolwiek jestem, wpisać fizyczny kod i tam mieć naprawdę ekstremalnie dobrą prywatność tych wszystkich notatek. Wyobrażam sobie to tak, że mam jakiś lokalny model językowy. Pracuję na nim. Robię w Włóczykij zgodnie z guard rails, które stworzymy — które są wypadkową KOSA 2. Potem ewentualnie jeśli coś będzie widać że importować, no to można zaimportować."

This is a 3-tier privacy architecture upgrade over the original Włóczykij scope in issue #178. The IronKey provides hardware-encrypted Tier 2 storage with physical forcing-function for context switching.

Hardware specification

Kingston IronKey Keypad 200C, 16GB, USB-C

Property	Value
Encryption	AES-256 XTS, hardware (firmware-implemented)
Certification	FIPS 140-3 Level 3 (Pending)
PIN entry	Physical keypad on device (defeats software keyloggers)
Brute-force protection	10 consecutive failed PINs → crypto-erase
Connector	USB-C (3.2 Gen 1)
Speed	~145MB/s read, ~115MB/s write
Capacity	16GB (more than sufficient for years of markdown vault)
Battery	Built-in rechargeable (for PIN entry without host power)
Multi-PIN	Admin + User PINs supported
Read-only mode	Togglable; operator can mount as read-only when LLM-only access needed
Warranty	5+1 years
Operating temp	0°C to 60°C

3-tier privacy architecture

Tier	Vault	Storage	Agent access	Operator action to enter
0 — agent-collaborative	`Iskra-i-Piotr/*` (excluding hard_private folders)	M1 + RS2000/VPS1000 mirrors + Synology + encrypted-Dropbox (per ADR-0013)	YES per ADR-0010 capabilities.yaml	none (default)
1 — operator-on-disk	`Iskra-i-Piotr/{Journal,Finance,Family,Health}` (per ADR-0010 hard_private mapping, amended per operator 2026-05-11)	same M1+mirror chain (BUT path-denylisted from agents per capabilities.yaml)	NO (path-policy denied)	none; just operator vault access
2 — operator-on-physical-key	`/Volumes/IRONKEY/Włóczykij/*`	Kingston IronKey 200C, 16GB, AES-256 XTS hardware-encrypted, FIPS 140-3 Level 3	local-admin LLM ONLY (M1 local; gemma-3 per ADR-0010); ONLY when IronKey physically mounted	physical: insert USB → enter PIN on device → mount

Why this is sound architecture

Physical forcing-function for context switch. No software lock can be accidentally bypassed by drag-drop into chat. IronKey-in-drawer = vault literally absent from M1 disk.
Defense-in-depth. Even if M1 is compromised (malware, theft), attacker cannot auto-mount Włóczykij because:
- Device requires PIN entered on its physical keypad
- PIN is not stored on M1 or in any software credential store
- 10 wrong PINs → crypto-erase
Air-gapped-by-default. Tier 2 content is not on M1 disk except when IronKey is mounted. Not in cloud (per operator's voice-note: not in encrypted Dropbox by default — see Open Question #1 below). Not in Synology. Operator physically controls when Tier 2 content "exists" on a computer.
Local LLM compatibility. ADR-0010 local-admin LLM tier (gemma-3 on M1) runs locally; supports Tier 2 workflows because both LLM and content are on operator's M1 (no cloud dispatch needed). KOS2-derived guard rails apply.
Operator portability. "Markdown zawsze ze mną w kluczach" — operator can mount on any USB-C-capable computer (not just M1) to access Tier 2 content. Useful when traveling without M1.

Workflow (operator-mode based)

Daily mode (IronKey in drawer)

M1 boot → Iskra-i-Piotr available (Tier 0 + Tier 1)
agents work as usual (Tier 0 access per capabilities.yaml)
Tier 2 content physically absent from M1

Privacy mode (IronKey mounted)

operator inserts IronKey → enters PIN on device keypad
M1 mounts /Volumes/IRONKEY/ (read-write OR read-only per operator choice)
local-admin LLM (gemma-3) starts in "Włóczykij scope"
  - vault_roots.accessible adds /Volumes/IRONKEY/Włóczykij/
  - cloud agents (Hermes, Ollama swarm, etc.) blocked at wrapper level
  - KOS2-guard rails apply: preview-first, no-exfil, audit-log
operator works on intimate content
operator ejects IronKey → vault disappears from M1
local-admin LLM returns to default scope (Iskra-i-Piotr only)

Promotion path (Iskra-i-Piotr → Włóczykij)

Something in Iskra-i-Piotr earns elevation (operator decides)
  → operator mounts IronKey
  → operator manually copies file to /Volumes/IRONKEY/Włóczykij/
  → operator deletes source from Iskra-i-Piotr (or leaves; per-file)
  → ejects IronKey
From now on, that content lives on IronKey only.

Import path (Włóczykij → Iskra-i-Piotr) — rare

Operator decides intimate content earned demotion to operator-on-disk Tier 1
  → mount IronKey, copy file out, eject
  → file lives in Iskra-i-Piotr/{Journal,...} with frontmatter sensitivity tier

Integration with existing architecture

ADR-0010 (local-admin LLM tier) — amendment

ops/local-admin/capabilities.yaml gets new vault_roots field (already proposed in issue #178 for Iskra-i-Piotr/Włóczykij split; this issue adds IronKey path):

vault_roots:
  accessible_default:
    - "/Users/pd/Obsidian/Iskra-i-Piotr/"
  accessible_when_mounted:
    - "/Volumes/IRONKEY/Włóczykij/"      # only when IronKey physically mounted
  denylist:
    - "/Users/pd/Obsidian/Włóczykij/"    # on-disk mirror; NOT primary
    - (other operator-confirmed denylists)

local-admin LLM runtime check: at every read attempt, verify /Volumes/IRONKEY/ is mounted; if not, refuse Tier 2 access.

ADR-0013 (4th replica) — amendment / OPEN QUESTION

Does Tier 2 content (Włóczykij) join the 4th replica chain?

Option A: NO — IronKey is the only canonical storage; loss = total loss; operator accepts the trade-off for maximum privacy.
Option B: YES (encrypted Dropbox only) — IronKey content periodically backed up to encrypted Dropbox via tar+age pipeline (existing per ADR-0013); Synology + RS2000 + VPS1000 are NOT included (those see encrypted blob only if at all).
Option C: YES (Synology + encrypted Dropbox) — full 4th-replica chain; Tier 2 content is just "more thoroughly encrypted" but multi-replica.

Operator's voice-note 2026-05-11 suggested Option A or B. Operator decides; this issue captures the question.

Issue #178 (Włóczykij second-tier vault)

Issue #178 assumed /Users/pd/Obsidian/Włóczykij/ (M1 disk) as canonical. This issue supersedes that location: IronKey-mounted path is canonical; M1-disk mirror is optional (if any).

scripts/vault-sync-iskra-to-wloczykij.sh (proposed in #178) becomes:

IF operator wants M1-disk mirror of Włóczykij: sync target stays /Users/pd/Obsidian/Włóczykij/ for redundancy
IF operator chooses IronKey-only: sync target is /Volumes/IRONKEY/Włóczykij/, runs only when mounted

Operator picks.

KOS2-derived guard rails

Per operator (voice-note 2026-05-11): "Lokalny model językowy. Robię w Włóczykij zgodnie z guard rails, które stworzymy — które są wypadkową KOSA 2."

KOS2 (github.com/pdurlej/KOS2) provides the prior-art reference for vault janitor / hygiene patterns. Tier 2 KOS2-derived rules (Phase 08+ design):

Preview-first for all mutations (no auto-apply)
No exfil: local-admin LLM cannot dispatch Tier 2 content to ANY cloud (Ollama Cloud, Honcho.dev, OpenAI, Anthropic, anything not on M1)
Audit log: every Tier 2 read + every operator-approved mutation logged to /Volumes/IRONKEY/.iskra-audit/YYYY-MM-DD.ndjson (audit-on-IronKey, not on M1 — audit stays with vault)
Read-only by default: IronKey mounted read-only unless operator explicitly toggles writeable
Mount duration limit: auto-eject after X minutes of inactivity? (Operator preference; default 30 min)

Open questions (operator decides)

Backup of Tier 2 content: A (none, IronKey only) / B (encrypted Dropbox only) / C (full chain)?
M1-disk mirror at /Users/pd/Obsidian/Włóczykij/: keep (redundancy) or remove (IronKey-only-canonical)?
PIN management: where is the IronKey PIN backed up? (Not on M1 — defeats purpose. 1Password? Printed paper? Operator memory only with multiple-failed-PIN risk?)
2nd IronKey for hardware-backup: at €100 ish per Kingston Keypad 200C, second device as full mirror is cheap insurance against hardware failure. Operator decides.
Read-only vs read-write default: most ADHD-safe is read-only-by-default; explicit toggle to write.
KOS2 guard-rail port timeline: when does Phase 08+ implementation of vault-janitor for Tier 2 begin? (Likely depends on Phase 06 prune + Phase 07 local-admin tier completion.)

Scope (this issue produces Phase 08+ tickets)

Ticket A — Hardware setup runbook

docs/runbooks/ironkey-setup.md:

Initial PIN setup (admin + user)
Format as Mac-friendly filesystem (APFS-encrypted? OR exfat for cross-platform?)
Initial Włóczykij directory structure
Backup PIN to secondary safe location (operator chooses)
Optional: 2nd IronKey as hardware-backup mirror

Ticket B — Local-admin LLM amendment (extends ADR-0010)

ops/local-admin/capabilities.yaml adds accessible_when_mounted semantics. Wrapper code at runtime checks os.path.ismount('/Volumes/IRONKEY/') before granting Tier 2 access.

Ticket C — Optional encrypted Dropbox backup of IronKey content

If operator chooses Option B above, add scripts/4th-replica/sync-ironkey-to-dropbox.sh (runs only when IronKey mounted; encrypts via age before upload).

Ticket D — KOS2-derived guard rails for Tier 2

Phase 08+ — adapt KOS2 patterns for IronKey vault janitor + privacy-aware mutations.

Phase

Phase 08+. Most likely sequencing:

Phase 06 prune completes
Phase 07 implementation lands (attention-dispatcher, local-admin tier, vault janitor on Iskra-i-Piotr)
Phase 08 implements Włóczykij + IronKey integration (this issue's tickets A-D)

Could be earlier IF operator wants to use IronKey for current intimate notes BEFORE Phase 07 — that's a Ticket A "operator-driven manual" path with no automation, just hardware setup + manual file moves.

Acceptance criteria

Issue captures the 3-tier architecture (this body satisfies)
Operator answers 6 Open Questions above
Cross-link added to issue #178 (this issue supersedes #178's storage location)
When Phase 08+ activates: 4 sub-tickets opened from this scope

Refs

Operator voice-note 2026-05-11 07:45 + image IMG_9781.HEIC
ADR-0010 (local-admin LLM tier) — extends with vault_roots field
ADR-0013 (4th replica) — possible amendment for Option B/C
Issue #178 (Włóczykij second-tier vault) — superseded by this for storage location
KOS2 (github.com/pdurlej/KOS2) — guard-rail prior art
Kingston IronKey Keypad 200C product page: https://www.kingston.com/en/usb-flash-drives/ironkey-keypad-200c

Coordination

Lane: Phase 08+ design (advisor)
Owner: operator (hardware setup + PIN management); claude-orchestrator (architecture documentation)
Codex: not involved until Phase 08+ implementation

Role: advisor (claude)
Captured for: operator's "szaleństwo z przymrużeniem oka" architectural intuition — "żebyś wiedział, możesz to zapisać gdzieś jako komentarz jaki jest jakby myśl, jaka jest struktura tutaj jakby danych wokół tego"

## Context Per operator voice-note 2026-05-11 07:45 + image IMG_9781.HEIC (Kingston IronKey Keypad 200C 16GB, purchased Black Friday November 2025): > *"Włóczykij. Docelowo powinien być moim backupem albo jedynym miejscem, gdzie są pliki Włóczykij. Tak żeby mój markdown w idealnym świecie mógł być zawsze ze mną w kluczach. Moja baza obsidianowa, mogę ją podłączyć gdziekolwiek jestem, wpisać fizyczny kod i tam mieć naprawdę ekstremalnie dobrą prywatność tych wszystkich notatek. Wyobrażam sobie to tak, że mam jakiś lokalny model językowy. Pracuję na nim. Robię w Włóczykij zgodnie z guard rails, które stworzymy — które są wypadkową KOSA 2. Potem ewentualnie jeśli coś będzie widać że importować, no to można zaimportować."* This is a **3-tier privacy architecture** upgrade over the original Włóczykij scope in issue #178. The IronKey provides **hardware-encrypted Tier 2 storage** with physical forcing-function for context switching. ## Hardware specification **Kingston IronKey Keypad 200C, 16GB, USB-C** | Property | Value | |----------|-------| | Encryption | AES-256 XTS, hardware (firmware-implemented) | | Certification | FIPS 140-3 Level 3 (Pending) | | PIN entry | Physical keypad on device (defeats software keyloggers) | | Brute-force protection | 10 consecutive failed PINs → crypto-erase | | Connector | USB-C (3.2 Gen 1) | | Speed | ~145MB/s read, ~115MB/s write | | Capacity | 16GB (more than sufficient for years of markdown vault) | | Battery | Built-in rechargeable (for PIN entry without host power) | | Multi-PIN | Admin + User PINs supported | | Read-only mode | Togglable; operator can mount as read-only when LLM-only access needed | | Warranty | 5+1 years | | Operating temp | 0°C to 60°C | ## 3-tier privacy architecture | Tier | Vault | Storage | Agent access | Operator action to enter | |------|-------|---------|--------------|--------------------------| | **0 — agent-collaborative** | `Iskra-i-Piotr/*` (excluding hard_private folders) | M1 + RS2000/VPS1000 mirrors + Synology + encrypted-Dropbox (per ADR-0013) | YES per ADR-0010 capabilities.yaml | none (default) | | **1 — operator-on-disk** | `Iskra-i-Piotr/{Journal,Finance,Family,Health}` (per ADR-0010 hard_private mapping, amended per operator 2026-05-11) | same M1+mirror chain (BUT path-denylisted from agents per capabilities.yaml) | NO (path-policy denied) | none; just operator vault access | | **2 — operator-on-physical-key** | `/Volumes/IRONKEY/Włóczykij/*` | **Kingston IronKey 200C, 16GB, AES-256 XTS hardware-encrypted, FIPS 140-3 Level 3** | local-admin LLM ONLY (M1 local; gemma-3 per ADR-0010); ONLY when IronKey physically mounted | physical: insert USB → enter PIN on device → mount | ## Why this is sound architecture 1. **Physical forcing-function for context switch.** No software lock can be accidentally bypassed by drag-drop into chat. IronKey-in-drawer = vault literally absent from M1 disk. 2. **Defense-in-depth.** Even if M1 is compromised (malware, theft), attacker cannot auto-mount Włóczykij because: - Device requires PIN entered on its physical keypad - PIN is not stored on M1 or in any software credential store - 10 wrong PINs → crypto-erase 3. **Air-gapped-by-default.** Tier 2 content is not on M1 disk except when IronKey is mounted. Not in cloud (per operator's voice-note: not in encrypted Dropbox by default — see Open Question #1 below). Not in Synology. Operator physically controls when Tier 2 content "exists" on a computer. 4. **Local LLM compatibility.** ADR-0010 local-admin LLM tier (gemma-3 on M1) runs locally; supports Tier 2 workflows because both LLM and content are on operator's M1 (no cloud dispatch needed). KOS2-derived guard rails apply. 5. **Operator portability.** "Markdown zawsze ze mną w kluczach" — operator can mount on any USB-C-capable computer (not just M1) to access Tier 2 content. Useful when traveling without M1. ## Workflow (operator-mode based) ### Daily mode (IronKey in drawer) ``` M1 boot → Iskra-i-Piotr available (Tier 0 + Tier 1) agents work as usual (Tier 0 access per capabilities.yaml) Tier 2 content physically absent from M1 ``` ### Privacy mode (IronKey mounted) ``` operator inserts IronKey → enters PIN on device keypad M1 mounts /Volumes/IRONKEY/ (read-write OR read-only per operator choice) local-admin LLM (gemma-3) starts in "Włóczykij scope" - vault_roots.accessible adds /Volumes/IRONKEY/Włóczykij/ - cloud agents (Hermes, Ollama swarm, etc.) blocked at wrapper level - KOS2-guard rails apply: preview-first, no-exfil, audit-log operator works on intimate content operator ejects IronKey → vault disappears from M1 local-admin LLM returns to default scope (Iskra-i-Piotr only) ``` ### Promotion path (Iskra-i-Piotr → Włóczykij) ``` Something in Iskra-i-Piotr earns elevation (operator decides) → operator mounts IronKey → operator manually copies file to /Volumes/IRONKEY/Włóczykij/ → operator deletes source from Iskra-i-Piotr (or leaves; per-file) → ejects IronKey From now on, that content lives on IronKey only. ``` ### Import path (Włóczykij → Iskra-i-Piotr) — rare ``` Operator decides intimate content earned demotion to operator-on-disk Tier 1 → mount IronKey, copy file out, eject → file lives in Iskra-i-Piotr/{Journal,...} with frontmatter sensitivity tier ``` ## Integration with existing architecture ### ADR-0010 (local-admin LLM tier) — amendment `ops/local-admin/capabilities.yaml` gets new `vault_roots` field (already proposed in issue #178 for Iskra-i-Piotr/Włóczykij split; this issue adds IronKey path): ```yaml vault_roots: accessible_default: - "/Users/pd/Obsidian/Iskra-i-Piotr/" accessible_when_mounted: - "/Volumes/IRONKEY/Włóczykij/" # only when IronKey physically mounted denylist: - "/Users/pd/Obsidian/Włóczykij/" # on-disk mirror; NOT primary - (other operator-confirmed denylists) ``` `local-admin LLM` runtime check: at every read attempt, verify `/Volumes/IRONKEY/` is mounted; if not, refuse Tier 2 access. ### ADR-0013 (4th replica) — amendment / OPEN QUESTION Does Tier 2 content (Włóczykij) join the 4th replica chain? - **Option A**: NO — IronKey is the only canonical storage; loss = total loss; operator accepts the trade-off for maximum privacy. - **Option B**: YES (encrypted Dropbox only) — IronKey content periodically backed up to encrypted Dropbox via tar+age pipeline (existing per ADR-0013); Synology + RS2000 + VPS1000 are NOT included (those see encrypted blob only if at all). - **Option C**: YES (Synology + encrypted Dropbox) — full 4th-replica chain; Tier 2 content is just "more thoroughly encrypted" but multi-replica. Operator's voice-note 2026-05-11 suggested **Option A or B**. Operator decides; this issue captures the question. ### Issue #178 (Włóczykij second-tier vault) Issue #178 assumed `/Users/pd/Obsidian/Włóczykij/` (M1 disk) as canonical. **This issue supersedes that location**: IronKey-mounted path is canonical; M1-disk mirror is optional (if any). `scripts/vault-sync-iskra-to-wloczykij.sh` (proposed in #178) becomes: - IF operator wants M1-disk mirror of Włóczykij: sync target stays `/Users/pd/Obsidian/Włóczykij/` for redundancy - IF operator chooses IronKey-only: sync target is `/Volumes/IRONKEY/Włóczykij/`, runs only when mounted Operator picks. ## KOS2-derived guard rails Per operator (voice-note 2026-05-11): *"Lokalny model językowy. Robię w Włóczykij zgodnie z guard rails, które stworzymy — które są wypadkową KOSA 2."* KOS2 (`github.com/pdurlej/KOS2`) provides the prior-art reference for vault janitor / hygiene patterns. Tier 2 KOS2-derived rules (Phase 08+ design): - **Preview-first** for all mutations (no auto-apply) - **No exfil**: local-admin LLM cannot dispatch Tier 2 content to ANY cloud (Ollama Cloud, Honcho.dev, OpenAI, Anthropic, anything not on M1) - **Audit log**: every Tier 2 read + every operator-approved mutation logged to `/Volumes/IRONKEY/.iskra-audit/YYYY-MM-DD.ndjson` (audit-on-IronKey, not on M1 — audit stays with vault) - **Read-only by default**: IronKey mounted read-only unless operator explicitly toggles writeable - **Mount duration limit**: auto-eject after X minutes of inactivity? (Operator preference; default 30 min) ## Open questions (operator decides) 1. **Backup of Tier 2 content**: A (none, IronKey only) / B (encrypted Dropbox only) / C (full chain)? 2. **M1-disk mirror at `/Users/pd/Obsidian/Włóczykij/`**: keep (redundancy) or remove (IronKey-only-canonical)? 3. **PIN management**: where is the IronKey PIN backed up? (Not on M1 — defeats purpose. 1Password? Printed paper? Operator memory only with multiple-failed-PIN risk?) 4. **2nd IronKey for hardware-backup**: at €100 ish per Kingston Keypad 200C, second device as full mirror is cheap insurance against hardware failure. Operator decides. 5. **Read-only vs read-write default**: most ADHD-safe is read-only-by-default; explicit toggle to write. 6. **KOS2 guard-rail port timeline**: when does Phase 08+ implementation of vault-janitor for Tier 2 begin? (Likely depends on Phase 06 prune + Phase 07 local-admin tier completion.) ## Scope (this issue produces Phase 08+ tickets) ### Ticket A — Hardware setup runbook `docs/runbooks/ironkey-setup.md`: - Initial PIN setup (admin + user) - Format as Mac-friendly filesystem (APFS-encrypted? OR exfat for cross-platform?) - Initial Włóczykij directory structure - Backup PIN to secondary safe location (operator chooses) - Optional: 2nd IronKey as hardware-backup mirror ### Ticket B — Local-admin LLM amendment (extends ADR-0010) `ops/local-admin/capabilities.yaml` adds `accessible_when_mounted` semantics. Wrapper code at runtime checks `os.path.ismount('/Volumes/IRONKEY/')` before granting Tier 2 access. ### Ticket C — Optional encrypted Dropbox backup of IronKey content If operator chooses Option B above, add `scripts/4th-replica/sync-ironkey-to-dropbox.sh` (runs only when IronKey mounted; encrypts via age before upload). ### Ticket D — KOS2-derived guard rails for Tier 2 Phase 08+ — adapt KOS2 patterns for IronKey vault janitor + privacy-aware mutations. ## Phase Phase 08+. Most likely sequencing: - Phase 06 prune completes - Phase 07 implementation lands (attention-dispatcher, local-admin tier, vault janitor on Iskra-i-Piotr) - Phase 08 implements Włóczykij + IronKey integration (this issue's tickets A-D) Could be earlier IF operator wants to use IronKey for current intimate notes BEFORE Phase 07 — that's a Ticket A "operator-driven manual" path with no automation, just hardware setup + manual file moves. ## Acceptance criteria - [ ] Issue captures the 3-tier architecture (this body satisfies) - [ ] Operator answers 6 Open Questions above - [ ] Cross-link added to issue #178 (this issue supersedes #178's storage location) - [ ] When Phase 08+ activates: 4 sub-tickets opened from this scope ## Refs - Operator voice-note 2026-05-11 07:45 + image IMG_9781.HEIC - ADR-0010 (local-admin LLM tier) — extends with `vault_roots` field - ADR-0013 (4th replica) — possible amendment for Option B/C - Issue #178 (Włóczykij second-tier vault) — superseded by this for storage location - KOS2 (github.com/pdurlej/KOS2) — guard-rail prior art - Kingston IronKey Keypad 200C product page: https://www.kingston.com/en/usb-flash-drives/ironkey-keypad-200c ## Coordination - Lane: Phase 08+ design (advisor) - Owner: operator (hardware setup + PIN management); claude-orchestrator (architecture documentation) - Codex: not involved until Phase 08+ implementation **Role:** advisor (claude) **Captured for**: operator's "szaleństwo z przymrużeniem oka" architectural intuition — *"żebyś wiedział, możesz to zapisać gdzieś jako komentarz jaki jest jakby myśl, jaka jest struktura tutaj jakby danych wokół tego"*

claude referenced this issue

2026-05-11 07:47:58 +02:00

Phase 08+ scope: Włóczykij as second-tier curated vault (physical-separation safety architecture) #178

claude commented

2026-05-11 07:52:40 +02:00

Author

Collaborator

Role: operator (piotr) → recorded by claude (orchestrator)
Intent: operator-feedback-applied (6 Open Questions answered)
Needs owner: no (operator has spoken; this is record-keeping)

Operator voice-note 2026-05-11 ~07:55 answered all 6 Open Questions from this issue. Summary + new architecture discoveries below.

Answers to Open Questions

Q1 — Backup of Tier 2 content: Option B-modified (Synology-only, not Dropbox)

Operator: "Kingston tutaj jakby wystarczy. Synology backup może tego Kingstona jako backup tier 2 ale póki co to jest jakby mówimy o przyszłych planach na tym momencie to jeszcze nie boli."

Decision:

Primary: Kingston IronKey alone (operator accepts loss-is-loss for now)
Future (not urgent): Synology NAS as encrypted backup target for IronKey content
NOT encrypted Dropbox (per ADR-0013 4th replica chain). Tier 2 stays on-site.

Architecture implication: Synology has TWO roles now:

Tier 0/1 4th replica primary (per ADR-0013): /volume1/iskra-baseline/
Tier 2 backup target (future): /volume1/iskra-tier2-encrypted/ (encrypted blob from IronKey)

These are separate directories on the same Synology. Different encryption keys; different mount semantics; different access policies.

Q2 — M1-disk mirror: KEEP for Obsidian compatibility

Operator: "Nie jestem w stanie zrobić tej dwójki [IronKey-only canonical] bo Obsidian wariuje. Więc chyba będzie M1 disk mirror po prostu a tym."

Decision:

/Users/pd/Obsidian/Włóczykij/ stays as M1-disk mirror (Obsidian needs stable vault path)
/Volumes/IRONKEY/Włóczykij/ is the canonical security boundary
Sync direction: M1-mirror ↔ IronKey (operator-triggered manual sync when IronKey mounted)
M1-disk mirror is in vault_roots.denylist per ADR-0010 (agents NEVER read it, even though physical files exist)

Open follow-up: figure out cleaner solution. Obsidian's "vault must be local" constraint is the friction. Possible Phase 09+ ideas:

Obsidian opens /Volumes/IRONKEY/Włóczykij/ directly when mounted, falls back to read-only stub when unmounted
Or: vault structure decoupled from Obsidian vault (markdown lives on IronKey; Obsidian sees a separate "view-only proxy" vault)
Park for now.

Q3 — PIN management: physical secure location (undisclosed)

Operator: "Mam fizycznie miejsce, gdzie składuję ważne papiery, więc tam będzie w fizycznym miejscu dla mnie dostępnym. Specjalnie ci nie mówię, gdzie dokładnie, żeby nawet to nie wyleciało tutaj."

Decision:

PIN written on paper, stored at operator's physical secure location (undisclosed by design — good privacy hygiene; never enters AI context)
Fallback path: Synology backup of IronKey content + YubiKey-protected access to Synology (see NEW DISCOVERY below)
Worst case (paper lost + IronKey lost): loss is total, accepted

Q4 — 2nd IronKey: NO

Operator: "Nie chciałbym, bo jest dość drogie, a nie ma wartości, prócz tego, że się tym jaram. Zacznijmy od testowania tego."

Decision: single IronKey for now. Operator self-aware about FOMO vs actual value. Re-evaluate after operational period (e.g. 3 months) if hardware-failure risk feels real.

Q5 — Read-only vs read-write default: READ-ONLY default + manual toggle + auto-revert

Operator: "Tryb read only żeby właśnie dla agentów i read write żeby w momencie kiedy jest coś do zrobienia. Może powinien się sam wyłączać po jakimś czasie."

Decision:

Mount default: read-only
Manual toggle: operator-explicit command (e.g. iskra-ironkey mode read-write) for write mode
Auto-revert to read-only: after inactivity timeout (suggested: 30 min idle)
Auto-eject after extended idle (suggested: 2h idle → unmount entirely, requires re-PIN)

Implementation note (Phase 08+): IronKey Keypad 200C supports read-only mode toggle via device or via mount-time option. Wrapper script scripts/ironkey/mount-readonly.sh is the safe-default path; scripts/ironkey/toggle-readwrite.sh is operator-explicit.

Q6 — KOS2 guard-rail timeline: defer to Phase 08+

Operator: "Z racji, że nie działa, możemy sobie ustawić na kolejne fazy."

Decision: Phase 08+ as originally proposed. KOS2-derived guard rails implement when IronKey integration becomes active (after Phase 07 lands local-admin tier on Iskra-i-Piotr).

NEW DISCOVERY — 2× YubiKey in operator's hardware inventory

Operator: "U tego Synology można wykorzystać to, że mam YubiKey, a też 2 YubiKey, więc to też można tutaj jakoś to pewnie włączyć."

This is new information not previously in any platform inventory. Two YubiKeys in operator's possession.

Architectural implications

YubiKey (FIDO2/U2F/PIV/OpenPGP capable) opens several potential roles in the privacy chain:

Synology auth factor: 2FA for Synology DSM admin login (FIDO2 via WebAuthn) — protects the future Tier 2 backup target.
SSH key storage: SSH private keys stored on YubiKey (PIV slot or OpenPGP); SSH to RS2000/VPS1000/kip uses hardware-resident key. Eliminates ~/.ssh/id_* files on M1 disk for production-tier auth.
Age key co-storage: ADR-0013 mentions age encryption key for encrypted Dropbox. Could move age key to YubiKey (via age-plugin-yubikey) — encryption now requires hardware presence.
GitHub/Forgejo SSH key: per-actor PATs currently in BW custom field; could augment with YubiKey-resident SSH keys for git push (defense-in-depth against M1 compromise).
PIN recovery factor for IronKey: NOT directly — IronKey PIN is on-device only. BUT YubiKey-protected Synology backup means "if IronKey PIN forgotten, restore from Synology requires YubiKey hardware presence" — better than software password.
Future M1 boot / FileVault: macOS supports YubiKey for Touch ID alternative; not in current scope but possible later.

Capture in inventory

Recommendation: open separate follow-up issue Phase 08+ scope: integrate 2× YubiKey into platform auth chain covering the above 6 roles. Operator picks which to enable.

For THIS issue (#180), YubiKey relevance is narrow:

YubiKey enables Tier 2 backup-on-Synology to be hardware-auth-protected (Synology DSM 2FA via WebAuthn)
Not blocking; Synology Tier 2 backup is already operator-deferred per Q1

Updated architecture summary

TIER 0 — agent-collaborative
  /Users/pd/Obsidian/Iskra-i-Piotr/*
  ↓ 4th replica chain per ADR-0013
  M1 → RS2000 + VPS1000 + Synology + encrypted Dropbox

TIER 1 — operator-on-disk
  /Users/pd/Obsidian/Iskra-i-Piotr/{Journal,Finance,Family,Health}/
  ↓ same M1 + mirrors as Tier 0
  agents path-denylisted per ADR-0010
  (Health moved OUT of hard_private per voice-note 2026-05-11)

TIER 2 — operator-on-physical-key
  PRIMARY:  /Volumes/IRONKEY/Włóczykij/  (Kingston Keypad 200C, AES-256 XTS hw-encrypted)
  MIRROR:   /Users/pd/Obsidian/Włóczykij/ (M1 disk; Obsidian compatibility ONLY; denylist for agents)
  BACKUP (Phase 08+ future): Synology /volume1/iskra-tier2-encrypted/
            ↑ optionally YubiKey-FIDO2-protected Synology admin access
  CANONICAL: IronKey is source of truth; M1 mirror is sync target

  Mount default: read-only
  Mode toggle: operator-explicit (auto-revert after 30 min idle)
  Auto-eject: 2h idle
  PIN backup: physical secure location (undisclosed; operator-only)
  No 2nd IronKey for now (re-evaluate after 3 months)

Recommended follow-up tickets (not opening now; operator-paced)

Phase 08+ scope: integrate 2× YubiKey into platform auth chain — 6 potential roles enumerated above
Phase 08+ ticket: operator-driven IronKey setup runbook (Ticket A from this issue body) — operator-paced, can be done before Phase 07 lands
Phase 08+ ticket: M1-disk mirror sync semantics for Obsidian compatibility — figure out cleaner Obsidian-doesn't-wariuje pattern

Next action

This issue is now operator-answered + architecture-recorded. No blocker. Implementation lives in Phase 08+ post-Phase-07.

Role: orchestrator → record-keeper (claude)
Lane: architecture documentation

**Role:** operator (piotr) → recorded by claude (orchestrator) **Intent:** operator-feedback-applied (6 Open Questions answered) **Needs owner:** no (operator has spoken; this is record-keeping) Operator voice-note 2026-05-11 ~07:55 answered all 6 Open Questions from this issue. Summary + new architecture discoveries below. ## Answers to Open Questions ### Q1 — Backup of Tier 2 content: Option B-modified (Synology-only, not Dropbox) Operator: *"Kingston tutaj jakby wystarczy. Synology backup może tego Kingstona jako backup tier 2 ale póki co to jest jakby mówimy o przyszłych planach na tym momencie to jeszcze nie boli."* **Decision**: - **Primary**: Kingston IronKey alone (operator accepts loss-is-loss for now) - **Future** (not urgent): Synology NAS as encrypted backup target for IronKey content - **NOT** encrypted Dropbox (per ADR-0013 4th replica chain). Tier 2 stays on-site. **Architecture implication**: Synology has TWO roles now: 1. Tier 0/1 4th replica primary (per ADR-0013): `/volume1/iskra-baseline/` 2. Tier 2 backup target (future): `/volume1/iskra-tier2-encrypted/` (encrypted blob from IronKey) These are **separate directories on the same Synology**. Different encryption keys; different mount semantics; different access policies. ### Q2 — M1-disk mirror: KEEP for Obsidian compatibility Operator: *"Nie jestem w stanie zrobić tej dwójki [IronKey-only canonical] bo Obsidian wariuje. Więc chyba będzie M1 disk mirror po prostu a tym."* **Decision**: - **`/Users/pd/Obsidian/Włóczykij/`** stays as M1-disk mirror (Obsidian needs stable vault path) - **`/Volumes/IRONKEY/Włóczykij/`** is the canonical security boundary - Sync direction: M1-mirror ↔ IronKey (operator-triggered manual sync when IronKey mounted) - M1-disk mirror is in `vault_roots.denylist` per ADR-0010 (agents NEVER read it, even though physical files exist) **Open follow-up**: figure out cleaner solution. Obsidian's "vault must be local" constraint is the friction. Possible Phase 09+ ideas: - Obsidian opens `/Volumes/IRONKEY/Włóczykij/` directly when mounted, falls back to read-only stub when unmounted - Or: vault structure decoupled from Obsidian vault (markdown lives on IronKey; Obsidian sees a separate "view-only proxy" vault) - Park for now. ### Q3 — PIN management: physical secure location (undisclosed) Operator: *"Mam fizycznie miejsce, gdzie składuję ważne papiery, więc tam będzie w fizycznym miejscu dla mnie dostępnym. Specjalnie ci nie mówię, gdzie dokładnie, żeby nawet to nie wyleciało tutaj."* **Decision**: - PIN written on paper, stored at operator's physical secure location (undisclosed by design — good privacy hygiene; never enters AI context) - **Fallback path**: Synology backup of IronKey content + YubiKey-protected access to Synology (see NEW DISCOVERY below) - **Worst case** (paper lost + IronKey lost): loss is total, accepted ### Q4 — 2nd IronKey: NO Operator: *"Nie chciałbym, bo jest dość drogie, a nie ma wartości, prócz tego, że się tym jaram. Zacznijmy od testowania tego."* **Decision**: single IronKey for now. Operator self-aware about FOMO vs actual value. Re-evaluate after operational period (e.g. 3 months) if hardware-failure risk feels real. ### Q5 — Read-only vs read-write default: READ-ONLY default + manual toggle + auto-revert Operator: *"Tryb read only żeby właśnie dla agentów i read write żeby w momencie kiedy jest coś do zrobienia. Może powinien się sam wyłączać po jakimś czasie."* **Decision**: - **Mount default**: read-only - **Manual toggle**: operator-explicit command (e.g. `iskra-ironkey mode read-write`) for write mode - **Auto-revert to read-only**: after inactivity timeout (suggested: 30 min idle) - **Auto-eject** after extended idle (suggested: 2h idle → unmount entirely, requires re-PIN) **Implementation note** (Phase 08+): IronKey Keypad 200C supports read-only mode toggle via device or via mount-time option. Wrapper script `scripts/ironkey/mount-readonly.sh` is the safe-default path; `scripts/ironkey/toggle-readwrite.sh` is operator-explicit. ### Q6 — KOS2 guard-rail timeline: defer to Phase 08+ Operator: *"Z racji, że nie działa, możemy sobie ustawić na kolejne fazy."* **Decision**: Phase 08+ as originally proposed. KOS2-derived guard rails implement when IronKey integration becomes active (after Phase 07 lands local-admin tier on Iskra-i-Piotr). ## NEW DISCOVERY — 2× YubiKey in operator's hardware inventory Operator: *"U tego Synology można wykorzystać to, że mam YubiKey, a też 2 YubiKey, więc to też można tutaj jakoś to pewnie włączyć."* **This is new information** not previously in any platform inventory. Two YubiKeys in operator's possession. ### Architectural implications YubiKey (FIDO2/U2F/PIV/OpenPGP capable) opens several potential roles in the privacy chain: 1. **Synology auth factor**: 2FA for Synology DSM admin login (FIDO2 via WebAuthn) — protects the future Tier 2 backup target. 2. **SSH key storage**: SSH private keys stored on YubiKey (PIV slot or OpenPGP); SSH to RS2000/VPS1000/kip uses hardware-resident key. Eliminates `~/.ssh/id_*` files on M1 disk for production-tier auth. 3. **Age key co-storage**: ADR-0013 mentions age encryption key for encrypted Dropbox. Could move age key to YubiKey (via age-plugin-yubikey) — encryption now requires hardware presence. 4. **GitHub/Forgejo SSH key**: per-actor PATs currently in BW custom field; could augment with YubiKey-resident SSH keys for git push (defense-in-depth against M1 compromise). 5. **PIN recovery factor for IronKey**: NOT directly — IronKey PIN is on-device only. BUT YubiKey-protected Synology backup means "if IronKey PIN forgotten, restore from Synology requires YubiKey hardware presence" — better than software password. 6. **Future M1 boot / FileVault**: macOS supports YubiKey for Touch ID alternative; not in current scope but possible later. ### Capture in inventory **Recommendation**: open separate follow-up issue `Phase 08+ scope: integrate 2× YubiKey into platform auth chain` covering the above 6 roles. Operator picks which to enable. For THIS issue (#180), YubiKey relevance is narrow: - YubiKey enables Tier 2 backup-on-Synology to be hardware-auth-protected (Synology DSM 2FA via WebAuthn) - Not blocking; Synology Tier 2 backup is already operator-deferred per Q1 ## Updated architecture summary ``` TIER 0 — agent-collaborative /Users/pd/Obsidian/Iskra-i-Piotr/* ↓ 4th replica chain per ADR-0013 M1 → RS2000 + VPS1000 + Synology + encrypted Dropbox TIER 1 — operator-on-disk /Users/pd/Obsidian/Iskra-i-Piotr/{Journal,Finance,Family,Health}/ ↓ same M1 + mirrors as Tier 0 agents path-denylisted per ADR-0010 (Health moved OUT of hard_private per voice-note 2026-05-11) TIER 2 — operator-on-physical-key PRIMARY: /Volumes/IRONKEY/Włóczykij/ (Kingston Keypad 200C, AES-256 XTS hw-encrypted) MIRROR: /Users/pd/Obsidian/Włóczykij/ (M1 disk; Obsidian compatibility ONLY; denylist for agents) BACKUP (Phase 08+ future): Synology /volume1/iskra-tier2-encrypted/ ↑ optionally YubiKey-FIDO2-protected Synology admin access CANONICAL: IronKey is source of truth; M1 mirror is sync target Mount default: read-only Mode toggle: operator-explicit (auto-revert after 30 min idle) Auto-eject: 2h idle PIN backup: physical secure location (undisclosed; operator-only) No 2nd IronKey for now (re-evaluate after 3 months) ``` ## Recommended follow-up tickets (not opening now; operator-paced) 1. **`Phase 08+ scope: integrate 2× YubiKey into platform auth chain`** — 6 potential roles enumerated above 2. **`Phase 08+ ticket: operator-driven IronKey setup runbook`** (Ticket A from this issue body) — operator-paced, can be done before Phase 07 lands 3. **`Phase 08+ ticket: M1-disk mirror sync semantics for Obsidian compatibility`** — figure out cleaner Obsidian-doesn't-wariuje pattern ## Next action This issue is now **operator-answered + architecture-recorded**. No blocker. Implementation lives in Phase 08+ post-Phase-07. **Role:** orchestrator → record-keeper (claude) **Lane:** architecture documentation

claude referenced this issue

2026-05-11 07:56:35 +02:00

Phase 08+ scope: integrate 2× YubiKey into platform auth chain (6 roles) #181

claude referenced this issue from a commit

2026-05-17 18:15:07 +02:00

docs(specs): vault-to-infisical-migration-v0 prebuild (#64)

claude referenced this issue

2026-05-17 18:15:19 +02:00

docs(specs): vault-to-infisical-migration-v0 prebuild (#64) #336

claude referenced this issue from a commit

2026-05-17 18:19:03 +02:00

docs(specs): vault-tier-3-architecture-v0 prebuild (#178 + #180)

claude referenced this issue

2026-05-17 18:19:18 +02:00

docs(specs): vault-tier-3-architecture-v0 prebuild (#178 + #180) #337

claude referenced this issue from a commit

2026-05-17 18:22:20 +02:00

docs(specs): pseudo-anonymization-readlayer-v0 prebuild (#177)

claude referenced this issue

2026-05-17 18:22:40 +02:00

docs(specs): pseudo-anonymization-readlayer-v0 prebuild (#177) #338

claude referenced this issue

2026-05-17 21:01:19 +02:00

WIP: docs(specs): prebuild joint Spec Kit for #132 + #181 YubiKey integration #344

claude referenced this issue from a commit

2026-05-17 21:01:21 +02:00

docs(specs): prebuild joint Spec Kit for #132 + #181 YubiKey integration (WIP)

claude referenced this issue from a commit

2026-05-17 21:28:58 +02:00

docs(specs): secrets-pipeline-foundation-v0 prebuild (#237)

codex added this to the 02 - DR and restore confidence milestone

2026-05-19 08:36:21 +02:00

pdurlej referenced this issue from a commit

2026-05-23 10:30:57 +02:00

Merge pull request 'docs(specs): vault-tier-3-architecture-v0 prebuild (#178 + #180)' (#337) from claude/vault-tier-3-architecture-v0-prebuild into main

codex commented

2026-05-29 16:21:43 +02:00

Collaborator

M10 disposition: moved to 10 - Improvements.

What this is: IronKey hardware-encrypted storage.

Why parked here: Parked in M10 because it is a useful physical-storage improvement for Włóczykij, but not a blocker for M02 infrastructure DR or M04 Vault sunset entry criteria.

This preserves the idea without letting it block M02/M03/M04 closeout. Before reactivation, split it into a narrow issue or PR with concrete acceptance criteria.

M10 disposition: moved to `10 - Improvements`. What this is: IronKey hardware-encrypted storage. Why parked here: Parked in M10 because it is a useful physical-storage improvement for Włóczykij, but not a blocker for M02 infrastructure DR or M04 Vault sunset entry criteria. This preserves the idea without letting it block M02/M03/M04 closeout. Before reactivation, split it into a narrow issue or PR with concrete acceptance criteria.

codex modified the milestone from 02 - DR and restore confidence to 10 - Improvements

2026-05-29 16:21:43 +02:00

codex referenced this issue

2026-05-29 16:36:32 +02:00

Phase 08+ scope: Włóczykij as second-tier curated vault (physical-separation safety architecture) #178

codex referenced this issue

2026-05-29 16:59:57 +02:00

chore(w9): milestone archaeology packet for stale open issues #535

claude added the

agent/claude-code

label

2026-05-30 13:08:25 +02:00

claude added the

priority:p3

label

2026-05-30 22:43:17 +02:00

claude added the

status:parked

label

2026-06-01 08:53:15 +02:00

claude commented

2026-06-01 08:53:15 +02:00

Author

Collaborator

Parked (p3, M10 closure plan #653 + Judging Claw priority). Reactivate when IronKey Tier-2 hardware storage is scheduled.

**Parked (p3, M10 closure plan #653 + Judging Claw priority).** Reactivate when IronKey Tier-2 hardware storage is scheduled.

Iskra commented

2026-06-09 03:03:28 +02:00

Collaborator

{
"confidence": 5,
"effort_hint": "large",
"escalation": {
"kind": "operator",
"reason": "Hardware-encrypted vault storage changes privacy, backup, import, and failure-mode decisions."
},
"evidence_refs": [
{
"note": "Issue scopes IronKey Keypad 200C as Tier 2 hardware-encrypted storage for W\u0142\u00f3czykij vault.",
"type": "forgejo",
"value": "issue-title-body-labels-and-target-snapshot"
},
{
"note": "Body frames a three-tier privacy architecture for portable markdown notes and local-model work.",
"type": "forgejo",
"value": "issue-body-context"
},
{
"note": "Snapshot labels mark the work as priority p3 and parked.",
"type": "snapshot",
"value": "target-snapshot-labels"
}
],
"impact": 4,
"judge_actor": {
"name": "iskra",
"runtime": "openclaw"
},
"judged_at": "2026-06-09T01:02:00Z",
"labels_to_apply": [
"judge/p2",
"judge/operator-needed"
],
"piotr_fit": "high",
"priority": "p2",
"rationale_summary": "This is P2 operator-shaped privacy architecture because hardware-encrypted W\u0142\u00f3czykij storage can protect sensitive notes but needs explicit guardrails and recovery design.",
"reach": 4,
"recommended_next_action": "operator_needed",
"rerun_reason": "no_prior_judgment",
"schema": "openclaw.judge.v0",
"target": {
"kind": "issue",
"number": 180,
"repo": "pdurlej/platform"
},
"target_snapshot": {
"body_hash": "sha256:ce8293aac1a6cd1811e5fb9c4d8af9a31e59e5ec460de282e8a584c360d61c1b",
"commit_count": null,
"evidence_hash": "sha256:460e2fade7e0c27dc5476907dd2548f2dff6d7401a067e1f89f195aff14589c0",
"head_sha": null,
"labels": [
"agent/claude-code",
"priority:p3",
"status:parked"
],
"labels_hash": "sha256:9e8ed9cb7b1b30f4dcf389e2b3d1f8e66c19eb940504926be5872a601be5b3ab",
"state": "open",
"title_hash": "sha256:1ca3f9926f56472e77f3a27c7cae050460b0ceb16b2937063711a15c13bd6ea2",
"updated_at": "2026-06-01T08:53:15+02:00"
},
"top_caveat": "Do not make it the only vault location until backup, loss, corruption, and import boundaries are deliberately tested."
}

{ "confidence": 5, "effort_hint": "large", "escalation": { "kind": "operator", "reason": "Hardware-encrypted vault storage changes privacy, backup, import, and failure-mode decisions." }, "evidence_refs": [ { "note": "Issue scopes IronKey Keypad 200C as Tier 2 hardware-encrypted storage for W\u0142\u00f3czykij vault.", "type": "forgejo", "value": "issue-title-body-labels-and-target-snapshot" }, { "note": "Body frames a three-tier privacy architecture for portable markdown notes and local-model work.", "type": "forgejo", "value": "issue-body-context" }, { "note": "Snapshot labels mark the work as priority p3 and parked.", "type": "snapshot", "value": "target-snapshot-labels" } ], "impact": 4, "judge_actor": { "name": "iskra", "runtime": "openclaw" }, "judged_at": "2026-06-09T01:02:00Z", "labels_to_apply": [ "judge/p2", "judge/operator-needed" ], "piotr_fit": "high", "priority": "p2", "rationale_summary": "This is P2 operator-shaped privacy architecture because hardware-encrypted W\u0142\u00f3czykij storage can protect sensitive notes but needs explicit guardrails and recovery design.", "reach": 4, "recommended_next_action": "operator_needed", "rerun_reason": "no_prior_judgment", "schema": "openclaw.judge.v0", "target": { "kind": "issue", "number": 180, "repo": "pdurlej/platform" }, "target_snapshot": { "body_hash": "sha256:ce8293aac1a6cd1811e5fb9c4d8af9a31e59e5ec460de282e8a584c360d61c1b", "commit_count": null, "evidence_hash": "sha256:460e2fade7e0c27dc5476907dd2548f2dff6d7401a067e1f89f195aff14589c0", "head_sha": null, "labels": [ "agent/claude-code", "priority:p3", "status:parked" ], "labels_hash": "sha256:9e8ed9cb7b1b30f4dcf389e2b3d1f8e66c19eb940504926be5872a601be5b3ab", "state": "open", "title_hash": "sha256:1ca3f9926f56472e77f3a27c7cae050460b0ceb16b2937063711a15c13bd6ea2", "updated_at": "2026-06-01T08:53:15+02:00" }, "top_caveat": "Do not make it the only vault location until backup, loss, corruption, and import boundaries are deliberately tested." }

Iskra added the

judge/operator-needed

judge/p2

labels

2026-06-09 03:03:28 +02:00

codex referenced this issue

2026-06-11 00:14:03 +02:00

docs(agent-readiness): clean stale ADR references #787