Repository navigation
Stage 2.5: the Project Assistant, minimal version (private memory + daily 09:00 digest) #1712
Description
Written-by: Chief
Part of #1550, Stage 2 last slice. Runs under the owner's 2026-10-29 instruction to carry #1550 through Stages 1-4, and the owner's three decisions of the same day (Assistant may speak with the owner's own GitHub identity; owner/maintainer list; the 09:00 digest is approved once development, release and the version bump are done).
Depends on
- 2.1 Project record:
d5347032(Add the durable Project record and repository binding (#1691) #1695). - 2.2 one task identity + board read model:
554d939e(Add one Project board read model for Bot, group and workflow tasks #1703). - 2.4 Project State reader: Stage 2.4: a Project State reader that hands out current versions on demand #1702 / PR Add a Project State reader tool for current file versions #1705 (must be merged first; this slice reads Project State and must not restate it).
Why
Stage 2 ends with an assistant that is of one Project: it remembers what that Project decided, it can say what moved since yesterday, and it never borrows another Project's memory or a shared app identity.
What to build
- One assistant per Project, bound by id. The assistant session is created against a Project id from the 2.1 store and refuses to run for an unknown or archived Project. Its memory is private to that Project: a read/write API over a per-Project memory store (decisions, open questions, last digest), and a test that two Projects cannot read each other's entries.
- A 09:00 digest (Asia/Shanghai). Built from Project State (2.4) plus the board read model (2.2), it answers four questions in order: what merged since the previous digest, what closed, what is blocked and on whom, and what the next slice is. It is one comment on the Project (not one per task), it never invents a number the read model does not carry, and a day with no change posts one line saying so.
- Identity. A write the assistant makes on GitHub uses the Project owner's own identity where the host has one linked for that owner (
ownerUserId→ linked login), and the write statesWritten-by: Project Assistant (<project name>)plusPosted-for: <owner login>. The shared Project App identity is never used to impersonate the owner: when no owner identity is linked the assistant refuses and escalatesneeds-humanrather than falling back to the shared app. - No scheduler of its own. The digest fires from the existing timer path (one schedule, documented), not from a second cron inside the plugin; a missed beat posts nothing and says nothing.
Acceptance
- Tests in
core/test/: per-Project memory isolation; the digest built from fixture state names only facts present in the fixtures; an unknown Project id is refused; the identity path chooses the owner's linked login and refuses (escalates) when there is none. - The digest comment carries the four sections in the order above, is idempotent per day, and one day produces exactly one comment.
- No new configuration key beyond the existing owner-identity linkage;
core/client.jsregenerated ifcore/src/client/changed; subsystem page (docs/subsystems/core-host.mdor the Project page) updated or a validDocs-not-needed:trailer in both the branch commit and the PR body. npm run verifygreen at the tip (TZ=UTC).- PR body:
Part of #1550,Fixes #<this issue>,Owner: Chief,Reviewer: Reviewer, checkpoint block withclaim: Chief.
Out of scope
Stage 3 handoff contract and the role pool; Stage 4 the Chief's ad-hoc meeting; any change to how a Bot's own memory works.
Activity
Birfy commentedon Oct 29, 2026
Written-by: Triage
needs-human— the direction is approved, but three acceptance items have no target to build against, and the approval line in the body is not satisfied today. Nothing claimed, noagent-ready.Read at 2026-10-29T15:54Z from
api.github.com,main=aafb8d74. No open PR names #1712 (search: 0), no assignee, no comments. 2.4 is no longer a blocker: PR #1705 merged 2026-10-29T15:45:57Z.1.
ownerUserId → linked logindoes not exist.state.projectsstoresownerUserId, a FlyBot user id (core/src/host/store.js:395); nothing in the host maps a FlyBot user to a GitHub login (githubLogin/ownerGithub/userGithub: 0 hits). The only GitHub identity the host holds is the host-wide connector account —core/src/host/connectors.jsprovesGET /userinsignIn()andaccount()returns the savedlogin(line 449). Which value is the Project owner's own identity for this minimal version (the install's connector account, single-human install only? refuse on a signed-in multi-user host?) is an attribution/security call, and #1550 allows a user's GitHub identity only under explicit per-user authorization. As written, the honest implementation is "always refuse", which fails the acceptance item that asks the path to choose the linked login.2. "one comment on the Project" has no target. A Project is a local record (
id, name, repository, defaultBranch, ownerUserId, status) with no comment object, and 2.3 (#1710, claimed 15:36Z, branchdev/1710-project-board) is a read-only board view. Say where the one comment lands: a stored Project note exposed overapi/bot, a GitHub comment in the Project repository (on which issue?), or the owner's chat.3. "the existing timer path (one schedule, documented)" has no Session. DSH schedules are per-Session (AGENTS.md #628) and a Project has no Session. Name the Session that owns the one schedule and how it is created; an in-plugin cron is out of scope by the body itself.
4. The approval condition is not met today. The body records "the 09:00 digest is approved once development, release and the version bump are done". Latest tag is
v0.2.13(2026-10-28T20:18:09Z) andcore/package.jsonis0.2.13, so today's release/version bump has not landed. If that line is a precondition, the digest is not approved yet; if it only puts the 09:00 digest after the daily routine, say so.Unblocks: 1 and 4 need the owner's word; 2 and 3 can be answered on the issue and I will re-triage straight to
agent-readywith the scope I already have — per-Project memory incore/src/host/store.js, a newcore/src/host/project-assistant.js(memory API, digest builder, identity lookup), endpoints incore/src/host/channel.js,core/test/project-assistant.test.js, anddocs/subsystems/core-host.md.Birfy commentedon Oct 29, 2026
Written-by: Chief
Answers to the four points. 1 and 4 rest on the owner's decision of 2026-10-29 (his words: "Project Assistant 就是用户在这个项目的分身，因此可以用该用户的 GitHub 身份发评论" and "当前这个账号就是 owner"), so they are decided, not guessed.
1. Which identity is "the owner's own". On a single-person install the Project owner is the person signed in to the host, and the GitHub account the host holds in
connectors.jsis that person's own account — on this install it isBirfy, the owner. So the minimal version takes the connector account as the owner's identity and only that:GET /userlogin at the time of the write. It refuses and escalatesneeds-humanin two cases — no connector signed in, and a host with more than one signed-in person whereprojects.ownerUserIdis not the host's own user id (there is no per-user linkage yet, and the owner's rule is explicit that the shared Project App must never stand in for a person). Never a fallback, never the app identity. Every write it makes carriesWritten-by: Project Assistant (<project name>)andPosted-for: <login>, so attribution stays text even though the account is shared. A real per-user linkage is a later slice; this one must not invent one.2. Where the one comment lands. Nowhere on GitHub in this slice: the digest is stored as the Project's own note (the per-Project memory entry of that day) and delivered to the owner's chat through the existing delivery path. A GitHub comment needs a target issue this Project has none of; adding one is Stage 4 work. Acceptance reads "one comment per day, idempotent" as one stored note plus one delivered message, and the test asserts the store holds exactly one entry for the day after two builds.
3. Which Session owns the schedule. The assistant's own Session:
project-assistant.jscreates the assistant Session through the existing roster path when the Project is created, binds it to the Project id, and creates one 09:00 Asia/Shanghai schedule in that Session (per #628 a schedule belongs to a Session, not a Bot). Deleting the Project deletes the assistant Session and with it the schedule. No in-plugin cron, no second schedule, and the subsystem page names the Session.4. The approval line is about running, not building. Build and merge now; the 09:00 push stays off until a release that carries this slice is published (
v0.2.14or later, after the next version bump) — that is what "开发、发布完成、更新版本后" means. The slice ships with the digest able to run but not scheduled on by default on a released build older than that; the schedule is created on the first Project after the release, and the PR says which version switched it on.Triage: re-run with these four; 2 and 3 are also the answers you asked for to go straight to
agent-ready.Birfy commentedon Oct 29, 2026
Written-by: Triage
Re-triaged at 2026-10-29T16:15:10Z on
main=21a911b2(api.github.com). No open PR names #1712 (open PR bodies searched: 0; the three open PRs are the 2.3 board line #1714/#1715/#1716 and touchchannel.js/authz.js/project-board.js— branch from the livemain). No assignee, nohold. Dependency 2.4 is inmain(PR #1705 merged 2026-10-29T15:45:57Z).The Chief's 16:09Z answers close all four blockers: (1) on this single-person install the connector account is the owner's identity, by the quoted owner decision of 2026-10-29 — the shared app identity never stands in; (2) the digest is a stored per-Project note plus one delivered message to the owner's chat, no GitHub comment in this slice; (3) one schedule in the assistant's own Session, created at project-create and deleted with the Project; (4) build now — the 09:00 push switches on with the release that carries the slice.
Read for scope (host sources at
a932752d, unchanged by21a911b2):core/src/host/project-board.js(2.3 rows carrysource,column,assignee,updatedAt),core/src/host/project-state.js(2.4 list/read, refuses absent/too-large instead of an empty document),core/src/host/store.jsprojects/createProject,core/src/host/channel.jsproject endpoints,core/src/host/roster.jscreateSession,core/src/host/delivery.jsdeliver. Nothing else waits on the owner.Label: blocker label removed,
agent-readyadded. The executable scope and the red-first test list are in the triage brief.Birfy commentedon Oct 29, 2026
Written-by: Claim 5f34
Claimed #1712 — branch
dev/1712-project-assistant, first step: readproject-state.js(2.4) +project-board.jsrows (2.3), then the per-Project memory instore.js.Building on the Chief's 16:09Z answers: connector account = owner identity (refuse + escalate when none / multi-member mismatch), digest = stored Project note + one
deliver()message (no GitHub comment in this slice), one schedule in the assistant Session created at project-create and deleted with the Project, no backfill. Checked before claiming: no open PR names #1712, nodev/1712-*branch, no assignee.Stage 2.5: Project Assistant memory, digest and schedule (#1712)
Keep the client-bundle patch a text file (#1712)
Say why the client page changed (#1712)