ticket: use base32 project record ids

.yoi/tickets/00001KT1DF48G/artifacts/implementation-report.md

@@ -0,0 +1,33 @@
+# Implementation report
+
+## Summary
+
+Standardized crate README files as thin responsibility-boundary documents.
+
+## Changes
+
+- Rewrote existing stale README files to remove public-type inventories and outdated architecture claims.
+- Added concise README files for important crates that lacked them:
+  - `client`
+  - `lint-common`
+  - `memory`
+  - `pod-registry`
+  - `pod-store`
+  - `secrets`
+  - `session-metrics`
+  - `tools`
+  - `workflow`
+  - `yoi`
+- Each crate README now follows the same shape:
+  - Role
+  - Boundaries
+  - Design notes
+  - See also
+- README files link to maintained `docs/design/` or `docs/development/` docs instead of duplicating long design explanations.
+
+## Validation
+
+- All crates under `crates/*` have a README.
+- `rg` sweep for stale public-type headings, old crate title, accidental edit text, and old product names in crate README files => no output.
+- `./tickets.sh doctor` => `doctor: ok`
+- `git diff --check` => passed

.yoi/tickets/00001KT1DF48G/item.md

@@ -0,0 +1,26 @@
+---
+title: "Standardize crate README responsibility boundaries"
+state: "closed"
+created_at: "2026-06-01T11:00:26Z"
+updated_at: "2026-06-01T13:22:51Z"
+---
+
+## Background
+
+The crate README files are uneven and several important crates have no README at all. They should be standardized as thin responsibility-boundary documents rather than API references.
+
+This work item follows `docs-information-architecture` and should link crate README files to the maintained design/development docs where appropriate.
+
+## Requirements
+
+- Each crate README should explain the crate's role, boundaries, key entry points, and relevant design docs.
+- README files should avoid public type inventories, method lists, and implementation details that are likely to drift.
+- Important crates without README files should get concise responsibility-boundary README files.
+- Existing stale names or stale architectural claims should be removed.
+
+## Acceptance criteria
+
+- Existing crate README files follow a consistent role/boundary-oriented shape.
+- Important crates without README files have a short README.
+- Crate README files link to `docs/design/` or `docs/development/` instead of duplicating long design content.
+- Validation includes `./tickets.sh doctor` and `git diff --check`.

.yoi/tickets/00001KT1DF48G/resolution.md

@@ -0,0 +1 @@
+Completed crate README boundary cleanup: all crates now have concise role/boundary README files linked to maintained design/development docs; validation passed.

.yoi/tickets/00001KT1DF48G/thread.md

@@ -0,0 +1,57 @@
+<!-- event: create author: tickets.sh at: 2026-06-01T11:00:26Z -->
+
+## Created
+
+Created by tickets.sh create.
+
+---
+
+<!-- event: implementation_report author: hare at: 2026-06-01T11:09:35Z -->
+
+## Implementation report
+
+# Implementation report
+
+## Summary
+
+Standardized crate README files as thin responsibility-boundary documents.
+
+## Changes
+
+- Rewrote existing stale README files to remove public-type inventories and outdated architecture claims.
+- Added concise README files for important crates that lacked them:
+  - `client`
+  - `lint-common`
+  - `memory`
+  - `pod-registry`
+  - `pod-store`
+  - `secrets`
+  - `session-metrics`
+  - `tools`
+  - `workflow`
+  - `yoi`
+- Each crate README now follows the same shape:
+  - Role
+  - Boundaries
+  - Design notes
+  - See also
+- README files link to maintained `docs/design/` or `docs/development/` docs instead of duplicating long design explanations.
+
+## Validation
+
+- All crates under `crates/*` have a README.
+- `rg` sweep for stale public-type headings, old crate title, accidental edit text, and old product names in crate README files => no output.
+- `./tickets.sh doctor` => `doctor: ok`
+- `git diff --check` => passed
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-01T13:22:51Z status: closed -->
+
+## Closed
+
+Completed crate README boundary cleanup: all crates now have concise role/boundary README files linked to maintained design/development docs; validation passed.
+
+
+---