Will kazi accept the two upstream additions dira's seams still depend on?

**Reduced from three asks to two on 2026-07-29.** The third — an optional `why` field on goal-files — turned out to be unnecessary: goal-files already carry a free-form `metadata` table, documented at `lib/kazi/goal/loader.ex:24` as stored **verbatim** and read with no validation (`loader.ex:640`). dira writes `metadata.why = "dira:dec-NNNN"` today. Downward traceability needs nothing from kazi, which also removes the one ask that would have put a dira-shaped string into kazi's file format.

Two asks remain, both small, both additive, neither breaking. Ordered by dira's need:

1. **Register `portfolio` in `Kazi.CLI.Schema`.** It already emits `schema_version` and a stable shape; registering it makes the contract discoverable and puts it under the lockstep-version rule, so dira's join surface stops being a private implementation detail it merely happens to read. Lowest cost, highest value. 2. **A post-disposition hook on `approve` / `reject`.** The event dira most wants to subscribe to. It should be as thin as an optional configured command invoked synchronously with the proposal ref and the new state.

**Explicitly not the session bus.** An earlier version of this entry suggested riding ADR-0067's bus as `bus post` on disposition, "rather than new infrastructure." That was wrong on verification. The bus is hosted by `kazi daemon` (a long-lived per-machine process supervising `nats-server`), and ADR-0067 states that everything on it "degrades gracefully when the daemon is not running: bus surfaces report 'no daemon' cleanly and no-op." It would also couple dira's core capture to a daemon, contradicting int-0002 and cst-0004.

**Corrected 2026-07-31, before this was filed upstream.** This paragraph used to claim a disposition made with the daemon down "would vanish, and nothing would indicate it had." That was an over-claim and did not survive verification: every bus verb prints a one-line no-daemon error and exits 1, so a *direct* `bus post` fails loudly. Whether an internal disposition-to-bus path would swallow that is a claim about code nobody has written, and it is not ours to make.

The verifiable argument is stronger anyway, and it is made in kazi's own words: ADR-0067 states that **convergence never depends on the bus** — a goal must converge identically with the daemon down. Disposition must hold to the same rule. So the signal is absent in exactly the case the bus is designed to tolerate, and a consumer cannot distinguish "no disposition happened" from "the daemon was down".

The bus is also the wrong *shape*: its `event`/`intent` stream is age-bounded to roughly 24h, and messages are capped near 1 KB with digest-based reads. That is correct for ephemeral coordination chatter and wrong for a durable ledger. (Which is also why the bus is **not** redundant with dira: it is ephemeral operational "now," dira is the permanent record of why.)

A direct synchronous hook has neither problem and needs no daemon. The honest risk: kazi's README stakes out a deliberate boundary — it will never decide what to build. Ask 2 could read as dira colonising kazi's surface with its own concerns, and kazi may reasonably refuse. Ask 1 is defensible on kazi's own terms regardless of dira: an emitted-but-undocumented `--json` shape is a gap in kazi's public contract whether or not anything consumes it.

Fallback if either is declined, so this question blocks nothing:

- (1) declined → dira pins the shape and tests against a recorded fixture, accepting breakage risk on kazi upgrades. - (2) declined → the skill wraps `approve`/`reject`, or dira diffs proposal state between sessions. Worse ergonomics, same outcome.

Answer by opening the two issues at `kazi-org/kazi` and letting the maintainer decide — same person, but the decision belongs on kazi's side of the boundary.