@mnemonica/tactica 0.3.10 → 0.3.11

package/README.md

@@ -805,7 +805,7 @@ When enabled, tactica detects execution-flow patterns alongside type definitions
 - `scopeId` — the scopeId of the scope holding the wrap call site (fallback join).
 - `wrapsTypePath` — the mnemonica fullPath of the instance argument, resolved through the scope-variable chain (innermost binding wins; an untyped local shadows a typed outer one rather than being guessed).
 - `via` — the location of the enclosing wrap site when the call is nested inside another wrapped body (or returns a function): the wrappers-graph generation chain is built from it.
-- `scope` — the enclosing mnemonica type path. Lexical scoping (the owning `define()`/`lazy()` handler or `@decorate()`-ed class) wins; a wrap site outside any handler — the fire-and-forget-wrapper shape — is attributed through its instance/context argument (a tracked assignment like `const holder = new Holder(…)`, the enclosing function's parameter annotation resolved through the graph law, or a `let`/`var`/`const` declaration with an EXPLICIT type annotation like `let updateCommitted: LedgerUpdate;` — declaration-site typing only, no flow analysis), and nested sites (function-valued returns, lexically nested wraps) inherit the causing wrap site's scope down the `via` chain. An UNANNOTATED `let`/`var` still buckets under `unknown` (the analyzer does not track assignments flow-sensitively) — a `const` with an analyzable initializer stays the recommended discipline. Sites attributable to nothing stay under the `unknown` key with `scope` absent.
+- `scope` — the enclosing mnemonica type path. Lexical scoping (the owning `define()`/`lazy()` handler or `@decorate()`-ed class) wins; a wrap site outside any handler — the fire-and-forget-wrapper shape — is attributed through its instance/context argument (a tracked assignment like `const holder = new Holder(…)`, the enclosing function's parameter annotation resolved through the graph law, or a `let`/`var`/`const` declaration with an EXPLICIT type annotation like `let updateCommitted: LedgerUpdate;` — declaration-site typing only, no flow analysis; the annotation may be the type name or the generated nested-type alias (`UpdatePay_SomeTerminal`, mapped by the underscore→dotted naming law)); the wrap CALLEE identifier also follows a `let`/`var` binding to its first statically-visible in-scope assignment — the catch-guard pattern (`let fn; try { fn = new T(…) } catch { return } wrap(fn, …)`) attributes as `T`, while closure-only assignments and never-assigned bindings stay `unknown` (function/class boundaries are not crossed). One discipline covers both wrap arguments: assignment evidence beats an explicit annotation claim (`let fn: T`, or a wrapper arriving as an annotated parameter) beats `unknown` — the annotation pins the type only when the assignment is not resolvable (a userland call return, say). Nested sites (function-valued returns, lexically nested wraps) inherit the causing wrap site's scope down the `via` chain. An UNANNOTATED `let`/`var` still buckets under `unknown` (the analyzer does not track assignments flow-sensitively) — a `const` with an analyzable initializer stays the recommended discipline. Sites attributable to nothing stay under the `unknown` key with `scope` absent.
 
 ## Instrumentation Points
 

package/docs/lookup-pattern.md

@@ -0,0 +1,109 @@
+# Consuming tactica Output: The lookup Pattern
+
+> **For application developers using tactica-generated types.**
+> If you generated `.tactica/types.ts` and `.tactica/registry.ts` but still write `as unknown as` casts, read this.
+
+---
+
+## The Mistake Everyone Makes
+
+You run tactica. It generates the files. You import the types. You still cast.
+
+```typescript
+// ❌ WRONG — you generated the types but didn't use them properly
+import { RequestData } from './collections/requestTypes.js';
+import type { RequestData as RequestDataT } from '../../.tactica/types.js';
+
+const requestData = new RequestData({ ... }) as unknown as RequestDataT;
+```
+
+This is the most common failure mode. The types exist. The registry exists. But you're bridging them with a cast instead of using `lookup`.
+
+---
+
+## The Correct Way
+
+```typescript
+// ✅ CORRECT — lookup uses the TypeRegistry augmentation
+import { lookup } from 'mnemonica';
+
+const RequestData = lookup('RequestData');
+const requestData = new RequestData({ ... });
+const routeData = new requestData.RouteData({ ... });
+```
+
+`lookup('RequestData')` returns the constructor **typed through the registry**. TypeScript knows:
+- The constructor signature
+- The instance properties
+- That the instance has `.RouteData`, `.PageData`, etc.
+
+No cast needed. The registry does the work.
+
+---
+
+## Why Importing the Type Is Not Enough
+
+`tactica` generates two files:
+
+1. `.tactica/types.ts` — exports like `export type RequestData = {...}`
+2. `.tactica/registry.ts` — augments `mnemonica.TypeRegistry`
+
+Importing from `types.ts` gives you the **instance shape**. It does NOT give you the **constructor type** with sub-constructors.
+
+The registry augmentation is what teaches TypeScript that `lookup('RequestData')` returns a constructor whose instances have `.RouteData`. Without `lookup`, you're just importing shapes and casting between them.
+
+---
+
+## Module-Level Usage
+
+`lookup` is a runtime lookup, but it's safe to call at module level:
+
+```typescript
+// ✅ Safe and correct
+const RequestData = lookup('RequestData');
+const EngineRequest = lookup('EngineRequest');
+
+app.get('/', async () => {
+	const requestData = new RequestData({ ... });
+});
+```
+
+The returned constructor is the same object every time. There is no per-request overhead.
+
+---
+
+## For Decoration (Fastify, Express, etc.)
+
+Use the same `lookup` result for decoration:
+
+```typescript
+const RequestData = lookup('RequestData');
+
+app.decorate('RequestData', RequestData);
+
+// Later in a route handler:
+const requestData = new RequestData({ ... });
+```
+
+No need to import the raw constructor separately. `lookup` gives you the runtime object AND the type.
+
+---
+
+## Checklist
+
+After running `tactica`:
+
+- [ ] `.tactica/` directory exists with `types.ts` and `registry.ts`
+- [ ] `tsconfig.json` includes `.tactica/**/*` in `include`
+- [ ] You use `lookup('TypeName')` instead of direct imports
+- [ ] You do NOT write `as unknown as` with mnemonica types
+- [ ] You run `tsc --noEmit` to verify types resolve
+
+If any box is unchecked, the integration is incomplete.
+
+---
+
+## See Also
+
+- **Canonical typing guide:** [`core/docs/typed-lookup.md`](https://github.com/wentout/mnemonica/blob/master/docs/typed-lookup.md) — builder mode, the one-line `RegistryOf` bridge, and the augmented mode this repo generates for
+- **Library landing:** [`core/README.md`](https://github.com/wentout/mnemonica) — the thesis, the four data mistakes, the three type-system paths

package/lib/analyzer.d.ts

@@ -725,6 +725,40 @@ export declare class MnemonicaAnalyzer {
      * Resolve type from EDS call argument (best effort)
      */
     private resolveEDSArgumentType;
+    /**
+     * let-in-try: find the RIGHT-HAND SIDE of the first statically-visible
+     * assignment to `name` in the scope that declares it. The declaring
+     * container is found innermost-out (blocks, case clauses, the source
+     * file — the F20 walk); the scan recurses into nested blocks (try/
+     * catch/finally, if/else, loops, switch cases) but NEVER crosses
+     * function or class boundaries — an assignment inside a closure does
+     * not attribute. Returns undefined when the binding is declared but
+     * never assigned in scope (and stops there: an inner declaration
+     * shadows any outer binding).
+     */
+    private followScopeAssignment;
+    /**
+     * True when the statement list contains a `let`/`var`/`const`
+     * declaration for `name` (any initializer form).
+     */
+    private statementsDeclareVariable;
+    /**
+     * First `name = rhs` assignment in the statement list, recursing
+     * into nested in-scope blocks. Function and class bodies are
+     * boundaries and are not entered.
+     */
+    private findAssignmentRhsInStatements;
+    /**
+     * `name = rhs` as a direct expression statement.
+     */
+    private directAssignmentRhs;
+    /**
+     * Statement lists of the nested blocks that stay INSIDE the current
+     * scope — try/catch/finally, if/else, loops, switch cases, nested
+     * blocks, labeled statements. Function-like and class bodies are
+     * scope boundaries and yield nothing.
+     */
+    private nestedScopeBlocks;
     /**
      * Resolve the enclosing mnemonica scope of an EDS call site by walking
      * up the parent chain: nearest define()/lazy() call whose handler holds
@@ -742,6 +776,17 @@ export declare class MnemonicaAnalyzer {
      * metadata heuristic, not the identity-law surface.
      */
     private resolveWrapInstanceTypePath;
+    /**
+     * F24: resolve a bare-identifier annotation to a graph fullPath. The
+     * annotation may name the type directly (`LedgerUpdate`) or carry
+     * the GENERATED instance alias of a nested type
+     * (`UpdatePay_SomeTerminal`, imported from the generated types file
+     * via tsconfig paths) — not a graph node NAME. The name is tried
+     * as-is first, then its underscore→dotted form (the generated alias
+     * naming law; the same mapping scopes.json uses for annotations).
+     * Ambiguity and absence yield undefined.
+     */
+    private resolveAnnotationTypePath;
     /**
      * Resolve a bare-identifier type annotation of the nearest enclosing
      * function's parameter through the mnemonica-graph tiers (value scope,