Skip to content

Daily Log: 2026-07-12 ​

A substantial day of architecture and prior-art research in fractal. Significant design exploration around routing/dispatch composition models and evaluation of external frameworks (tRPC, Effect-TS, Hono, Elysia) to inform fractal's own direction.

Sessions and Activity ​

fractal ​

Continued from previous day's design work. A long, focused session beginning at 03:14:30 with an important evaluation result: fractal's read confirmed it is surface-only (HTTP/CLI/MCP routing) with no internal-dispatch coverage or caller-context support. This distinction between surface projection and cross-cutting concerns clarified the architectural landscape and informed subsequent research.

Key activities:

  1. Fractal evaluation readout (03:14:30) — Documented findings from spike/fractal-eval branch that fractal is orthogonal to (not subsuming) the internal annotation/caller-context layer. This is a positive clarification rather than a limitation.

  2. Prior-art research agents (09:30–09:40, multiple agents in parallel):

    • Effect-TS: Layer/service DI composition, context threading, middleware as service-shaped values
    • tRPC: Procedure definition, middleware context accumulation, transport-agnostic procedures, inspectability
    • Hono: Koa-style onion composition, context generics, multi-runtime core + adapters, decoupled OpenAPI
    • Elysia: Schema-first type system, four-context accumulation layers (decorate/state/derive/resolve), AOT compilation with dead-code elimination, Eden Treaty Proxy client generation

All research findings written to docs/design/prior-art/ with detailed architectural notes for later synthesis.

  1. Discernment and restraint (09:39–10:25) — Several points where the user pushed back on suggestions ("can you please stop suggesting things especially without thinking them through first", "why do you keep trying to force progress"), redirecting to deeper thinking and research rather than proposing solutions. This shaped later focus toward understanding the problem space fully before committing to design.

Token Usage ​

ProjectSessionsOutput TokensCache ReadInput Tokens
fractal1~15,400~287,500+~38,000+

(Note: Session spanned July 10–12; token counts reflect primary activity on 2026-07-12. Research agent runs contributed significantly to token usage via parallel background execution.)

Observations ​

  1. Clarifying discovery: The fractal evaluation separated surface projection (what fractal covers) from cross-cutting concerns (what it doesn't), resolving ambiguity about its applicability. This is a valuable design clarification rather than a negative finding.

  2. Systematic prior-art mining: Instead of ad-hoc suggestions, the session ran parallel research agents to document Effect, tRPC, Hono, and Elysia as canonical references. This positions later synthesis on a shared evidence base.

  3. Pushing back on premature solving: User redirected the session away from proposing solutions ("why do you keep trying to force progress") toward deeper understanding. This suggests a deliberate design methodology — understand the problem fully and enumerate actual constraints before picking a direction.

  4. Scale-to-zero learning curve: A key question surfaced late in the session ("what if we want scale-to-zero learning curve") that may be a core design constraint worth elevating.

Projects Touched ​

  • fractal — Architecture evaluation, prior-art research, clarification on composition models for routing/dispatch, design doc updates.

Next Steps (inferred) ​

  1. Synthesize prior-art findings into fractal's design docs — the research is written but not yet integrated into conclusions.
  2. Revisit the "scale-to-zero learning curve" constraint in light of the research — does one of the frameworks (tRPC's simplicity, Elysia's type-level inference?) align with this goal?
  3. Determine whether to build a custom routing/dispatch or adopt/adapt an existing framework — the evaluation suggests fractal + a custom caller-context/annotation layer as the path, but this should be written down as a settled design decision.
  4. Continue the coordination refactor in parallel if needed (prior-art research didn't block ongoing implementation work).