TensorEQ Runtime Diagnostics

Hardware-aware runtime diagnostics and evidence reports for AI, embedded, and edge workspaces.

Status: preview / under active development. Not yet published to the VS Code Marketplace.

TensorEQ collects bounded, advisory evidence about a workspace — source layout, hardware target selection, host runtime, toolchain inventory, model source candidates, and adapter availability — and records every safety boundary it crosses in a deterministic JSON manifest. It does not run models, load adapter code, validate API keys, or reach the network on the user's behalf.

What TensorEQ does today

TensorEQ adds an Activity Bar container with an L4 Intelligence tree view, a TensorEQ Probe output channel, a status bar item, and a set of commands that progressively produce evidence under .tensoreq/evidence-manifest.json. Each command is a single, bounded, fail-closed step on the safety ladder:

• Source / workspace probing — file-pattern scan with bounded exclusions; produces .tensoreq/source-probe.json and a profile classification.
• Hardware target selection (M4) — manual user pick from a static catalogue. Selected ≠ connected ≠ verified.
• Host runtime inventory (M5) — vscode.env and os.cpus() snapshot, no hostname/userInfo/networkInterfaces reads.
• Toolchain inventory (M6) — declared toolchain files only; build_ready: false, flash_ready: false.
• Model workspace gate (M7), model source inventory (M8), model candidate selection (M9), model header gate (M10) — bounded model-file discovery and a 64 KB header gate; no parse, no tensor read.
• Model adapter registry (M11) — static, metadata-only catalogue of known adapter shapes.
• Model adapter availability plan (M12) — declarative future check policy; the forbiddenInThisMilestone array pins what cannot be done.
• Model adapter availability probe consent (M13) — explicit, manual modal consent record, scoped to a future probe only.
• Model adapter availability probe method (M14) — selects a single allow-listed method (require.resolve for onnxruntime-node) without executing it.
• Model adapter availability probe execution (M15) — the one narrow runtime call: require.resolve("onnxruntime-node") inside a try/catch, gated on M13 granted + M14 selected + drift check. The resolved path is never stored, returned, or logged.
• Model adapter load plan (M16 Step A) — a pure planner that classifies the load plan; defaultAction is always do_not_load.
• Model adapter load plan report view (M16 Step B) — a read-only webview (enableScripts: false, strict CSP, empty localResourceRoots) that renders the M16 Step A plan; no command URIs, no scripts, no remote resources.
• Explicit adapter execution boundary design (M17) — a pure design layer that records what a hypothetical future execution would require (workspace_trust, explicit_user_approval, execution_policy, adapter_specific_risk_acknowledgement). executionAllowed is always false.

Safety model

• Advisory by default. Detected ≠ selected ≠ planned ≠ approved ≠ verified ≠ executed. Each rung is its own milestone with its own gate.
• No silent adapter loading. No require(adapter), no dynamic import(adapter), no import.meta.resolve(adapter). The single M15 require.resolve call is allow-listed to onnxruntime-node only and is wrapped in try/catch with the resolved path discarded.
• No model execution. No tensor read, no weight read, no graph parse, no tokenizer read, no architecture/dtype/shape/op inference.
• No API key validation. No outbound network requests for adapter validation.
• No network calls for adapter validation, package detection, registry lookup, model download, or telemetry. No fetch/http/ https/net usage in the extension.
• No fake device claims. Selected hardware is not connected hardware; detected source is not verified source; generated manifest is not runtime evidence.
• No .tensoreq writes outside the explicit per-command evidence workflow described above. The user owns and can delete .tensoreq/ at any time.
• No telemetry. No agent sync. No "phone home".

Workspace Trust behavior

The Model Adapter Load Plan report (M16 Step B) honors vscode.workspace.isTrusted. When the workspace is untrusted, the report shows boundaryStatus: blocked, reasonCode: workspace_untrusted, and defaultAction: do_not_load (or do_not_execute from the M17 boundary). The view does not prompt the user to trust the workspace and does not unlock any functionality from inside the report.

Other read-only commands operate within the standard VS Code Workspace Trust contract.

Command list

No commands named loadNow, executeNow, runAdapter, loadAdapter, startAdapter, validateAdapter, connectAdapter, executeAdapter, approveAndRun, or approveAndLoad exist.

Marketplace status

This extension is under active development and currently distributed for local testing only. It is not yet published to the VS Code Marketplace or to Open VSX. The preview flag in package.json is set to true so that any future publication clearly signals pre-release status.

M20 prepares the publisher-identity contract and the publish dry-run checklist only; it does not publish the extension, does not run vsce publish, does not handle any Personal Access Token, and does not add any CI publish automation. See docs/TEQ_EXTENSION_MILESTONE_20_PUBLISHER_IDENTITY_PUBLISH_DRY_RUN_CHECKLIST.md for the full M20 contract.

The manual UI smoke-test checklist lives at docs/TEQ_EXTENSION_MILESTONE_22_MANUAL_UI_SMOKE_TEST_SESSION.md. An operator runs it locally in an interactive VS Code session; no result file is committed to the repo.

The extension ships a single EQ mark across both sizes: a plain monochrome "EQ" in resources/tensoreq.svg (activity bar, currentColor-themed) and a 128×128 Marketplace-compatible PNG derived from the same EQ identity at resources/tensoreq.png. The PNG is project-owned and regenerated deterministically by scripts/build-icon.js (npm run build:icon).

Screenshots

(Placeholder — no screenshots have been captured for this preview. Screenshots will be added when the extension reaches a publishable milestone. No images are bundled with the current package.)

Known limitations

• TensorEQ does not yet load adapter code under any path. The M14–M17 chain only records boundary state.
• The executeAdapterAvailabilityProbe command performs a single allow-listed require.resolve("onnxruntime-node") call. It does not import or execute onnxruntime-node. The resolved path is never persisted.
• Hardware target rows are static catalogue entries; TensorEQ does not enumerate connected devices.
• The L4 tree rows show advisory state only.

M14–M17 ladder

detected ≠ selected ≠ planned ≠ approved ≠ executed

Each transition is a separate milestone with its own gate, its own evidence event, and its own forbidden list.

Development validation

cd extensions/tensoreq
npm install
npm run compile
npm test
# Optional Marketplace packaging dry-run (creates a local .vsix, not committed)
npx --yes @vscode/vsce package --no-yarn

Run the extension in an Extension Development Host from VS Code or Code OSS. The extension does not require publishing to Open VSX or the VS Code Marketplace for local development.

Local install from VSIX (no publish)

The packaging dry-run produces a local .vsix that can be installed into your own VS Code for a release-candidate smoke test — no publication required:

cd extensions/tensoreq
npx --yes @vscode/vsce package --no-yarn
code --install-extension tensoreq-0.0.1.vsix
# ...verify, then uninstall when done:
code --uninstall-extension tensoreq.tensoreq

The .vsix can also be installed via the Command Palette (Extensions: Install from VSIX...). The generated .vsix is git-ignored and must not be committed. This is a local install only; the extension has not been published to the Marketplace or Open VSX. See docs/TEQ_EXTENSION_MILESTONE_21_RELEASE_CANDIDATE_QA_LOCAL_VSIX_INSTALL_SMOKE_TEST.md for the full smoke-test checklist.