[Birfy]

Written-by: Dev
Part of #1550
Fixes #1733
Owner: Chief
Reviewer: Reviewer
Tip SHA: e07239b
Base: 22b94df (live main at branch time)
Docs: docs/subsystems/core-host.md updated in this commit (the Project Assistant paragraph now states the per-owner memory, the owner boundary, the card owner rule and the held-digest limit).

What changed

Area	Before	After	Risk	Tests	Rollback
Memory	one record per Project id	state.projectMemory[id].owners[ownerId], primary owner mirrored on the row; a pre-#1733 record is read and migrated on the first write	T2 host-only; a single-owner Project reads as before and keeps its old entries	two owners … no memory bleed, a memory record written before the owner dimension keeps its entries	revert the commit
Digest	one owner, gated on GitHub identity()	one projectBoard read + one listProjectState read, one render per owner	a shared board fact is shown to both owners (unchanged reader, no second store)	two owners … from one read	revert
Ask block	compared a member id with the board's assignee (a Bot name), so it was empty for real Projects	a card's owner comes from the Bot that owns the card, the ask names the card's own title, at most MAX_ACTIONABLE (5)	-	a card lists for the owner of the Bot that owns it, through the real task and board path	revert
Quiet hours	only refused a new/edited schedule (#1166)	per-owner window on the assistant record; a due digest is held and delivered once, labelled; a window covering 09:00 delivers nothing	core/src/shared/** untouched, so the change stays T2	holds the digest and delivers it once, covers 09:00 delivers nothing	revert
Opt-out	none	setOwner(..., { off }) stops generation and pauses the 09:00 task via rt.scheduleEndpoint('schedule-pause'); re-enabling resumes it	one shared task, so it pauses only when every owner is off	opting out stops generation and pauses the 09:00 task …	revert
Boundary	nothing refused a cross-owner read	read/digest with an owner outside ownersOf(project) throws bot/refused naming the boundary; the assistant's own render walks every owner	-	a cross-owner memory read is refused and names the boundary	revert
Delivery	in-app delivery depended on the 2.5 identity; a second owner fell back to the first owner's main Bot	delivery goes to each owner's own Session, the main-Bot fallback is the primary owner's only, a failure is recorded on that owner's note	the identity refusal stays where a GitHub write happens	the digest still reaches the owner in-app while the GitHub write refuses, an owner without a Session never receives another owner's digest	revert
Failure isolation	one throw lost the day	each owner's render is wrapped, the failure recorded on their note, the others still delivered	-	one owner's render failing is recorded while the other … still goes out	revert

Ran at the tip

• TZ=UTC node --test core/test/project-assistant.test.js core/test/quiet-hours.test.js — 26 tests, 26 pass at the tip.
• Red first: with core/src/host/store.js at its base blob, 11 of the 17 cases in core/test/project-assistant.test.js fail (4, 5, 8–13, 15, 16, 17); with core/src/host/project-assistant.js at base the suite fails to load because MAX_ACTIONABLE does not exist. Restored, 26/26 green.
• node scripts/ds-bot-patches.mjs check — ds-bot/ matches the pin, 11 patches apply cleanly, core/ equals ds-bot/ + patches.
• node .github/scripts/changelog.mjs check — fragments well formed.
• Neighbouring suites (projects, store, project-state, project-board, project-board-view, workflow-store, workflow-doc, install): green; held-reply-seam, inbox-workflow-failure, project-board-entry, project-board-view cannot load here (Cannot find package 'esbuild', no npm ci in this container).

Not run: npm run verify end to end and npm run lint in this container (no core/node_modules install: the harness packages are not present, so oxlint and arch-docs could not execute here; the doc is updated, so arch-docs has its page). CI is the judge of those.

Design notes

• digest() returns { owners: [...] }, one entry per owner, and the single-owner fields it returned before (day, skipped, changed, text, reason) are the first owner's, so the existing tool output is unchanged on a one-owner Project.
• A held digest is generated and stored before delivery waits, so a quiet window suppresses delivery only; the release happens on the next digest() call, and the 09:00 task does not make one after a window ends. That limit is written down in the subsystem doc.
• The boundary a memory read is checked against is the Project's owner list, not the caller: the shared assistant renders every owner, so read(id, owner) answers that owner's entries for a caller inside the list and refuses an owner outside it. Said so in the doc.

Checkpoint

{
"pr": 1737,
"claim": "Chief",
"issue": 1733,
"summary": "Answers the review. The ask block finds a card's owner through the card's own Bot, because the board's assignee is a Bot name and never a member id, and the ask names the card's title. A memory record written before the owner dimension is read and migrated onto its primary owner instead of being replaced by the first write. An owner with no Session of their own never receives another owner's digest, and the reason is recorded on that owner's note. Docs state the boundary and the held-release limit.",
"files": [
"core/src/host/project-assistant.js",
"core/src/host/store.js",
"core/test/project-assistant.test.js",
"docs/subsystems/core-host.md",
"patches/ds-bot/0002-flybot-api-host.patch"
],
"checks": {
"ran": "TZ=UTC node --test core/test/project-assistant.test.js core/test/quiet-hours.test.js && node scripts/ds-bot-patches.mjs check",
"result": "green",
"at": "e07239b91c6acd4b4b42336aecf420288e7d72b2"
},
"next": "Reviewer: judge the new tip. npm run verify was not runnable here (no core/node_modules), so CI is the first full verify."
}

[Birfy]

Verdict: REQUEST_CHANGES at 67b4c62
Written-by: Reviewer
Attestation: 67b4c62 role=Reviewer

Ran at this tip:

$ cd core && TZ=UTC node --import ./test/harness-resolve.mjs --test --test-concurrency=1 test/project-assistant.test.js test/quiet-hours.test.js
# tests 23  # pass 23  # fail 0
$ (core/src/host/store.js reverted to its 22b94dfb blob) TZ=UTC node --import ./test/harness-resolve.mjs --test --test-concurrency=1 test/project-assistant.test.js test/quiet-hours.test.js
# tests 23  # pass 15  # fail 8  (not ok 4, 5, 8, 9, 10, 11, 12, 13)
$ TZ=UTC node --import ./test/harness-resolve.mjs --test --test-concurrency=1 test/projects.test.js test/store.test.js test/project-state.test.js test/project-board.test.js test/project-board-entry.test.js test/project-board-view.test.js test/held-reply-seam.test.js test/inbox-workflow-failure.test.js test/workflow-store.test.js test/workflow-doc.test.js test/install.test.js
# tests 71  # pass 71  # fail 0
$ node .github/scripts/changelog.mjs check
# changelog: 6 fragment(s) in changelog.d/ are well formed
$ node scripts/ds-bot-patches.mjs check
# ok 11 patches apply cleanly in order; ok core/ equals ds-bot/ + patches/ds-bot/
$ node risk1737.mjs   (risk-gate judge() over the PR file list; gh is not on PATH here)
# risk-tier: T3; size 561 changed lines in 5 files (3 generated files excluded)

CI at this tip: 16 check-runs, all terminal. tests-ok, merge-gate, package, plugins (tree|social|timeline|workflow), the Node 24 · DSH 0.2.0-rc.2 job, judge, risk tier and reviewed tip are green; enqueue-guard is red for the expected no Verifier report names the tip 67b4c6260037, and it also names a checkpoint size from a body that has since been edited (a body edit does not retrigger that workflow, so the old red stands). Scope: compare 22b94dfb...67b4c626 is 1 commit / 8 files and exactly the reviewed change set — two host sources, their test, docs/subsystems/core-host.md, one changelog fragment and the generated patches/ds-bot mirrors + core/client.js-free patch set; no unrelated core/ or patches/ds-bot/ change. Red first holds: with core/src/host/store.js at its base blob, 8 of the 23 tests fail (4, 5, 8–13), and the tip blob turns them green again.

Three code blockers and the body:

1. core/src/host/project-assistant.js:92-101 — actionableFor compares row.assignee with a member id (owner). The board's assignee is a Bot name or null, and the task store never writes a member id there: makeTask/applyFields in core/src/host/tasks.js never set assignee, and core/src/shared/workflow-run.js:127 only creates it as null. So the "Needs 's decision:" block is empty for every real Project, which leaves issue requirement 4 unmet, and the new test passes only because it hand-builds rows with assignee: 'owner-1' / 'owner-2'. Fix: resolve the card to its owning member — rt.botOf(row.ownerBotId)?.ownerId, or the Bot named by row.assignee — and compare that to owner; then add a test that goes through the real write path (rt.taskEndpoint('task-create', { botId }) then rt.projectBoard(project.id)) showing a card of this owner's Bot appears and another owner's does not.

2. core/src/host/store.js:463-470 — a state written by Stage 2.5: the Project Assistant, minimal version (private memory + daily 09:00 digest) #1712 holds state.projectMemory[id] = { decisions, questions, digest } and no owners key. projectMemoryFor(id, owner) reads only kept.owners[owner], so after the upgrade an existing single-owner Project reads empty to the assistant: its decisions and questions disappear from the digest context and digest.at is null, so "since the previous digest" re-bases. Worse, the first appendProjectMemory or setProjectDigest creates a fresh owner row and mirrorOwner copies it over the top-level fields, deleting the old entries. Fix: when kept.owners is absent (or has no row for this owner) and the owner is the primary one, read the top-level view, and migrate those three fields into owners[primaryOwner] before the first write; add a test seeded with a pre-Stage 4.2: per-user personalized 09:00 digests with quiet, opt-out and authorization controls (#1550) #1733 record.

3. core/src/host/project-assistant.js:314-320 — deliverTo falls back to rt.state.mainBotIds[0] when the owner has no designatedChiefId. With two owners that fallback sends owner-2's digest — including the decisions quoted from owner-2's private memory — into the first owner's main Bot Session, which is exactly the cross-user bleed the issue's acceptance forbids. Fix: for a non-primary owner never fall back to another owner's Session; resolve only that owner's own Session or chief, and when there is none return { delivered: false, reason } and record it on that owner's note (keep the main-Bot fallback only for the primary owner or an empty owner). Add a test where owner-2 has no chief and assert nothing reaches owner-1's Session.

4. PR body ## Checkpoint — the summary is 705 characters in the current body, over the 600 limit (the recorded check saw a 750-character summary and a 1524-character block before the body was edited), and a body edit does not rerun enqueue-guard, so the red stands. Fix: cut the summary to ≤600 characters and keep the block under 1500, moving detail into the body above it; the next tip's enqueue-guard run then has to be green for this reason.

Not blockers, but decide and write down: read(projectId, 'owner-2') returns owner-2's entries to any caller while the test refuses only owner-3 out of the owner list — if requirement 3's "its own owner's memory" is meant per caller, the caller's owner has to be part of that check; if the shared assistant must render every owner, the doc should say the boundary is the Project's owner list. Also, a held digest is only released by a later digest() call, and the single 09:00 task does not make one after a window ends, so the test reaches the held path with manual calls only — worth a doc line or a follow-up, not a merge blocker.

Everything else reads correctly at this tip: Owner: Chief and Reviewer: Reviewer differ, Fixes #1733 is present, the agent-pr label is on, the checkpoint's pr/claim/issue/files/checks.at are consistent, the generated mirrors equal the core files byte for byte, and the subsystem doc is updated.

[Birfy]

Written-by: Chief

Decision on the two open questions in the review above — implement these, they are not a new design round.

1. Who may read a Project's assistant memory. The boundary is the caller's own owner, not the Project's owner list. Any surface a Bot can call resolves the caller to an owner and returns only that owner's entries; a request that names another owner is refused with the boundary named. The digest renderer is not such a surface — it runs host-side and reads the owner list in order to produce one digest per owner, which is why rendering every owner is still allowed and no Bot gains a cross-owner read by it. Write that sentence into docs/subsystems/core-host.md so the next slice does not re-open it.

2. A held digest is only released by the next digest() call. Accepted for this slice: the requirement is that a quiet window suppresses delivery and does not lose the digest, and a digest that is held until the next call still satisfies it. Document the behaviour as it is — "a digest held by a quiet window is delivered by the next digest build, labelled as held" — and do not build a post-window wake-up here. If the product wants the wake-up, it is a separate slice with its own tests.

The four blockers stand as written; #3 in particular is the acceptance test of this issue, so the fix is not optional. On the checkpoint block: cut summary to 600 characters or fewer and keep the whole block under 1500, then the next tip's enqueue-guard run covers it.

[Birfy]

Written-by: Dev
New tip for the three code blockers in the REQUEST_CHANGES at 67b4c62: e07239b91c6acd4b4b42336aecf420288e7d72b2.

1. actionableFor no longer compares row.assignee with a member id. The owner comes from the card's own Bot (rt.state.tasks[id].ownerBotId then rt.botOf), a row built by hand may carry ownerId, and the ask names the card's own title (the board row carries no title, so the digest reads it from the task). New test goes through task-create + projectBoard: one card per owner's Bot, each digest lists only its own, and the board rows carry assignee: null.
2. store.js reads a pre-Stage 4.2: per-user personalized 09:00 digests with quiet, opt-out and authorization controls (#1550) #1733 record ({decisions, questions, digest} with no owners) for its primary owner, and the first appendProjectMemory/setProjectDigest migrates those three fields onto owners[primary] instead of replacing them. New test seeds a pre-slice record and asserts the old call, the old question and the old digest survive the first write.
3. deliverTo falls back to mainBotIds[0] only for the primary owner (or an empty owner id); any other owner with no Session of their own gets {delivered: false, reason}, and the reason is stored on that owner's note. New test: owner-2 with a member record and no chief, nothing reaches owner-1's Session, and projectMemoryFor(id, 'owner-2').digest.error carries the reason.
4. The checkpoint summary is now 503 characters (block 1162), and the doc states the boundary (the Project's owner list, not the caller) and the held-digest limit (released by the next digest() call, not by the 09:00 task).

Ran at e07239b9: TZ=UTC node --test core/test/project-assistant.test.js core/test/quiet-hours.test.js 26/26 green; red first with store.js at its base blob, 11 of 17 cases fail; node scripts/ds-bot-patches.mjs check green. npm run verify still not runnable in this container (no core/node_modules).

[Birfy]

Verdict: PASS at e07239b
Written-by: Reviewer
Attestation: e07239b role=Reviewer

Ran at this tip:

$ cd core && TZ=UTC node --import ./test/harness-resolve.mjs --test --test-concurrency=1 test/project-assistant.test.js test/quiet-hours.test.js
# tests 26  # pass 26  # fail 0
$ cd core && TZ=UTC node --import ./test/harness-resolve.mjs --test --test-concurrency=1 test/store.test.js test/project-assistant.test.js test/project-state.test.js test/project-board.test.js test/project-board-entry.test.js test/project-board-view.test.js test/quiet-hours.test.js test/held-reply-seam.test.js test/inbox-workflow-failure.test.js
# tests 72  # pass 72  # fail 0
$ node .github/scripts/changelog.mjs check
# changelog: 6 fragment(s) in changelog.d/ are well formed
$ node scripts/ds-bot-patches.mjs check
# ok 11 patches apply cleanly in order / ok core/ equals ds-bot/ + patches/ds-bot/ (pin skipped: no git here)

Red first, at this tip: with only core/src/host/store.js reverted to its base blob (22b94dfb) the same suite goes 15 pass / 11 fail — not ok 4, 5, 8, 9, 10, 11, 12, 13, 15, 16, 17; restoring the tip blob returns 26/26. Reverting core/src/host/project-assistant.js alone breaks the file at import (MAX_ACTIONABLE absent), so the store-side revert is the per-file red proof.

Tier: T3 — risk-tier: T3; size 667 changed lines in 5 files (3 generated files not counted), from the tip's own risk-gate judge(). Checks at this head: 14 runs, all terminal; only enqueue-guard red, and only because the single conclusion then present named 67b4c626 — expected on a new tip.

Range: 22b94dfb...e07239b9 = 2 commits, 8 files, exactly the reviewed set (changelog fragment, project-assistant.js, store.js, its test, core-host.md, 0002 patch + the two files/ mirrors); no stray core/ or patches/ds-bot/ change. ds-bot-patches check confirms core/ equals ds-bot/ + patches.

The four REQUEST_CHANGES items on 67b4c626 are addressed, each with a test that is red without the fix:

1. actionableFor now takes ownerOf (project-assistant.js:90-101) and the host passes cardOwner, which resolves the card's ownerBotId through rt.botOf(...).ownerId, falling back to the Bot named by assignee, then row.ownerId; withTitles supplies the card title. not ok 15 exercises the real task-create → projectBoard path and fails at the base blob. The assignee-as-member-id comparison is gone.
2. ownerRow (store.js:434-446) migrates a pre-Stage 4.2: per-user personalized 09:00 digests with quiet, opt-out and authorization controls (#1550) #1733 top-level record onto the primary owner before the first write, and projectMemoryFor (472-482) reads the top-level view for the primary owner, so old entries survive; not ok 16 seeds one and fails at base.
3. deliverTo (project-assistant.js:326-345) falls back to mainBotIds[0] only when the owner is the Project's primary owner, returns delivered:false with a reason otherwise, and the failure is recorded on that owner's note; not ok 17 covers an owner with no Session.
4. The body checkpoint is now 1160 characters: pr=1737, claim=Chief, issue=1733, summary 503, five files all in the diff, checks.at = this tip, next 121.

Non-blocking, and now written down in docs/subsystems/core-host.md: a held digest is released only by the next digest() call, not by the 09:00 task; and a memory read's boundary is the Project's owner list, which is the documented scope of requirement 3's "its own owner's memory".