feat(guidelines): import shared primitives from a neutral home

.clinerules/karpathy-skills.md

@@ -122,6 +122,7 @@ Your priors are a starting hypothesis, not the answer. The most expensive mistak
   - For **design and infra decisions** — an architecture, a tradeoff, how to build something — study prior art: how established services and competitors solved the same problem is real signal. Here engineering blogs, postmortems, conference talks, and case studies are legitimate and valuable. Weigh how others did it in the wild, then decide for *this* system.
 - **Read this codebase, don't infer it.** Before editing, read the actual code, types, and tests the change touches, and trace the real flow end to end. How it works *here* beats how it works *in general*.
 - **Reuse before you build — look down the stack, not just sideways.** Before adding any new state — config keys, DB columns, env vars, endpoints, files, abstractions — search the framework / platform / library you build on, *and* the rest of this repo, for a primitive that already models the concern. "The code this touches" is too narrow: the answer often lives one layer down, adjacent to the change, not in it. Reinventing what the host already exposes is the single most common efficiency miss. Verify the primitive against the dependency's actual source, not its docs alone.
+- **Import from a neutral home — don't reach into another feature.** Finding the primitive isn't enough; *where you import it from* is part of the decision. If it lives inside another feature's private space — its route folder, its module, a `Feature*` name on generic code — importing it there couples the two: that feature's next refactor breaks yours, and the name now lies about what the code does. Hoist the generic part to a domain-neutral shared module, name it for what it does rather than where it was born, and have both features import that. A second caller is exactly what earns the extraction, so this is not the speculative abstraction §2 warns about — but keep it an extraction: move the code, don't redesign it on the way out.
 - **Verify the invocation contract, not just the behavior.** When your change emits something a machine will run — a command line, an API call, a query, a config — confirming *what it does* is not confirming *how it's called*. Check the exact signature (flag names, params, arg order, whether auth is a `--flag` or an env var) against the **primary source**: the command's own option definition, the API's schema, the function's real signature — not prose docs, and not a nearby example. Reference docs group by topic and quietly invite you to cross-apply a sibling command's flags onto yours; the sample that "looks right" is how a wrong flag ships. That mundane call detail is the part most likely wrong *and* least likely checked — precisely because it feels beneath verifying — and it is often what decides whether the thing runs at all.
 - **Map before you move.** For non-trivial work, get the overview first: where this lives, what calls it and what it calls, the data and infrastructure boundaries it crosses. A change that's locally correct but wrong about the architecture is a new bug.
 - **When you can't verify, say so.** Flag it as an assumption and state how you'd confirm — never launder a guess into a claim.

.cursor/rules/karpathy-skills.mdc

@@ -128,6 +128,7 @@ Your priors are a starting hypothesis, not the answer. The most expensive mistak
   - For **design and infra decisions** — an architecture, a tradeoff, how to build something — study prior art: how established services and competitors solved the same problem is real signal. Here engineering blogs, postmortems, conference talks, and case studies are legitimate and valuable. Weigh how others did it in the wild, then decide for *this* system.
 - **Read this codebase, don't infer it.** Before editing, read the actual code, types, and tests the change touches, and trace the real flow end to end. How it works *here* beats how it works *in general*.
 - **Reuse before you build — look down the stack, not just sideways.** Before adding any new state — config keys, DB columns, env vars, endpoints, files, abstractions — search the framework / platform / library you build on, *and* the rest of this repo, for a primitive that already models the concern. "The code this touches" is too narrow: the answer often lives one layer down, adjacent to the change, not in it. Reinventing what the host already exposes is the single most common efficiency miss. Verify the primitive against the dependency's actual source, not its docs alone.
+- **Import from a neutral home — don't reach into another feature.** Finding the primitive isn't enough; *where you import it from* is part of the decision. If it lives inside another feature's private space — its route folder, its module, a `Feature*` name on generic code — importing it there couples the two: that feature's next refactor breaks yours, and the name now lies about what the code does. Hoist the generic part to a domain-neutral shared module, name it for what it does rather than where it was born, and have both features import that. A second caller is exactly what earns the extraction, so this is not the speculative abstraction §2 warns about — but keep it an extraction: move the code, don't redesign it on the way out.
 - **Verify the invocation contract, not just the behavior.** When your change emits something a machine will run — a command line, an API call, a query, a config — confirming *what it does* is not confirming *how it's called*. Check the exact signature (flag names, params, arg order, whether auth is a `--flag` or an env var) against the **primary source**: the command's own option definition, the API's schema, the function's real signature — not prose docs, and not a nearby example. Reference docs group by topic and quietly invite you to cross-apply a sibling command's flags onto yours; the sample that "looks right" is how a wrong flag ships. That mundane call detail is the part most likely wrong *and* least likely checked — precisely because it feels beneath verifying — and it is often what decides whether the thing runs at all.
 - **Map before you move.** For non-trivial work, get the overview first: where this lives, what calls it and what it calls, the data and infrastructure boundaries it crosses. A change that's locally correct but wrong about the architecture is a new bug.
 - **When you can't verify, say so.** Flag it as an assumption and state how you'd confirm — never launder a guess into a claim.

.github/copilot-instructions.md

@@ -122,6 +122,7 @@ Your priors are a starting hypothesis, not the answer. The most expensive mistak
   - For **design and infra decisions** — an architecture, a tradeoff, how to build something — study prior art: how established services and competitors solved the same problem is real signal. Here engineering blogs, postmortems, conference talks, and case studies are legitimate and valuable. Weigh how others did it in the wild, then decide for *this* system.
 - **Read this codebase, don't infer it.** Before editing, read the actual code, types, and tests the change touches, and trace the real flow end to end. How it works *here* beats how it works *in general*.
 - **Reuse before you build — look down the stack, not just sideways.** Before adding any new state — config keys, DB columns, env vars, endpoints, files, abstractions — search the framework / platform / library you build on, *and* the rest of this repo, for a primitive that already models the concern. "The code this touches" is too narrow: the answer often lives one layer down, adjacent to the change, not in it. Reinventing what the host already exposes is the single most common efficiency miss. Verify the primitive against the dependency's actual source, not its docs alone.
+- **Import from a neutral home — don't reach into another feature.** Finding the primitive isn't enough; *where you import it from* is part of the decision. If it lives inside another feature's private space — its route folder, its module, a `Feature*` name on generic code — importing it there couples the two: that feature's next refactor breaks yours, and the name now lies about what the code does. Hoist the generic part to a domain-neutral shared module, name it for what it does rather than where it was born, and have both features import that. A second caller is exactly what earns the extraction, so this is not the speculative abstraction §2 warns about — but keep it an extraction: move the code, don't redesign it on the way out.
 - **Verify the invocation contract, not just the behavior.** When your change emits something a machine will run — a command line, an API call, a query, a config — confirming *what it does* is not confirming *how it's called*. Check the exact signature (flag names, params, arg order, whether auth is a `--flag` or an env var) against the **primary source**: the command's own option definition, the API's schema, the function's real signature — not prose docs, and not a nearby example. Reference docs group by topic and quietly invite you to cross-apply a sibling command's flags onto yours; the sample that "looks right" is how a wrong flag ships. That mundane call detail is the part most likely wrong *and* least likely checked — precisely because it feels beneath verifying — and it is often what decides whether the thing runs at all.
 - **Map before you move.** For non-trivial work, get the overview first: where this lives, what calls it and what it calls, the data and infrastructure boundaries it crosses. A change that's locally correct but wrong about the architecture is a new bug.
 - **When you can't verify, say so.** Flag it as an assumption and state how you'd confirm — never launder a guess into a claim.

.windsurf/rules/karpathy-skills.md

@@ -122,6 +122,7 @@ Your priors are a starting hypothesis, not the answer. The most expensive mistak
   - For **design and infra decisions** — an architecture, a tradeoff, how to build something — study prior art: how established services and competitors solved the same problem is real signal. Here engineering blogs, postmortems, conference talks, and case studies are legitimate and valuable. Weigh how others did it in the wild, then decide for *this* system.
 - **Read this codebase, don't infer it.** Before editing, read the actual code, types, and tests the change touches, and trace the real flow end to end. How it works *here* beats how it works *in general*.
 - **Reuse before you build — look down the stack, not just sideways.** Before adding any new state — config keys, DB columns, env vars, endpoints, files, abstractions — search the framework / platform / library you build on, *and* the rest of this repo, for a primitive that already models the concern. "The code this touches" is too narrow: the answer often lives one layer down, adjacent to the change, not in it. Reinventing what the host already exposes is the single most common efficiency miss. Verify the primitive against the dependency's actual source, not its docs alone.
+- **Import from a neutral home — don't reach into another feature.** Finding the primitive isn't enough; *where you import it from* is part of the decision. If it lives inside another feature's private space — its route folder, its module, a `Feature*` name on generic code — importing it there couples the two: that feature's next refactor breaks yours, and the name now lies about what the code does. Hoist the generic part to a domain-neutral shared module, name it for what it does rather than where it was born, and have both features import that. A second caller is exactly what earns the extraction, so this is not the speculative abstraction §2 warns about — but keep it an extraction: move the code, don't redesign it on the way out.
 - **Verify the invocation contract, not just the behavior.** When your change emits something a machine will run — a command line, an API call, a query, a config — confirming *what it does* is not confirming *how it's called*. Check the exact signature (flag names, params, arg order, whether auth is a `--flag` or an env var) against the **primary source**: the command's own option definition, the API's schema, the function's real signature — not prose docs, and not a nearby example. Reference docs group by topic and quietly invite you to cross-apply a sibling command's flags onto yours; the sample that "looks right" is how a wrong flag ships. That mundane call detail is the part most likely wrong *and* least likely checked — precisely because it feels beneath verifying — and it is often what decides whether the thing runs at all.
 - **Map before you move.** For non-trivial work, get the overview first: where this lives, what calls it and what it calls, the data and infrastructure boundaries it crosses. A change that's locally correct but wrong about the architecture is a new bug.
 - **When you can't verify, say so.** Flag it as an assumption and state how you'd confirm — never launder a guess into a claim.

AGENTS.md

@@ -122,6 +122,7 @@ Your priors are a starting hypothesis, not the answer. The most expensive mistak
   - For **design and infra decisions** — an architecture, a tradeoff, how to build something — study prior art: how established services and competitors solved the same problem is real signal. Here engineering blogs, postmortems, conference talks, and case studies are legitimate and valuable. Weigh how others did it in the wild, then decide for *this* system.
 - **Read this codebase, don't infer it.** Before editing, read the actual code, types, and tests the change touches, and trace the real flow end to end. How it works *here* beats how it works *in general*.
 - **Reuse before you build — look down the stack, not just sideways.** Before adding any new state — config keys, DB columns, env vars, endpoints, files, abstractions — search the framework / platform / library you build on, *and* the rest of this repo, for a primitive that already models the concern. "The code this touches" is too narrow: the answer often lives one layer down, adjacent to the change, not in it. Reinventing what the host already exposes is the single most common efficiency miss. Verify the primitive against the dependency's actual source, not its docs alone.
+- **Import from a neutral home — don't reach into another feature.** Finding the primitive isn't enough; *where you import it from* is part of the decision. If it lives inside another feature's private space — its route folder, its module, a `Feature*` name on generic code — importing it there couples the two: that feature's next refactor breaks yours, and the name now lies about what the code does. Hoist the generic part to a domain-neutral shared module, name it for what it does rather than where it was born, and have both features import that. A second caller is exactly what earns the extraction, so this is not the speculative abstraction §2 warns about — but keep it an extraction: move the code, don't redesign it on the way out.
 - **Verify the invocation contract, not just the behavior.** When your change emits something a machine will run — a command line, an API call, a query, a config — confirming *what it does* is not confirming *how it's called*. Check the exact signature (flag names, params, arg order, whether auth is a `--flag` or an env var) against the **primary source**: the command's own option definition, the API's schema, the function's real signature — not prose docs, and not a nearby example. Reference docs group by topic and quietly invite you to cross-apply a sibling command's flags onto yours; the sample that "looks right" is how a wrong flag ships. That mundane call detail is the part most likely wrong *and* least likely checked — precisely because it feels beneath verifying — and it is often what decides whether the thing runs at all.
 - **Map before you move.** For non-trivial work, get the overview first: where this lives, what calls it and what it calls, the data and infrastructure boundaries it crosses. A change that's locally correct but wrong about the architecture is a new bug.
 - **When you can't verify, say so.** Flag it as an assumption and state how you'd confirm — never launder a guess into a claim.

CLAUDE.md

@@ -120,6 +120,7 @@ Your priors are a starting hypothesis, not the answer. The most expensive mistak
   - For **design and infra decisions** — an architecture, a tradeoff, how to build something — study prior art: how established services and competitors solved the same problem is real signal. Here engineering blogs, postmortems, conference talks, and case studies are legitimate and valuable. Weigh how others did it in the wild, then decide for *this* system.
 - **Read this codebase, don't infer it.** Before editing, read the actual code, types, and tests the change touches, and trace the real flow end to end. How it works *here* beats how it works *in general*.
 - **Reuse before you build — look down the stack, not just sideways.** Before adding any new state — config keys, DB columns, env vars, endpoints, files, abstractions — search the framework / platform / library you build on, *and* the rest of this repo, for a primitive that already models the concern. "The code this touches" is too narrow: the answer often lives one layer down, adjacent to the change, not in it. Reinventing what the host already exposes is the single most common efficiency miss. Verify the primitive against the dependency's actual source, not its docs alone.
+- **Import from a neutral home — don't reach into another feature.** Finding the primitive isn't enough; *where you import it from* is part of the decision. If it lives inside another feature's private space — its route folder, its module, a `Feature*` name on generic code — importing it there couples the two: that feature's next refactor breaks yours, and the name now lies about what the code does. Hoist the generic part to a domain-neutral shared module, name it for what it does rather than where it was born, and have both features import that. A second caller is exactly what earns the extraction, so this is not the speculative abstraction §2 warns about — but keep it an extraction: move the code, don't redesign it on the way out.
 - **Verify the invocation contract, not just the behavior.** When your change emits something a machine will run — a command line, an API call, a query, a config — confirming *what it does* is not confirming *how it's called*. Check the exact signature (flag names, params, arg order, whether auth is a `--flag` or an env var) against the **primary source**: the command's own option definition, the API's schema, the function's real signature — not prose docs, and not a nearby example. Reference docs group by topic and quietly invite you to cross-apply a sibling command's flags onto yours; the sample that "looks right" is how a wrong flag ships. That mundane call detail is the part most likely wrong *and* least likely checked — precisely because it feels beneath verifying — and it is often what decides whether the thing runs at all.
 - **Map before you move.** For non-trivial work, get the overview first: where this lives, what calls it and what it calls, the data and infrastructure boundaries it crosses. A change that's locally correct but wrong about the architecture is a new bug.
 - **When you can't verify, say so.** Flag it as an assumption and state how you'd confirm — never launder a guess into a claim.