TT Claude Memory

feedback_no_current_stack_bias_for_inherit_v2

Properties1
descriptionSaturday 18 April 2026 — Rich flagged that Eric's v0.5 book letter rejected Fregly's *Generative AI on AWS* with reason "deeply AWS-specific and superseded for INHERIT's stack (Vercel + Supabase + bespoke inference)". Rich's direction is explicit: there is NO requirement for INHERIT v2 to be built on Vercel/Supabase or any other current TT stack element. Future architecture proposals must evaluate technology on merit, not on fit with the current deployment environment.

2 min read

The rule. When evaluating architecture options or recommending books/resources for INHERIT v2, do not treat TT’s current deployment stack (Vercel, Supabase, Node/TS, Python, current LegacyLists infrastructure) as a constraint. INHERIT v2 is a rebuild; the stack is open.

Why: Rich’s verbatim statement 18 April 2026: “there is absolutely no requirement for us to build our next solution with vercel and supabase: do not assume that vercel and supabase need to be used for Inherit v2.” The rebuild is specifically the moment where stack decisions reopen.

How to apply:

  1. When scoring architecture options, do NOT weight current-stack-compatibility as a criterion unless explicitly asked. INHERIT v2 is green-field on the infrastructure layer; Josh’s LegacyLists on v6.6 continues on its current stack separately and in parallel.
  2. When rejecting books or resources, never cite “wrong fit for current stack” as the reason. If a book is AWS-centric and INHERIT v2 might be AWS-deployed, that is a valid vote for the book, not against it. If INHERIT v2 might be Rust-on-bare-metal or Kubernetes-self-hosted or edge-function-deployed, stay open.
  3. Option D currently references Vercel+Supabase nowhere explicitly, but assumptions can leak in through book recommendations, subagent briefs, or LOC estimates that assume TypeScript-Python stacks. Watch for that leak.
  4. Option F was proposed 18 April 2026 specifically to remove stack bias — “absolutely whatever technology you think is best, with no bias towards software we are currently using.” Treat Option F as the explicit stake-in-the-ground that the other options have un-stated stack assumptions which F removes.
  5. When a fresh Claude session is briefed on INHERIT v2, include this explicit “no current-stack assumption” note in the context so stack priors don’t creep in through defaulting.

Related memories:

  • project_options_d_and_e_synthesis.md — D uses Neo4j/Pydantic/Mistral Nemo which are tech choices, not stack-compatibility constraints. F reopens these.
  • feedback_scope_vs_commercial_reality.md — solo-bootstrap capacity is still load-bearing; F must still respect that, but ops-complexity should be weighed on its own terms (managed services vs self-hosted) independent of current TT choices.

Graph View

Backlinks