Repository navigation
[Direction]: Architecture and research incubator #3246
Description
Purpose
Keep architectural experiments visible without presenting every RFC as shipped
behavior or implementation-ready work. This tracker is an index and decision
log; each implementation still needs its own bounded issue or PR.
Portfolio
| Exploration | Stage | Current entry |
|---|---|---|
| Effect Program and settlement algebra | Accepted / runtime hardening | RFC |
| TypeScript control-plane migration | Draft / parity experiment | #3225 |
| Hierarchical agent stride | Research qualification | #3203 |
| Research exploration control plane | Draft / typed frontier | RFC |
| Human Attention Wishlist | Draft / non-blocking sidecar | RFC |
| Goal artifact lifecycle projection | Draft / read model | RFC |
| Post-outcome memory utility attribution | Draft / research | #3214 |
| Goal Channel and Agent IM/OpenViking boundaries | Draft / integration exploration | RFC index |
Stage rule
- Accepted / hardening: the architectural decision is adopted; contributors
may improve tests or the shipped contract without reopening the whole design. - Incubating / qualification: a real implementation or parity candidate
exists, but promotion gates remain. - Research: experiments and evidence come before default product behavior.
- Draft: design review is welcome; implementation starts only from an
explicitly agreed smallest slice. - Held: visible for context, but no implementation should begin yet.
Scope rule
An RFC is not runtime truth. Each proposed abstraction needs a shipped caller,
an independently useful compatibility contract, or a focused qualification
fixture before entering production code. Do not create speculative modules,
wide protocols, or duplicate control-plane authority merely because a design
could support them later.
Use this issue to surface missing relationships, maturity changes, and the next
decision for an exploration. Use a separate issue to claim concrete work.
Activity
huangruiteng commentedon Aug 16, 2026
Direction governance is now merged in
#3248.
This issue remains the long-lived direction and decision tracker. Concrete
implementation should use a separate bounded issue or task-board row with an
explicit base branch, smallest slice, non-goals, and validation plan.
docs: trim the technical-directions map to its live sections