hosystem Engagements

Sharibako — Ho Overview

created 2026-06-30
updated 2026-07-03
status draft
type ho-overview
project sharibako
stage kamae-4
kamae-chain seed → system-design → injection-decision → readme → **ho-overview**
builds-on kamae-2-sharibako-system-design, kamae-2.1-sharibako-injection-decision, kamae-3-sharibako-readme
next per-ho dandori specs authored via ho-kamae-5

Seven phases (v1.0 target). Phase 0 sets up the project. Phases 1–2 build the vault substrate and the bridge to the user's filesystem with no UI at all. Phase 3 puts a CLI on top of that and earns the first real dogfooding, then ho-04.5 adds runtime injection (sharibako run) as a peer output verb alongside materialize; the then grew a run of small CLI-polish inserts as dogfooding surfaced work, and is now complete. Phases 4–5 add the Workshop and the linking UX that the is built around. Phase 6 ships v1.0 through signing, notarization, website, and release.

Revision 2026-07-01: ho-04.5 inserted after the injection decision (kamae-2.1). Ho-03 entry updated to reflect the ownership decision (kamae-2.2) — per-key ownership, .env merge-not-overwrite, update verb, four-way ingest matrix. This is a build-phase document; ship/commercial concerns sit in ho-09 as they always did — not elevated to content.

Revision 2026-07-03: Phase 3 closed. The CLI phase grew four inserts beyond ho-04/ho-04.5 as dogfooding surfaced work — ho-04.2 (interactive init), ho-04.4 (ingest dashboard, later superseded), ho-04.6 (plain-prompt init replacing the dashboard), and ho-04.7 (run feedback) — all complete, alongside ho-04.3 (sign the binary; unblock Keychain biometry) and ho-04.5 (sharibako run). Two as-built worth carrying forward: signing shipped via a signed .app bundle with keychain-access-groups + an embedded provisioning profile (not the raw-binary/empty-entitlements approach ho-04.3 first drafted — that entitlement is restricted, honoured only inside a bundle), and ho-04.5 shipped without memset_s scrubbing of decrypted values (kamae-2.1 Decision 7; SECURITY.md reconciled to match). Replan Checkpoint 1 fired — outcome recorded below. The per- documents under hos/ hold the detail; those inserts are not back-filled as full overview entries. No phase restructure; no ship/commercial elevation.

The overview commits to the sequence, names the decisions each ho is responsible for resolving, and marks the three pause points where real evidence is supposed to revise the plan.

What this is, and what it is not

This document is the build's directional plan. Each ho is sized to fit a single focused session; combined hos are flagged as candidates to split when the work turns out larger than the line predicts. The numbering scheme (ho-N.1, ho-N.5) exists for that reality — the plan is supposed to evolve as the build proceeds.

The system 's first-pass ho sequence is welcomed as starting material; this overview reorganizes it into phases and surfaces the splits and checkpoints the system design did not. The system design's deferred-decisions table is dissolved into per-ho decision callouts, so the decisions a given ho is responsible for resolving are right there in the ho.

This is not a contract. It is the map. Per-ho specs are the territory.

Phase structure

Phase Hos What it produces
0. Foundation Swift package, GitHub repo, signing reused from M4Bookmaker, CI, baseline tests
1. The vault substrate ho-01, ho-02 Encrypted vault on disk with git sync. End-to-end vault operations, no user surface
2. The bridge ho-03 Markers, .env ingest, materialize, drift detection. Vault meets the user's filesystem
3. The Tool (complete) ho-04, ho-04.2, ho-04.3, ho-04.4, ho-04.5, ho-04.6, ho-04.7 CLI usable for real personal work. First dogfooding moment. Ho-04.5 adds sharibako run (injection), sharibako clean, and the SECURITY.md draft; ho-04.2/04.4/04.6 build and rework interactive init; ho-04.3 signs the binary (Keychain biometry); ho-04.7 adds run feedback
4. The Workshop ho-05, ho-06 SwiftUI app with three-state UI, first-run wizard, ingest decision matrix
5. Linking UX ho-07 The parti-defining feature surfaced across both CLI and GUI
6. Release ho-08, ho-09 Bundling, notarization, Homebrew tap, website, v1.0

Phase 0 — Foundation

The project scaffolds itself. A single Swift package with two products (Sharibako.app, sharibako CLI) over a shared core library. The GitHub repo lives at github.com/sageframe-no-kaji/sharibako, GPL-3.0. Signing infrastructure reuses the existing Apple Developer Program from M4Bookmaker — same Developer ID cert, adapted from PyInstaller's notarization to native Xcode. CI runs swift build and swift test on every push so the stack exists from commit one. Nothing user-facing is built here; this is the encoded environment that downstream hos read.

Release on phase complete: v0.0 (private — scaffolding only)

ho-00 — Project scaffolding

The first session. Initialize the Swift package with the multi-product layout, create the GitHub repo, wire CI, add baseline tests that prove the package builds and runs, set up the per-project CLAUDE.md that points subsequent agent sessions at the operating discipline and the kamae chain. The age binary is not bundled yet — Phase 1 figures out how tests reach it.

Depends on: Nothing (this is the start)

What's in scope:

What "done" means:

What's out of scope:

Decisions required:

Phase 1 — The vault substrate

The bottom half of the architecture, built before any user-facing surface exists. The Vault Core owns the vault directory on disk: filesystem-as-schema, age encryption per secret, link resolution at runtime. The Conduit wraps git for vault sync — pull, push, commit, status — and knows nothing about secrets. By the end of the phase, an integration test creates a vault, writes encrypted scopes and secrets, commits them, pushes to a local bare remote, pulls them back, and decrypts cleanly. The data engine works end-to-end with no human interface attached.

Release on phase complete: v0.1 (library only; not yet useful to a user)

The vault's complete data model in code. Implements the vault/, shared/, scopes/<id>/ filesystem layout; reads and writes scope.yaml, <KEY>.age, and <KEY>.link files; shells out to the age binary for encryption and decryption; resolves the implicit link graph by walking .link files at runtime. Operations: list_scopes, list_shared, get_scope, get_value, add_secret, link, unlink, rotate, inspect. No CLI, no GUI — these are library functions with thorough tests. The age key story is decided here: how tests get an ephemeral age key, how the production code expects to find the real one (the Keychain integration may stub here and concretize in ho-04).

Depends on: ho-00

What's in scope:

What "done" means:

What's out of scope:

Decisions required:

Possible split: if age invocation and error handling turn out fussier than expected (binary discovery, exit code parsing, stdin/stdout streaming), split into ho-01.1 (filesystem layout + read/write + tests) and ho-01.2 (age invocation + encryption operations + round-trip tests).

ho-02 — The Conduit: git wrapping

The thin layer over git. Operations: commit(message), push(), pull(), status(). The Conduit knows nothing about secrets — every change is just a file change in the vault directory. The file-per-secret structure makes most conflicts impossible by construction; the cases that do conflict (same secret rotated on two machines between syncs) need to surface clearly without the Conduit pretending it can resolve them. v1 surfaces the conflict; UI polish for conflict resolution is deferred until conflicts happen in practice.

Depends on: ho-01

What's in scope:

What "done" means:

What's out of scope:

Decisions required:

Phase 2 — The bridge

The Vault Core knows about the vault; the user's filesystem knows about .env files. The Materializer is the bridge — it owns .sharibako marker files at project roots, walks configured scan roots to find them, ingests existing .env files into proposed scope schemas for user review, writes materialized .env files at marker-relative paths, and detects drift between materialized files and current vault state. By the end of this phase, the data flow runs end-to-end through a test that simulates a project directory, ingests its .env, writes a marker, and materializes the secret back out — all without a CLI or GUI.

Release on phase complete: v0.2 (library + materializer; programmatically usable)

ho-03 — The Materializer: markers, ingest, materialize, update, heal

The bridge's full responsibility set. Reads and writes .sharibako marker YAML; walks scan_roots to find markers; parses .env files; proposes scope schemas for user review through a four-way decision matrix (per kamae-2.2); merges owned keys into .env on materialize while preserving all non-owned lines exactly; reads .env back into the vault on update (bidirectional flow); computes the three-state model (live_here, live_elsewhere, orphaned); reports per-key drift via heal; retracts owned lines via clean. Nothing in this layer ever deletes a scope automatically — deletion is always an explicit user action against the Vault Core.

Depends on: ho-01, ho-02

Reflects: kamae-2.2 ownership decision — per-key ownership; .env merge-not-overwrite; update verb; four-way ingest matrix (import-local / link-shared / move-to-shared / leave-alone).

What's in scope:

What "done" means:

What's out of scope:

Decisions required:

Not splitting into ho-03.1 / ho-03.2. The original ho-overview speculated a split. Ho-03 stays a single ho; the two-agent-task decomposition (write path + read path) carries the density without needing a ho-level split.

Phase 3 — The Tool

A CLI built on top of the substrate. The Tool exposes the operations the Vault Core, Conduit, and Materializer already implement. Commands: init, add, get, rotate, link, materialize, sync, scan, status. Touch ID gating concretizes here — get requires authentication; other commands either do (rotation, linking) or don't (read-only inspection). By the end of this phase, Andrew can use sharibako for real personal secrets work without the GUI existing yet. This is the first dogfooding moment.

Release on phase complete: v0.3 (CLI usable for personal dogfooding)

Phase 3 as-built (complete, 2026-07-03). The phase closed as ho-04 (CLI MVP) plus six inserts. The two spelled out in full below are ho-04 and ho-04.5. The others landed as dogfooding surfaced the need and are recorded in their own per-ho documents under hos/: ho-04.2 (interactive init — the per-secret decision flow split out of ho-04), ho-04.3 (sign the release binary so Keychain biometry works — shipped as a signed .app bundle with keychain-access-groups + an embedded provisioning profile, since that entitlement is honoured only inside a bundle), ho-04.4 (an ingest dashboard, later superseded), ho-04.6 (plain-prompt init replacing the dashboard), and ho-04.7 (run feedback — a startup status line and a signal-shutdown countdown; see below). Replan Checkpoint 1 fired at the end of the phase; its outcome is recorded under "Replan checkpoints."

ho-04 — The Tool: CLI MVP wired to the core

Swift ArgumentParser implementation of every CLI command listed in the system design. The init flow follows the system design's step-by-step interaction: detect existing marker, propose scope identity, request Touch ID, scan for existing secrets, present the per-secret decision (import / link / move to shared / skip), write through the Vault Core, write the marker, materialize, commit + push. get prints to stdout with Touch ID gating. rotate and link work end-to-end. The CLI is the first surface that talks to macOS Keychain for the production age key.

Depends on: ho-01, ho-02, ho-03

What's in scope:

What "done" means:

What's out of scope:

Decisions required:

Possible split: if the init flow's interactive UX (decision matrix per secret, Touch ID interleaving, diff display) turns out to be a substantial UX problem in terminal form, split into ho-04.1 (non-interactive commands — add, get, rotate, link, materialize, sync, scan, status) and ho-04.2 (init with its full interactive flow).

Phase boundary — . Andrew uses the CLI for real secrets work. The questions that surface here drive the next phase: what's awkward, what's missing, what's actually fine, and — critically — whether the SwiftUI investment in Phase 4 is the right next move or whether further CLI polish should come first. See "Replan checkpoints" below for the explicit checkpoint structure.

ho-04.5 — Runtime injection (sharibako run), clean, and SECURITY.md draft

Status: complete (2026-07-03). sharibako run shipped and was dogfooded end-to-end against the real vault through the Keychain and Touch ID. As-built divergence from the scope below: no memset_s scrub of decrypted values (kamae-2.1 Decision 7 — the only scrub is the temp age-key file wipe; SECURITY.md reconciled to match). clean was already built by its Materializer siblings; this ho was run alone.

The injection verb specified in kamae-2.1. sharibako run [--scope <id>] -- <command> decrypts the current scope's secrets into memory, spawns the child with those values set in its environment, forwards stdio and signals, waits, exits with the child's status. No file is written; values live only in wrapper and child process memory. Pair verb sharibako clean [<scope>] retracts materialized files. sharibako run --dry-run prints secret names without values for pre-flight verification and safe agent-summarization. And this ho drafts SECURITY.md — the trust document that reflects the four-class threat model and the materialize/run exposure difference. The doc is written as if the software is done; it will be revised as v1 lands but its skeleton exists here.

Depends on: ho-01 (Vault Core), ho-03 (scope resolution from marker), ho-04 (CLI base + Keychain integration)

What's in scope:

What "done" means:

What's out of scope:

Decisions required:

Possible split:

Split only if the ho spills a session. The pairing is deliberate — writing SECURITY.md while injection is fresh in mind produces a stronger document than either could produce alone.

ho-04.7 — sharibako run feedback

Status: complete (2026-07-03). Inserted at Replan Checkpoint 1: driving run on real secrets surfaced feedback friction — a blank startup and a silent five-second Ctrl-C grace — and this ho closes it before the Workshop rather than carrying it in. run gains two stderr-only feedback surfaces, TTY-gated (suppressed under --json, forced on under --verbose): a startup status line naming the scope, the count of secrets injected, and the command; and, on SIGINT/SIGTERM/SIGHUP, a forwarding… line plus a plain-integer countdown across the existing grace, then a SIGKILL line if the child outlives it. No behavior change — spawn, env merge, exit-code mapping, signal forwarding, and grace→SIGKILL are byte-identical to ho-04.5. Scope was run only; the same terseness in materialize/ingest/sync is noted as a followup, not built. Detail in hos/ho-04.7-run-feedback.md.

Depends on: ho-04.5 (the run verb and its SignalForwarder).

Phase 4 — The Workshop

The native Mac app. SwiftUI, Apple Silicon only, three-pane window (scopes / secrets / detail). ho-05 is the shell — window structure, scope navigation, secret editing, materialize and sync buttons. ho-06 is the polish that makes the GUI usable for non-experts — the three-state UI glyphs, the ingest decision matrix as a real flow, first-run experience, age key generation with backup nudge, heal surface. By the end of the phase, the vibe-coder success criterion (15-minute install-to-first-materialized-.env) is achievable in tests against a fresh user persona.

Release on phase complete: v0.4 (GUI + CLI, full primary workflow)

ho-05 — The Workshop: SwiftUI shell

Xcode project for Sharibako.app, SwiftUI window with the three-pane layout, scope sidebar driven by the Vault Core's list_scopes, secret center pane with name and link/value/materialize-target columns, detail slide-in with value toggle, notes, link target, rotation history (driven by git log). Top-level actions: Add Scope, Add Shared Secret, Rescan, Sync. Touch ID flows through LocalAuthentication. The shell is wired to the same shared core library the CLI uses — no duplication of vault logic.

Depends on: ho-01, ho-02, ho-03, ho-04 (the CLI's Keychain integration is the pattern to follow)

What's in scope:

What "done" means:

What's out of scope:

Decisions required:

ho-06 — The Workshop polish: first-run, ingest, three-state UI, age key

The polish ho. Three-state glyphs in the sidebar (live here / live elsewhere / orphaned), the ingest decision matrix as a real SwiftUI flow (not a terminal prompt), first-run experience (vault location, scan root, optional remote, age key generation with backup nudge), and the heal surface for drift. This is the densest single ho in the project; the practitioner's stage with SwiftUI also informs how it splits.

Depends on: ho-05

What's in scope:

What "done" means:

What's out of scope:

Decisions required:

Possible split: this is the densest single ho in the project. Realistic split candidates:

If the dandori-spec author can fit all three into one focused session, leave as ho-06. If not, split before opening the session.

Phase boundary — replan checkpoint. First-run + ingest + backup nudge are the moments vibe-coder usability succeeds or fails. Test with a real non-Andrew user before opening Phase 5. If the first-run flow needs another pass, insert ho-06.5 rather than carrying the weakness into the linking work.

Phase 5 — Linking UX

The parti-defining feature, made visible. Linking-the-capability already exists in the Vault Core from ho-01 — .link files and resolution are part of the data model. What this phase adds is the user-facing experience: link/unlink as first-class CLI commands surfaced with the right ergonomics, the GUI link target picker, a shared-secret browser ("what's in shared/? what links to it?"), and the rotation propagation surface (when a shared value rotates, the linking scopes should show "stale" until materialized). Success Criterion #4 ("Rotation is one action") closes here.

Release on phase complete: v0.5 (full MVP behavior; feature-complete for v1)

ho-07 — Linking semantics across both surfaces

The linking UX in both the CLI and the GUI. CLI: link, unlink work as first-class commands (they exist as Vault Core operations from ho-01; this ho adds the CLI surface and the affordances around them — name-match suggestions, "what would change?" preview). GUI: a link target picker modal (browse shared entries, search by name, see what already links to each), a shared-secret browser pane or sheet showing the full link graph at a glance, a "stale" indicator on linking scopes when a shared value rotates, and the "Materialize all stale" action the README's first-session vignette references.

Depends on: ho-04 (CLI base), ho-06 (GUI polish base)

What's in scope:

What "done" means:

What's out of scope:

Decisions required:

Possible split:

If GUI work in particular sprawls (the shared-secret browser is non-trivial UX), splitting along these lines is the natural cut.

Phase boundary — replan checkpoint. This is the "are we ready to ship?" gate. The MVP feature set is complete. Before investing in Phase 6's signing/notarization/website work — which is real time and has Apple-side latency — confirm that the v1 promise is delivered. If it isn't, insert another polish ho rather than locking in a release that doesn't honor the parti.

Phase 6 — Release

Distribution machinery and v1.0. ho-08 builds the Mac app bundle (Xcode notarization, DMG with bundled age, "Install CLI" first-run action) and the CLI distribution (Homebrew tap formula, Linux .tar.gz). ho-09 stands up the website, the release manifest, the in-app update check, and ships v1.0. The pricing model, shared-vault documentation, and auto-update mechanism specifics all resolve here.

Release on phase complete: v1.0 (public)

ho-08 — Bundling, signing, installer

Xcode notarization workflow adapted from M4Bookmaker's PyInstaller-shaped pipeline. The .app bundles the Swift GUI binary, the CLI binary, the age binary, and license notices. create-dmg or equivalent produces the .dmg. First-run "Install CLI" symlinks the bundled CLI to /usr/local/bin/sharibako (or /opt/homebrew/bin/sharibako). CLI distribution: Homebrew tap at sageframe-no-kaji/tap with depends_on "age", plus a direct .tar.gz for non-Homebrew users that bundles age inside.

Depends on: ho-05, ho-06 (Mac app builds and runs cleanly before signing matters)

What's in scope:

What "done" means:

What's out of scope:

Decisions required:

Possible split:

These have different infrastructure (Xcode + Apple ecosystem vs. Homebrew + Linux build) and different verification surfaces. Splitting is reasonable if one half hits friction.

ho-09 — Website, release, v1.0

Cloudflare Pages site at sharibako.sageframe.net (matches the M4Bookmaker pattern), release manifest endpoint, in-app update check, GitHub release for v1.0 with both the .dmg and the CLI .tar.gz attached, README and architecture.md and SECURITY.md final pass against actual shipped behavior, and resolution of the remaining deferred decisions (pricing, shared-vault doc, auto-update specifics).

Depends on: ho-08

What's in scope:

What "done" means:

What's out of scope:

Decisions required:

What's NOT in this sequence

Tracked for v1.5 / post-v1; explicitly out of v1:

Replan checkpoints

Three explicit pause points. At each one, the practitioner stops, evaluates progress against real evidence, and decides whether to continue as planned, insert a polish ho, or replan.

Checkpoint 1 — After ho-04.5 (CLI + injection usable)

What's true: the substrate works end-to-end, the CLI is usable, and both output verbs (materialize and run) are wired. Andrew has been consolidating real personal secrets into the vault and running his actual dev workflows via sharibako run. SECURITY.md exists in draft form.

What to evaluate: is the CLI awkward in ways the GUI won't fix on its own? Is Touch ID frequency on run tolerable, or does the sharibako-agent daemon need to move forward from post-MVP? Is signal forwarding robust against real dev-server behavior? Does SECURITY.md pass an outside-eye reading, or does it need another pass before Phase 6? Are there missing CLI commands real use surfaced?

Why this is a checkpoint: Phase 4 is a substantial investment (SwiftUI from scratch is half the project). Reality from Phase 3 should shape what Phase 4 actually needs to be — not the other way around. Injection specifically carries the threat-model coverage for Class 4 (workspace file-readers); if it's rough, Phase 4 shouldn't paper over it.

Outcome (fired 2026-07-03). The CLI was used on real secrets. Touch ID frequency on run was tolerable ("a security app; no problem with it") — the sharibako-agent daemon stays post-MVP. Foundation.Process propagated exit codes and signal-death faithfully; signal forwarding held (Ctrl-C terminated the child cleanly, no orphan) — no posix_spawn fallback needed. SECURITY.md's run/--dry-run sections were reconciled against shipped behavior (the memset_s claim was drift; corrected). One friction surfaced: run was silent at startup and across the Ctrl-C grace. That became ho-04.7 (run feedback), built and closed here rather than carried into Phase 4. Decision: proceed to Phase 4 (ho-05, the Workshop). The CLI is solid enough; no further CLI polish is gating.

Checkpoint 2 — After ho-06 (GUI polish complete)

What's true: the GUI is usable for primary workflows. First-run, ingest, and backup nudge exist as designed.

What to evaluate: can a real non-Andrew vibe-coder complete first-run-to-first-materialized-.env in 15 minutes (Success Criterion #3)? If not, the failure is here, not in Phase 5. Test with a real user before opening Phase 5.

Why this is a checkpoint: the linking UX in Phase 5 depends on the GUI's established idiom. If that idiom is weak, the linking UX will be weak on top of weakness. Insert ho-06.5 (first-run polish based on user testing) if needed.

Checkpoint 3 — After ho-07 (linking UX complete)

What's true: the MVP feature set is delivered. The parti — including the rotation-propagation feature — is visible everywhere it needs to be.

What to evaluate: does the project, used end-to-end, deliver every success criterion? Transcript leak stopped (1)? Scatter consolidated (2)? Vibe-coder unassisted success (3)? Rotation one action (4)? If any of these fail, an additional polish ho is the answer — not committing to Apple notarization on a v1 that doesn't actually work.

Why this is a checkpoint: Phase 6's signing/notarization work has Apple-side latency and binds the project to a public commitment. Confirm the v1 promise is delivered before locking in a release.

Numbering and insertion

The numbering scheme exists because plans evolve.

Anticipated splits and insertions

Candidates surfaced during the overview, by pattern:

Combined-scope hos likely to split:

Insertions likely after replan checkpoints:

Insertions likely from real-world data:

Other deferred decisions

Decisions that don't tie to a specific v1 ho. Tracked here so they don't get lost.

Dependency summary

Phase 0 — Foundation
└── ho-00 ──────────────────────────────────────────── v0.0 (private)

Phase 1 — The vault substrate
├── ho-01 (Vault Core)
└── ho-02 (Conduit) ──────────────────────────────────  v0.1

Phase 2 — The bridge
└── ho-03 (Materializer) ────────────────────────────── v0.2

Phase 3 — The Tool  (complete)
├── ho-04   (CLI MVP)
├── ho-04.2 (interactive init)
├── ho-04.3 (sign binary; Keychain biometry)
├── ho-04.4 (ingest dashboard — superseded)
├── ho-04.5 (sharibako run, clean, SECURITY.md draft)
├── ho-04.6 (plain-prompt init — replaces the dashboard)
└── ho-04.7 (run feedback)
        ▲
        │  ◆ Replan Checkpoint 1 — FIRED: proceed to Phase 4 ── v0.3

Phase 4 — The Workshop
├── ho-05 (SwiftUI shell)
└── ho-06 (GUI polish, first-run, ingest, backup nudge)
        ▲
        │  ◆ Replan Checkpoint 2 (vibe-coder test) ── v0.4

Phase 5 — Linking UX
└── ho-07 (link UX across CLI + GUI)
        ▲
        │  ◆ Replan Checkpoint 3 (v1 promise) ─────── v0.5

Phase 6 — Release
├── ho-08 (Bundling, signing, installer)
└── ho-09 (Website + v1.0) ──────────────────────────── v1.0

Dependencies:

What to do with this document

The overview is the map. Each ho is the destination for a Kamae 5 (ho-kamae-5-authoring-collaborator) session, which produces a per-ho dandori spec — the surgical, command-verifiable instruction the executing agent runs against. Open one ho at a time; do not write all the dandori specs in advance.

Update this overview as the build proceeds. A ho that splits gets its successors named here (ho-03 → ho-03.1, ho-03.2). A ho that surfaces a new decision gets the decision recorded against it. A replan checkpoint that fires gets its outcome noted, including any inserted hos. The overview is a living document; small frequent updates beat large rare ones.

When in doubt about a ho's scope: the overview's job is the spine (heading, narrative, dependencies, decisions, light scope, possible-split flag). The per-ho dandori spec's job is the operational depth (files to touch, exact tests, verification commands, commit format). If a question is about what the ho is, it belongs here. If a question is about how the ho gets executed, it belongs in the dandori spec.

The next dandori session is ho-05 — The Workshop: SwiftUI shell (Phase 4). Phases 0–3 are complete. Open ho-05 via the Kamae 5 collaborator when ready; its first work is scaffolding xcode/Sharibako.xcodeproj against the Swift package (deferred to exactly this point).

Phases 0–3 dandori specs live under agent-tasks/ and their per-ho documents under hos/; the closed ones are the historical record and do not get reopened. Phase 4 begins fresh at ho-05.

Rendered from the corpus, verbatim · source on GitHub →

ingested: sharibako @ a97b22af9b61 · ho-system @ 79e96b801a13 · the glossary · the colophon