[ ROADMAP ]

Where the ship has been, and where it is going

Six phases are behind us, one of which we built and then deliberately switched off. What follows is grouped by horizon rather than by date, because unshipped work with a date on it is a guess wearing a uniform.

Shipped

In the order it happened. The product went from a well-built demo with no runtime to a live system in a single stretch of work — and the most consequential decision in it was the one to remove a feature.

  1. 01

    Persistence

    SHIPPEDAug 2026

    The deck stopped being a demo. Watches, proposals, and ledger events became real rows scoped to the operator who made them.

    • Cloudflare D1 database with migrations for watches, proposals, and ledger events.
    • Every row scoped to a session address, so wallet and demo sessions never mix.
    • First-visit seeding, so a fresh deck opens with something to steer rather than three empty tables.
  2. 02

    Real prices

    SHIPPEDAug 2026

    Fictional prices became real quotes on the underlying equities — and the deck learned to say which it was showing.

    • Market-data provider behind a cache-first quote service.
    • Shared quote cache in D1: one price for a symbol serves every deck, which is what keeps the system inside an upstream rate limit.
    • Provenance on every response — source, live, stale, and a detail line naming the cause when prices are not live.
  3. 03

    The agent loop

    SHIPPEDAug 2026

    The fleet started doing something while nobody was watching: a scheduled sweep that turns tripped watches into drafted proposals.

    • Cron Trigger every 15 minutes, re-entering the Worker through a self-reference binding.
    • Structured model call per tripped watch, schema-validated on return; invalid drafts are discarded, never repaired.
    • All allocation arithmetic computed in code — the model writes prose and argues, it does not calculate.
    • 30-minute per-watch cooldown, stamped even on failure, so an outage cannot become a spend loop.
  4. 04

    Execution rail

    DROPPED ON PURPOSEAug 2026

    Built, tested, and then deliberately switched off. The decision that followed became the product's architecture.

    • The connection layer is complete: OAuth with PKCE, RFC 7591 dynamic client registration, refresh tokens encrypted under a key held outside the database.
    • Order placement was never built, and now will not be.
    • Reasoning: Oddysey never executes, so holding a credential that could place real orders would buy the highest-value secret in the architecture in exchange for no capability at all.
    • The code remains unmounted, for a future where the deck needs to read real balances. Reading is not trading.
  5. 05

    Distribution over MCP

    SHIPPEDAug 2026

    Operators' own agents got a way in: a remote MCP server exposing nine tools, and pointedly not a tenth.

    • Streamable HTTP at /api/mcp, protocol 2025-06-18.
    • Revocable deck tokens, stored only as SHA-256 digests and shown in plaintext exactly once.
    • No approve or reject tool, at any permission level — an agent that could sign off on its own drafts would defeat the product.
    • Live in production on Cloudflare Workers with the cron sweep registered.
  6. 06

    Documentation, whitepaper, roadmap

    SHIPPEDAug 2026

    The reasoning behind the design became readable by someone who did not build it.

    • Full documentation: concepts, tutorials, REST and MCP reference, self-hosting, and the security model.
    • A whitepaper arguing the design, including the limitations it does not solve.
    • This page.

Planned

Each item says why it is wanted and, where one exists, the unresolved question standing in front of it. Items move between horizons as those questions get answered — or as they turn out to be harder than they looked.

Now

Being worked on, or next off the shelf.

  • An automated test suite

    The evaluation loop and the allocation arithmetic are exactly the code that most warrants tests, and they have none. Everything has been exercised by hand and in production, which is not the same thing.

    OPEN: Nothing conceptual — this is unglamorous work that has simply not been done.

  • Resolve market hours versus continuous watching

    The trigger reads change since previous close, so when the exchange is shut the number stops moving and the sweep goes quiet. That is correct for the price source and in tension with the promise of round-the-clock watching.

    OPEN: Either the sweep becomes market-hours-aware and stops claiming continuous coverage, or the underlying-equity quote stops being an adequate proxy and the price source changes. The second is a bigger change than it sounds.

  • A published MCP package

    Connecting a stdio-only client currently means bridging to the remote server by hand. A published package would make it one line.

Next

Decided in principle, not yet started.

  • Notifications that actually fire

    A drafted proposal is time-sensitive and currently waits until someone opens the deck. Email and webhook delivery on draft would close that gap.

  • Execution reconciliation

    Reported fills are claims, not observations. Checking them against a venue's own record would make the last line of the audit trail as trustworthy as the rest of it.

    OPEN: Verification needs read access to the venue, which reopens the credential-custody question that dropping the execution rail closed.

  • Portfolio-level watches

    Watches are per-symbol. Real concerns are often portfolio-level — total drawdown, concentration drift, a sector moving together.

  • Scoped deck tokens

    A token today grants all nine tools. A read-only token for a monitoring agent is an obvious and easy narrowing.

Later

Wanted, unscheduled, and honestly still uncertain.

  • Team decks with separated roles

    There is no notion of a team, a reviewer distinct from an approver, or a four-eyes requirement. For a desk, that is the first structural thing missing.

  • Read-only balance connection

    Holdings are fixtures because the system connects to no account. Reading real balances would make every allocation figure real, and reading is not trading.

    OPEN: It reintroduces credential custody for a read-only benefit. Not obviously worth it, and it will not be done quietly if it happens.

  • Proposal outcome tracking

    Nothing currently records whether approving a proposal turned out well. Without that, neither the operator nor the drafting prompt has a feedback signal.

Never

Not “not yet”. These are the commitments the product is built on, and shipping any of them would make Oddysey a different product with the same name.

An execution endpoint

The absence of an order path is the security argument. Adding one would not extend the product — it would replace it with a different, more ordinary one.

An approve or reject tool for agents

An agent that can sign off on its own drafts is an autonomous trader with extra steps. The capability is absent rather than gated, so no misconfiguration or compromised token can produce it.

Custody of brokerage credentials for trading

A refresh token that can place real orders is the highest-value secret such a system could hold. Since Oddysey does not execute, holding one would be pure risk.

An autonomous mode

Not as a setting, not for advanced users, not behind a warning. A supervision layer with an off switch for the supervision is a marketing claim, not a design.

Known gaps, stated plainly

There is no automated test suite. Holdings are fixtures rather than real balances. Reported fills are claims that nothing verifies. The sweep goes quiet when the exchange is shut, which sits awkwardly beside a promise of round-the-clock watching. None of these are hidden in a changelog — they are in the whitepaper’s limitations section and in the documentation too.