Skip to content

README.md

Latest commit

 

History

History
74 lines (57 loc) · 6.84 KB

README.md

File metadata and controls

74 lines (57 loc) · 6.84 KB
Raw
title Implementation Roadmap
description Review-ordered index of implementation plans and decision logs for every proposed feature
audience
developer
architect
status awaiting-decisions

Wiki Home › Future Features

Implementation Roadmap

Every proposal now has two companion documents: an implementation plan (user stories, architecture grounded in the current code, build phases, verification) and a decision log (the choices only the maintainer can make, each with options and a recommendation). This page is the review dashboard — work through it one feature at a time, in any order, across separate sessions.

How to review a feature

  1. Skim the proposal (you've seen these) for the framing.
  2. Read the implementation plan — it says how it would actually be built and in what phases.
  3. Answer the decision log: each decision has a **Decision:** _Pending_ line. Edit the file, or just state your answers in a session ("For HTTP Inspector: D1 = A, D2 = yes, D3 = A") and have the doc updated. Accepting all recommendations is a valid one-line answer.
  4. When a log has no pending decisions, flip its row below to ✅ ready to build.

Statuses: 🟡 awaiting decisions · ✅ ready to build · 🔨 in progress · 🚢 shipped (page moves out of future-features) · ❌ rejected (rationale recorded in Decisions).

The features

Ordered by the suggested build sequence; dependencies noted. "Key decision" is the one to think hardest about.

# Feature Plan Decisions Pending Key decision Status
1 HTTP Inspector plan log 0 Panel layout (tabs vs. interleaved) 🔨
2 Multi-Language Snippets plan log 3 Language set (permanent maintenance) 🟡
3 Shareable Playground Links — — — — ❌
4 Response Shape Viewer plan log 0 Sample size (also governs #5) 🔨
5 Query Builder plan log 0 Operator scope (what the UI teaches) 🔨
6 TypeScript Playground plan log 2 Transpiler + injection visual cue 🟡
7 Error Practice Routes plan log 4 Namespace (permanent URL contract) 🟡
8 Guided Challenges plan log 0 Check expressiveness (shapes contributions) 🔨
9 Auth Training Wheels plan log 5 D0 go/no-go + promise guardrails 🟡
10 Scratch Endpoints plan log 5 D0 build/defer/reject 🟡

Dependencies and shared machinery

flowchart TD
    HI[1. HTTP Inspector<br/>fetch wrapper + __net events] --> GC[8. Guided Challenges<br/>request-level checks]
    EP[7. Error Practice Routes] -.enables tracks.-> GC
    RS[4. Response Shape Viewer] <-->|shared deriveShape\(\) + sample fetch| QB[5. Query Builder]
    RS --> TS[6. TypeScript Playground<br/>injected types + IndexedDB]
    QB -->|Send to Playground| TS
    HI -.CORS exposedHeaders.-> QB
    ML[2. Multi-Language Snippets]
    GC --> TS
    GC -.demand signal.-> SC[10. Scratch Endpoints<br/>gated on D0]
    AU[9. Auth Training Wheels<br/>gated on D0]
Loading

Hard rules that fall out of the plans:

  • #1 before #7 — challenges assert on the fetch wrapper's events; build the wrapper once, in the inspector.
  • #4 and #5 share deriveShape() and one sample fetch; whichever builds first creates the utility (and the tab shell, per Shape Viewer D3).
  • #6 depends on #4 (or at least deriveShape() + toTypeScript()) for injected endpoint types; Query Builder's Send bridge (#5) should land before or with #6.
  • The CORS exposedHeaders change (one line, in the inspector plan) unblocks header reading for #1, #5, and #9 — worth doing with whichever lands first.
  • #9 and #10 are decision-gated: their D0s (go/no-go; build/defer/reject) are maintainer calls that precede any code.
  • #3 (Shareable Links) is rejected — not on the roadmap.
  • #2 is fully independent — good candidate whenever a small win is wanted.

Cross-cutting note: client unit testing

The client has no test runner today (lint + tsc only). Three roadmap pieces are pure functions that genuinely deserve unit tests: deriveShape()/toTypeScript() (#4/#5), buildQueryString() (#5), and the challenge check evaluator (#7). The first of those to be built should bring vitest with it (it fits the existing Vite setup); the plans each note this rather than deciding it — treat "add vitest" as accepted the first time one of those features is greenlit.

Related

  • Future Features — the proposals these plans elaborate
  • Decisions — where accepted/rejected outcomes get recorded permanently
  • Glossary — shared vocabulary used throughout these plans