As a maintainer running the interview, I want it to ask who the project onboards and what a session record is for, so that a solo-owned library is not handed a document nobody reads and a journal entry per session.
What
Add two interview questions and let the answers drive docs.md. First, who is onboarded: a team, in which case docs/ONBOARDING.md is generated and owns the setup while README section 6 points at it, or a single owner, in which case no ONBOARDING is generated and README section 6 stays self-contained. Second, the session-record cadence: every session, or on event only, meaning an entry is owed when a session produces a post-mortem or leaves work undone, and otherwise nothing is written. docs/PLAYBOOK.md stays unconditional; the dev-journal.md MUST for agent-assisted projects becomes "one of the two cadences, chosen at the interview".
Why
Today INTERVIEW.md generates ONBOARDING and PLAYBOOK unconditionally at three places (lines 94, 117 and 144), and docs.md requires a journal entry per session. On a single-owner library this produces a 157-line ONBOARDING that restates the README and PLAYBOOK, and a journal where 5 of the last 30 commits on main are journal-only merges, measured on pyomb on 2026-09-11. The continuity job the journal was given is now shared by decision records, the tracker, the changelog and the agent's own memory, so what it uniquely carries is the post-mortem and the "not done" list, which is exactly what the on-event cadence keeps.
Acceptance criteria
Related
As a maintainer running the interview, I want it to ask who the project onboards and what a session record is for, so that a solo-owned library is not handed a document nobody reads and a journal entry per session.
What
Add two interview questions and let the answers drive
docs.md. First, who is onboarded: a team, in which casedocs/ONBOARDING.mdis generated and owns the setup while README section 6 points at it, or a single owner, in which case no ONBOARDING is generated and README section 6 stays self-contained. Second, the session-record cadence: every session, or on event only, meaning an entry is owed when a session produces a post-mortem or leaves work undone, and otherwise nothing is written.docs/PLAYBOOK.mdstays unconditional; thedev-journal.mdMUST for agent-assisted projects becomes "one of the two cadences, chosen at the interview".Why
Today
INTERVIEW.mdgenerates ONBOARDING and PLAYBOOK unconditionally at three places (lines 94, 117 and 144), anddocs.mdrequires a journal entry per session. On a single-owner library this produces a 157-line ONBOARDING that restates the README and PLAYBOOK, and a journal where 5 of the last 30 commits on main are journal-only merges, measured on pyomb on 2026-09-11. The continuity job the journal was given is now shared by decision records, the tracker, the changelog and the agent's own memory, so what it uniquely carries is the post-mortem and the "not done" list, which is exactly what the on-event cadence keeps.Acceptance criteria
INTERVIEW.mdasks both questions, and a solo-owner answer generates no ONBOARDING while a team answer generates one that README section 6 defers todocs.mdstates the two journal cadences and what an on-event entry must contain, andscope.md's end-of-session audit reads the chosen cadence rather than always writing an entryRelated