Privacy boundary
This is a public roadmap issue. No real trade, holding, amount, date, thesis, evidence item, source, or other content from any private repository may be copied into this issue or into fomo-kernel. Product lessons must be expressed only as generic requirements, public research, or fictional fixtures.
Status
Owner-updated to enforce staged scope and a strict separation between the public kernel and any private investing workflow.
This issue is a staged product roadmap and scope guard, not a request to reproduce a full investment workflow and not an implementation epic.
Phase 1 slices: #479 (book-aware lane, landed as M1) and #597 (no-book entry lane, owner-ruled into this phase 2026-07-30).
Foundation and safety: #467, #456, #478, #414.
Product decision
FOMO Kernel should not become a full investment OS, wealth manager, research terminal, or copy of any private investing system.
Real investing use validates the needs, not the amount of product that must be copied:
- information before a trade matters;
- the reason for acting matters;
- portfolio consequence matters;
- later outcomes should be compared with what was believed at the time;
- personal rules should eventually be tested rather than merely written down.
The narrower product thesis is:
FOMO Kernel is a local, auditable decision-accountability kernel for trading. It challenges the next trade against the user's actual book, records the minimum context needed to judge that decision later, and gradually learns which personal rules deserve to survive.
A host may have rich research, ticker notes, news collection, or a private investment process. FOMO Kernel does not need to own or ingest those systems. It needs a small, explicitly supplied contract for receiving the decision-relevant result.
Core user questions
The long-term product should become unusually good at answering:
為什麼當初買？
現在加碼的理由，和當初一樣嗎？
這是真的新證據，還是價格下跌後的合理化？
這筆交易會讓組合變成幾個高度相關的同一押注嗎？
上次用相同理由加碼，發生了什麼？
我訂過的規則，到底有沒有用？
These remain the product direction. They do not all need to ship in the first version.
Market conclusion, kept short
Adjacent products already cover AI journals, behavioral analytics, thesis notes, research workflows, broker sync, and portfolio advice. Breadth is therefore not the opportunity.
The differentiating loop is the connection between:
what the user knew / believed
→ what the proposed trade does to the actual book
→ what the user decided and executed
→ what happened afterward
→ whether the reason, rule, and agent judgment held up
The first release only needs to make the first two arrows useful and preserve enough explicitly supplied context for later reconciliation.
Staged roadmap
Phase 0 — make the existing two capabilities trustworthy
Goal: review and consider must quote the same honest portfolio footing before more memory is added.
Work already has homes:
Phase 0 adds no broad product capability. It prevents the next phases from learning from or advising against the wrong book.
Phase 1 — minimal pre-trade decision loop
Goal: make one pre-trade conversation useful without requiring a full profile, ticker wiki, research database, or review card.
A user should be able to say:
"I am considering adding this position. My current reason is X; what changed is Y."
Two entry lanes, one conversation
Owner ruling 2026-07-30: evidence is a gradient, not a 1/0, and refusing to answer is not the mechanism that earns an upload — guidance is. A user with nothing recorded still enters here; they are walked up, and the product's own chain has to earn the trade history rather than demand it as a precondition.
| Lane |
Entry condition |
Outcome |
Owner |
| 1a — no-book entry |
no transaction export, no holdings snapshot |
one bounded DecisionFraming: strongest case for and against, the decision's key tension, the user's own exit condition, and a visible statement that actual weight, concentration, cash and rule collisions were not checked |
#597 |
| 1b — book-aware |
a recorded book or supplied snapshot |
TradeEvaluation: exact consequence, rule collisions, two-sided provenance-labelled challenge |
#479 — landed |
1a is an entry to the same conversation, not a lesser product and not a separate phase. It reuses 1b's questions, the bounded market-lookup contract, the limitation vocabulary and every red line; it must not reopen, fork or widen any 1b contract. 1b's landing is unaffected by 1a's absence.
The failure mode 1a is designed against: a book-free answer that reads as a partially-filled TradeEvaluation. It is a separate bounded outcome with a stated limit, and it never emits an empty or zero-valued portfolio_state.
The response in either lane combines:
Engine-owned facts
- exact portfolio basis and freshness;
- post-trade position weight;
- concentration / driver overlap;
- cash consequence;
- collision with currently tracked rules;
- explicit limitations when data is stale or incomplete.
Small decision context
- current reason;
- why now / what changed;
- zero to a few evidence references explicitly supplied by the user or host.
Agent interpretation
- case for and against;
- whether the input contains an evidence delta or only a price delta;
- which claims come from the record, public facts, or agent judgment;
- important items not checked.
Lane 1b's implementation slice is #479 (landed). Lane 1a is #597, and its own decision gate — one ephemeral conversation-only prototype plus an owner verdict — comes before any implementation issue is opened for it.
Phase 1 does not require
- automatic consultation-to-broker-trade matching;
- a new permanent
DecisionEpisode graph;
- cross-period reason similarity search;
- automatic thesis-drift detection;
- a complete research/evidence platform;
- rule backtesting;
- a new mandatory card lifecycle;
- reading from or copying any private repository.
The existing consider record and existing review flow remain the containers. The first step is to add only the missing decision context beside the already-computed consequence.
Scope guard specific to lane 1a
Phase 1 success gate
A context-free consider call remains unchanged, while a context-bearing call can:
- compute the consequence against a stated portfolio basis when a book exists; and when none exists, produce lane 1a's bounded framing that states which portfolio facts were not checked, rather than refusing or improvising them;
- preserve the user's explicitly supplied current reason and what changed;
- produce a two-sided, provenance-labelled answer;
- work from plain conversation or an optional external host;
- avoid importing any news, wiki, KOL, asset-management, or private-repository subsystem;
- invite the next piece of evidence by naming the specific answer it would buy — not by asking for data in the abstract, and never by withholding a useful answer as leverage.
Do not start Phase 2 until this interaction is used enough to show that users actually provide and revisit the context.
Phase 2 — cross-period personal memory
Goal: answer the first five core questions from the user's own fomo-kernel history.
Build on, rather than replace, existing work:
This phase should enable:
- why the user originally bought;
- whether today's add reason differs from the earlier reason;
- what changed between the two statements;
- retrieval of a small number of relevant prior executed analogs;
- what happened after similar reasons were used before.
Scope guard
Do not start by designing a full InstrumentThesisThread, universal evidence graph, or generalized investment ontology. Use the existing trade, thesis, consultation, and append-only state until a concrete reader cannot be built without a new object.
A new domain object must solve a measured failure, not merely make the diagram cleaner.
Phase 2 may read only data the user deliberately supplied to fomo-kernel or that fomo-kernel computed itself. It must not silently pull from a private repository.
Phase 3 — rule learning
Goal: answer, "我訂過的規則，到底有沒有用？"
The likely product shape is Decision Policy Replay, not a generic strategy backtest.
It may report:
- how many real opportunities were eligible for the rule;
- when the rule would have triggered;
- whether the user followed it;
- which actual trades the rule would have blocked or modified;
- what those actual trades subsequently did;
- whether the rule should be kept, revised, promoted, or retired.
It must not claim a fabricated full-portfolio counterfactual such as "this rule would have made $X," because the record does not know where released capital would have gone or which unexecuted trades would have replaced the blocked ones.
No separate implementation issue is opened yet. Phase 3 depends on Phase 2 history, known_at discipline, and an opportunity denominator. Opening it now would create a speculative backlog rather than an executable slice.
Phase 4 — optional adapters, only after validation
Possible thin integrations:
- an explicitly configured external-host context adapter;
- read-only broker sync;
- ETF constituent lookup;
- faster invocation surfaces such as a share sheet, browser extension, or command launcher.
Adapters must be opt-in and contract-based. They may pass only fields deliberately selected for the kernel; they must not crawl, mirror, or bulk-copy a private repository.
These are adapters around the kernel, not reasons to turn the kernel into a resident wealth-management application.
Simplified ownership boundary
FOMO Kernel owns
PortfolioState and deterministic trade consequences.TradePremise for the proposed action.- A small
DecisionContext deliberately supplied by the user or host.
- Append-only memory created inside fomo-kernel for later review and reconciliation.
- Rule adherence and, later, bounded rule efficacy analysis.
The host may own
- ticker wikis and long-form theses;
- morning notes, KOL scans, filings, and research reports;
- watchlists and idea discovery;
- richer owner-specific decision procedures;
- any presentation layer beyond the kernel's stable outputs.
The reusable boundary is:
The host gathers information; the kernel receives only a deliberately selected decision-relevant delta beside the computed consequence.
No implicit repository reading or bulk synchronization is part of this boundary.
Explicitly out of scope for the first product stage
- cloning any private or full research workflow;
- reading, copying, indexing, or summarizing a private repository into fomo-kernel;
- household net worth, retirement, tax, or full asset-allocation management;
- autonomous stock selection or market-wide alpha discovery;
- price targets and market forecasts as engine facts;
- a crawler, filing warehouse, transcript database, or KOL platform;
- a generic evidence knowledge graph;
- automatic tracking of every trade considered but not taken;
- multi-trade swap / pass / defer ontology;
- automatic execution matching;
- redesigning all current rule types at once;
- requiring a card for daily conversational use;
- generic investment advice offered in place of a portfolio fact the product could not compute.
These may be revisited only after a narrower phase demonstrates a concrete missing capability, and never by copying private records into the public repository.
Issue map
| Need |
Existing / new issue |
| Portfolio correctness and common basis |
#467, #456, #478 |
| Free-form answer provenance |
#414 |
| Minimal current reason + evidence delta (lane 1b) |
#479 |
| No-book decision framing (lane 1a) |
#597 |
| Bounded market-context lookup |
#601 |
| Declared principles, their revisions, and declared-vs-observed collisions |
#446 |
| Cross-period self-report reader |
#450 |
| Motive accumulation / reason drift |
#403 |
| Optional bounded profile distillation |
#446, #453 |
| Trigger reliability |
#458 |
| Decision Policy Replay |
not opened until prerequisites exist |
Product positioning draft
FOMO Kernel challenges the next trade against your actual book and preserves the minimum decision context needed to judge it later.
Long-term loop:
Why I acted → what the trade did to my book → what happened → what rule I learned → whether the next decision changed.
Near-term loop:
What I am considering → why now → what it does to my book → which rule or assumption it conflicts with.
Privacy boundary
This is a public roadmap issue. No real trade, holding, amount, date, thesis, evidence item, source, or other content from any private repository may be copied into this issue or into fomo-kernel. Product lessons must be expressed only as generic requirements, public research, or fictional fixtures.
Status
Owner-updated to enforce staged scope and a strict separation between the public kernel and any private investing workflow.
This issue is a staged product roadmap and scope guard, not a request to reproduce a full investment workflow and not an implementation epic.
Phase 1 slices: #479 (book-aware lane, landed as M1) and #597 (no-book entry lane, owner-ruled into this phase 2026-07-30).
Foundation and safety: #467, #456, #478, #414.
Product decision
FOMO Kernel should not become a full investment OS, wealth manager, research terminal, or copy of any private investing system.
Real investing use validates the needs, not the amount of product that must be copied:
The narrower product thesis is:
A host may have rich research, ticker notes, news collection, or a private investment process. FOMO Kernel does not need to own or ingest those systems. It needs a small, explicitly supplied contract for receiving the decision-relevant result.
Core user questions
The long-term product should become unusually good at answering:
These remain the product direction. They do not all need to ship in the first version.
Market conclusion, kept short
Adjacent products already cover AI journals, behavioral analytics, thesis notes, research workflows, broker sync, and portfolio advice. Breadth is therefore not the opportunity.
The differentiating loop is the connection between:
The first release only needs to make the first two arrows useful and preserve enough explicitly supplied context for later reconciliation.
Staged roadmap
Phase 0 — make the existing two capabilities trustworthy
Goal: review and
considermust quote the same honest portfolio footing before more memory is added.Work already has homes:
consider: [bug·data·M0]considermust consume and disclose the canonical PortfolioBasis #478;Phase 0 adds no broad product capability. It prevents the next phases from learning from or advising against the wrong book.
Phase 1 — minimal pre-trade decision loop
Goal: make one pre-trade conversation useful without requiring a full profile, ticker wiki, research database, or review card.
A user should be able to say:
Two entry lanes, one conversation
Owner ruling 2026-07-30: evidence is a gradient, not a 1/0, and refusing to answer is not the mechanism that earns an upload — guidance is. A user with nothing recorded still enters here; they are walked up, and the product's own chain has to earn the trade history rather than demand it as a precondition.
DecisionFraming: strongest case for and against, the decision's key tension, the user's own exit condition, and a visible statement that actual weight, concentration, cash and rule collisions were not checkedTradeEvaluation: exact consequence, rule collisions, two-sided provenance-labelled challenge1a is an entry to the same conversation, not a lesser product and not a separate phase. It reuses 1b's questions, the bounded market-lookup contract, the limitation vocabulary and every red line; it must not reopen, fork or widen any 1b contract. 1b's landing is unaffected by 1a's absence.
The failure mode 1a is designed against: a book-free answer that reads as a partially-filled
TradeEvaluation. It is a separate bounded outcome with a stated limit, and it never emits an empty or zero-valuedportfolio_state.The response in either lane combines:
Engine-owned facts
Small decision context
Agent interpretation
Lane 1b's implementation slice is #479 (landed). Lane 1a is #597, and its own decision gate — one ephemeral conversation-only prototype plus an owner verdict — comes before any implementation issue is opened for it.
Phase 1 does not require
DecisionEpisodegraph;The existing
considerrecord and existing review flow remain the containers. The first step is to add only the missing decision context beside the already-computed consequence.Scope guard specific to lane 1a
Phase 1 success gate
A context-free
considercall remains unchanged, while a context-bearing call can:Do not start Phase 2 until this interaction is used enough to show that users actually provide and revisit the context.
Phase 2 — cross-period personal memory
Goal: answer the first five core questions from the user's own fomo-kernel history.
Build on, rather than replace, existing work:
This phase should enable:
Scope guard
Do not start by designing a full
InstrumentThesisThread, universal evidence graph, or generalized investment ontology. Use the existing trade, thesis, consultation, and append-only state until a concrete reader cannot be built without a new object.A new domain object must solve a measured failure, not merely make the diagram cleaner.
Phase 2 may read only data the user deliberately supplied to fomo-kernel or that fomo-kernel computed itself. It must not silently pull from a private repository.
Phase 3 — rule learning
Goal: answer, "我訂過的規則，到底有沒有用？"
The likely product shape is Decision Policy Replay, not a generic strategy backtest.
It may report:
It must not claim a fabricated full-portfolio counterfactual such as "this rule would have made $X," because the record does not know where released capital would have gone or which unexecuted trades would have replaced the blocked ones.
No separate implementation issue is opened yet. Phase 3 depends on Phase 2 history,
known_atdiscipline, and an opportunity denominator. Opening it now would create a speculative backlog rather than an executable slice.Phase 4 — optional adapters, only after validation
Possible thin integrations:
Adapters must be opt-in and contract-based. They may pass only fields deliberately selected for the kernel; they must not crawl, mirror, or bulk-copy a private repository.
These are adapters around the kernel, not reasons to turn the kernel into a resident wealth-management application.
Simplified ownership boundary
FOMO Kernel owns
PortfolioStateand deterministic trade consequences.TradePremisefor the proposed action.DecisionContextdeliberately supplied by the user or host.The host may own
The reusable boundary is:
No implicit repository reading or bulk synchronization is part of this boundary.
Explicitly out of scope for the first product stage
These may be revisited only after a narrower phase demonstrates a concrete missing capability, and never by copying private records into the public repository.
Issue map
Product positioning draft
Long-term loop:
Near-term loop: