Built on the Hannah Stulberg / Carl Vellotti TeamOS pattern, diverged where PP's shape (one repo, multiple products coming, small team) called for it. Four structural decisions recommended by Aaron. No moves happen until Mario signs off.
Four structural choices. Read the tree first, then dive into details below if anything reads off.
The repo we're structuring is one of four surfaces the team operates across. Each has a different audience and purpose. The repo holds canonical artifacts; everything else syncs from or coordinates around it.
Canonical product specs, principles, strategy, industry knowledge. The source of truth. Future home: peachpilot-ai/teamos.
Ticket specs from the repo get loaded into Linear issues. Benihana reads, implements, runs through Ready for QA. Humans drive QA + Awaiting Release + Done + status tracking. Bug sub-issues (Bug + qa-bug labels) live here.
Action items, decisions log, advisor engagements (Alon Bochman page). Keeps Linear clean for the fleet. Where this kind of cross-team review lives.
Daily product-development thread, vendor coordination, ad-hoc decisions. Captures the moment-by-moment. Important calls get promoted to Notion or the repo as canonical.
Click any folder to expand it. Hover any underlined item for a longer description.
Four decisions Aaron recommends. Push back on any if the framing reads wrong.
Decision: `product/right-quote/`, future `product/peach-live/` and others as peers. Cross-product folders (`personas/`, `industry-knowledge/`, `principles/`) sit alongside.
Admin clarification: Admin is a settings menu within Right Quote, not a separate product. The A1-A4 admin tab specs live under `product/right-quote/specs/` with the agent flow specs.
Diverges from Hannah's function-first PRDs/{area}/ shape. PP has a multi-product roadmap.
Decision: Each product holds its own ticket specs in a `specs/` subfolder. One file per screen / surface.
Preserves the existing pattern. Linear ticket references need an audit before move - resolved in flag 1 below.
Decision: `research/` keeps its top-level slot for in-flight learning. `product/` holds canonical references only.
Promotion from research/ to product/ is an explicit editorial step - see lifecycle below.
Revisit at 3 months. If editorial gate isn't being maintained, fold research/ into product/.
Decision: `product/meetings/{standup, vendor-discovery}/`. Customer call summaries live under `product/customers/{name}/calls/`.
1:1s and other personal-meeting notes file outside the team repo. Standup and vendor-discovery are PP-team artifacts worth sharing.
How a learning artifact moves from in-flight notes to canonical reference. The promotion step is an editorial moment - "is this actually canonical now?"