Fix scoped TS/JS call evidence and release Context 0.3.3

GOALS.md

@@ -81,21 +81,30 @@ Exit: documented behaviour matches executable fixtures, including the cases wher
 - [ ] Walk through the documented install, scan, persist, retrieve, export and import path on a clean machine or isolated environment.
 - [ ] Exercise the supported local workflow on an explicitly selected non-ForgeSworn repository without workspace-specific paths, private worker helpers, Oathrun or a ForgeSworn account. State language/relationship coverage and gaps.
 - [ ] Exercise an actual MCP client session, including initialisation, errors, cancellation and bounded output.  Name the tested client and version.
-- [ ] Qualify actual Claude Code and Codex task/tool use separately, recording model/effort, source freshness, restart and disable. Connection health alone is insufficient; Claude Desktop is a separate client surface. Keep provider authentication outside Context.
+- [ ] Qualify actual Claude Code, Codex and OpenCode task/tool use separately, recording model/effort, source freshness, restart and disable. Connection health alone is insufficient; Claude Desktop is a separate client surface. Keep provider authentication outside Context.
 - [ ] Verify compatibility fixtures for existing package names, APIs and signed wire formats.  Document any required migration before release.
 - [ ] Test intended consumer integration in isolated branches or fixtures.  Do not silently repin or migrate live consumers.
 - [ ] Reconcile README commands, package versions, changelog and extraction provenance.  Distinguish a prepared tarball from an available registry release.
 - [ ] Publish through the authorised release process, then install the exact published versions from the registry outside the workspace and repeat the smoke workflow.
 
 Exit: a newcomer can follow the published instructions successfully without local workspace links or unpublished dependencies.
 
-## G4: Useful savings, with quality held constant
+## G4: Useful savings and better accepted results
+
+The owner's stronger product requirement is **better accepted developer results**.
+The [deterministic intelligence contract](docs/DETERMINISTIC-CODE-INTELLIGENCE.md)
+adds a prospectively locked quality-improvement measure and competent
+ordinary/Graphify-assisted baselines, including an OpenCode client cohort.
+Smaller packets or unchanged quality alone do not establish that claim. Preserve
+existing D5 protocols/results; qualify retrieval first, then mixed-model routing
+separately. Internal adoption need not wait for the complete external comparison.
 
 - [ ] Define representative tasks and acceptance tests before comparing baseline and Z1P-assisted runs.  Include repository orientation, bug investigation, change impact and an accepted code change.
 - [ ] Hold repository revisions, task instructions, model settings and acceptance standards constant.  Separate context improvements from any later model-routing experiment.
 - [ ] Count the whole task: retrieved source, input/output tokens, cached tokens where reported, retries, tool calls, failures and review time.  Include scan and refresh overhead.
 - [ ] Record missing provider usage as unknown, never zero.  Keep observed billing, estimated token cost and fixed subscription costs distinct.
 - [ ] Report accepted tasks, regressions and unsuccessful runs alongside cost.  Navigation compression alone is not an inference-bill saving.
+- [ ] Demonstrate a predeclared improvement in first-pass acceptance, missed/incorrect dependencies or substantive review repairs on representative tasks against the stated existing workflow; report losses and inconclusive results too.
 - [ ] Publish a reproducible, non-sensitive evaluation and its limitations.  Keep private code, prompts, invoices and customer data out of this repository.
 
 Exit: the tested workflow reduces cost per accepted outcome without lowering the agreed quality bar.  If it does not, record the result and fix the cause before making a savings claim.

PRODUCT_DIRECTION.md

@@ -3,9 +3,12 @@
 Updated: 22 September 2026. Product direction and acceptance plan, not a claim
 that the capabilities below are all shipped.
 
-Context should help any developer understand and change a codebase using less
-model context, while preserving the quality of their development work. The
-target is an independently implemented, MIT-licensed alternative to Graphify
+Context must help developers produce better accepted changes with less complete
+task cost. Smaller model context alone is insufficient: fewer wrong conclusions,
+missed dependencies and repair rounds must be demonstrated against competent
+existing workflows. Deterministic analysis and deeper language resolution are
+near-term product priorities. See the [implementation and benefit contract](docs/DETERMINISTIC-CODE-INTELLIGENCE.md).
+The target is an independently implemented, MIT-licensed alternative to Graphify
 for repository graphs, exploration and coding-agent context. Do not copy or
 integrate Graphify code. Replacement is a product goal; feature parity and
 whole-task savings have not been demonstrated.
@@ -24,8 +27,11 @@ and actual cash savings are separate outcomes.
 
 ## Product boundaries
 
-Claude Code and Codex are first-class target MCP clients. Context already has
-stdio MCP interfaces; both need complete independent developer acceptance.
+Claude Code, Codex and OpenCode are first-class target MCP clients. Context already
+has stdio MCP interfaces; each needs separate complete developer acceptance.
+OpenCode qualification is planned, not delivered. Support developers who already
+combine Graphify and frontier/cheap models; measure the benefit over that workflow
+without requiring them to replace their client or routing policy.
 Provider login, credentials, model selection and execution belong to the client
 or optional Oathrun runtime. Context retains its own source/evidence access
 boundaries. See [client and language goals](docs/CLIENTS-AND-LANGUAGES.md).

RELEASE_EVIDENCE.md

@@ -4,6 +4,29 @@ Latest implementation and adoption results are in the
 [dogfood execution ledger](docs/DOGFOOD-EXECUTION.md). The dated snapshots below
 remain historical evidence; internal pilot acceptance is separate from G0–G4.
 
+## 0.3.3 shipment checks, 22 September 2026
+
+The TS/JS scanner now binds calls to scoped compiler symbols over selected source
+files. It avoids false shadowed targets and nested-callback attribution, follows
+supported local aliases, rejects type-only/ambiguous exports and separates
+same-named static/instance methods. Analysis uses no LLM and the compiler host has
+no filesystem, configuration, default-library or network fallback. Full project
+resolution and default-export expression assignments remain unsupported.
+
+Implementation validation passed 420 tests, independent packed-package smoke and
+both unchanged benchmark gates with required-source recall 1.0. Independent
+review findings were repaired and rechecked. See the
+[execution ledger](docs/DOGFOOD-EXECUTION.md#22-september-2026--scope-aware-tsjs-call-evidence-local-unreleased)
+for attempts, repairs and the distinction between worker tokens and total cost.
+Versioned shipment CI, archive checksums and public-download checks accompany the
+GitHub release; this source entry does not pre-claim their outcome.
+
+Install both matching 0.3.3 tarballs with Node 24. Existing MCP servers require a
+reconnect after upgrading. npm authentication again returned HTTP 401 on
+22 September; registry publication remains blocked. Actual client acceptance,
+consumer upgrades and measured developer/subscription/cash benefits are separate
+checks; this scanner correction does not close those gates.
+
 ## 0.3.2 shipment checks, 22 September 2026
 
 Navigation and exact source packets now accept `.kts`, `.cc`, `.cxx`, `.hh`,

docs/CLIENTS-AND-LANGUAGES.md

@@ -11,7 +11,7 @@ selection, extraction, graphs, freshness, bounded retrieval, provenance and
 evidence access checks. Its supported local workflow needs no AI provider login,
 API key, subscription or model invocation.
 
-Claude Code, Codex or another client consumes that evidence over MCP or CLI.
+Claude Code, Codex, OpenCode or another client consumes that evidence over MCP or CLI.
 The client chooses its model/effort and handles provider authentication, billing,
 conversation, tool execution and approval UX. Oathrun owns those execution and
 routing responsibilities when it is the chosen agent host. Using Context from
@@ -55,12 +55,18 @@ restart/disable and consequential task qualification remain open. See
 
 ## OS1 client and retrieval assignments
 
+OpenCode is now a first-class qualification target. Its setup, lifecycle,
+receipt and mixed-model acceptance are **not yet tested**. Follow the
+[deterministic language and developer-results contract](DETERMINISTIC-CODE-INTELLIGENCE.md)
+for OS1e, compiler/resolver boundaries and fair Graphify/OpenCode comparisons.
+
 | Task | Owner / where | Model and effort | Acceptance |
 | --- | --- | --- | --- |
 | **OS1a — Claude Code alongside Codex. Partial: read-only audit accepted** | Context integration owner, Node tools, public setup docs and isolated client fixtures | Flash/thinking off for bounded docs/fixtures; Terra/medium integration; **Claude Sonnet 5/medium** as the first real Claude executor; **Claude Opus 5/high** for one consequential source-backed task after basic acceptance | A pinned package launches in both clients against an explicit root; real tool discovery, status/refresh/search, bounded evidence, edit/stale/refresh, restart and disable work. Record actual client/model/effort and accepted task, not just Connected |
 | **OS1b — Sufficient evidence through MCP. Shipped; first Claude use recorded** | Context implementation owner, shared packet module plus `packages/context-tools` adapters/tests | Terra/medium implementation; Sol/high boundary review; Flash/off for scoped fixtures | `repository_packet` returns bounded exact ranges or complete selected TS/JS blocks with provenance and stale rejection. Installed-tarball stdio retrieval, edit/refresh and restart pass. Reconnect existing clients to discover the new tool; first Claude read-only use is recorded, while lifecycle qualification remains open. No shell helper required by the consuming model; no arbitrary path escape |
 | **OS1c — Graph questions through MCP** | Context graph owner, same tools adapter; follows OS3/OS4 evidence integration | Terra/medium; Sol/high review of scope/provenance | Bounded repository symbol/neighbour/path queries return precise source and derivation metadata in both clients; do not mistake the existing signed-cache graph tools for this capability |
 | **OS1d — Other client surfaces** | Context integration owner, portable examples and clean-client acceptance | Flash/off for docs, Terra/medium review; user's chosen model for the actual client | Claude Desktop is separately qualified after Claude Code; other MCP clients follow demand. Never infer their acceptance from Claude Code or Codex |
+| **OS1e — OpenCode. Planned; first-class target** | Context integration owner; public setup, shared MCP and provider-neutral receipt fixtures | Flash/off bounded fixtures/docs; Terra/medium integration; existing user-selected model for client qualification | Actual pinned-client task, exact root and four tools, edit/stale/refresh, restart/cancellation/disable; preserve existing agents/Graphify and count model handoffs without changing routing policy |
 
 The Anthropic API model IDs for those qualification assignments are
 `claude-sonnet-5` and `claude-opus-5`. Claude Fable 5.1
@@ -95,19 +101,19 @@ do not silently scan the parent workspace.
 
 | Language / surface | Current support | Next useful depth |
 | --- | --- | --- |
-| TypeScript / JavaScript / TSX / JSX | Compiler API syntax trees; selected relative imports and syntactic call hints. No tsconfig loading or type checker; not complete semantic resolution | Aliases, re-exports, symbol identity and references with honest unresolved cases; keep dynamic calls and type-directed evidence distinct |
+| TypeScript / JavaScript / TSX / JSX | 0.3.3: isolated Program/TypeChecker binding over selected trees; scope-aware direct calls and local named default/re-export aliases. No tsconfig, external libraries or project type checking. 0.3.2 has earlier syntax/name hints | Explicit project configuration, references and task-level evidence queries; keep dynamic calls and type-directed evidence distinct |
 | Rust / Cargo | Lexical declarations and simple module-file guesses; manifest path dependencies in separate snapshots; Cargo lock resolution unsupported | Parser-backed modules, use/re-exports, types/traits/impls and call/reference candidates; selected workspace/features/cfg context; preserve unresolved macro/trait dispatch |
 | Kotlin / Java | Lexical declaration inference; no meaningful compiler-resolved import/type/call graph | Parsed declarations/imports; package/module and Gradle dependency evidence, then explicitly qualified references. Do not execute Gradle scripts during indexing |
 | Python | Lexical declarations and conservative relative-import guesses | Parsed scopes/imports and useful references; explicit environment/package assumptions; no import execution |
-| C / C++ | Lexical declarations and quoted-include guesses; broad scanner accepts more suffixes than navigation | Align `.cc/.cxx/.hpp` selection; parse declarations/includes; distinguish build-config/preprocessor-dependent and FFI edges |
+| C / C++ | Lexical declarations and quoted-include guesses; selected suffix gaps aligned in 0.3.2 | Parse declarations/includes; distinguish build-config/preprocessor-dependent and FFI edges |
 | Dart / Flutter | Absent from both the navigation allowlist and broad extractor | Add declared support and fixtures, then parsed imports/exports/parts and declarations with pub package/version evidence; no claim that adding `.dart` is semantic support |
 | Swift | Lexical declarations; no module/type/call resolution | Parsed declarations/imports with selected package/build metadata and explicit unresolved cases |
 | Vue / Svelte, SQL and build/config contracts | Dedicated parsing absent from these source extractors | Confirm use in selected projects; add component/script boundaries or schema/config relationships only against actual tasks |
 | Go, C#, Ruby, PHP | Conservative lexical extraction; some local-import guesses | Retain explicit support level; deepen when an accepted task needs it |
 
 Navigation and extraction must have a tested capability manifest so their suffix
-support cannot silently diverge. Current navigation, for example, omits `.kts`
-and several C++ suffixes which the broad scanner accepts. Source packets currently
+support cannot silently diverge. The `.kts` and selected C++ gaps were fixed in
+0.3.2; that adds source eligibility, not deeper resolution. Source packets currently
 have syntax-aware planning for TS/JS only; add complete-span planning for each
 new parser rather than silently truncating another language's function.