Roadmap and operating playbook
Choose the next bounded unit by prerequisite and proof—not by upstream feature count.
Pinned upstream commit: b189869b7755d2b482969acf6c92da3ecfeffd36
- Choose a future unit from product need and prerequisite readiness.
- Write a real proof boundary before implementation.
- Keep rejected duplicate surfaces out of the roadmap.
The big idea
Phase one is complete when the opt-in provider works and its limits are explicit. Future work should advance one honest boundary at a time: first image readiness if production needs Grok, atomic session storage if resume matters, or ACP/stdio research if tool telemetry is worth the complexity. The rest stays with existing Alembic owners.
Think of it like… Treat the roadmap like a climbing route: each anchor must hold before you move weight onto the next one. The analogy breaks because independent branches—Docker, sessions, telemetry—can be climbed separately when the product need is clear.
Candidate A: pin and install Grok in `.factory/Dockerfile`, choose non-leaking auth injection, and run the exact sentinel inside the image. Candidate B: generalize session storage from one file to an atomic directory bundle, then prove capture/resume/fork. Candidate C: evaluate ACP/stdio for structured tool events while preserving the AgentProvider narrow waist.
Do not auto-route Grok, copy the Rust runtime, or create parallel hooks/plugins/TUI/sandbox subsystems. Re-open the pinned/live upstream docs before each unit because CLI flags and event shapes can drift. Every unit gets owner, blocker, proof command, rollback, and an independent validator.
Evidence: Pinned session management guide
Compare the boundaries
Safe: one bounded unit, explicit owner, blocker, proof, and rollback.
Risky: “internalize everything” as a permanent parallel platform.
| Surface | Upstream | Alembic | Verdict |
|---|---|---|---|
| Docker readiness | Needed for Factory image use | Pin + auth + in-image smoke | NEXT IF NEEDED |
| Session bundle | Needed for resume/fork | Atomic directory storage | DEFER |
| ACP telemetry | Needed for tool events | Protocol research + adapter proof | DEFER |
Do not auto-route Grok, copy the Rust runtime, or create parallel hooks/plugins/TUI/sandbox subsystems. Re-open the pinned/live upstream docs before each unit because CLI flags and event shapes can drift. Every unit gets owner, blocker, proof command, rollback, and an independent validator.
Real code and commands
packages/factory/README.md (phase-one contract)
const nextUnit = {
id: "grok-docker-boundary",
prerequisite: "production actually needs Grok",
proof: [
"grok --version inside the pinned image",
"exact sentinel through factory.run inside the image",
"no credential in image layers or logs",
],
changesRoster: false,
};How to reach it
sed -n '1,80p' packages/factory/README.md rg -n "captureSessions|resumeSession|forkSession" packages/factory/src/GrokAgentProvider.ts
Evidence: RESOURCES.md
Visual atlas
Practice and feedback
Tool-call telemetry is desirable, but no product consumer needs it yet. What is the next action?
Retrieval cards
Tune the next unit
Select a desired outcome and read the smallest honest next unit.
Four-slide summary
Check your model
What should select the next roadmap unit?