test(release): verify a useful first-run experience from clean candidate installs

[DecisionNerd]

Outcome

Prove that a new technical user can install the release candidate and complete a useful GraphForge task using public instructions alone. Existing package/native-load checks are necessary but do not prove the first-use journey. Reuse #1096 consumer infrastructure and historical #180/#167/#186 patterns rather than adding a parallel release workflow.

Acceptance

• Choose one supported end-to-end quickstart with a small deterministic dataset, an understandable graph query or analysis, exact expected output, and a clear next step. Keep optional features and unavailable platforms out of the critical path. Document durable filesystem prerequisites and offer the existing in-memory path where appropriate.
• Exercise the documented entry paths for supported Rust, Python, Node and CLI consumers using the actual candidate artifacts in fresh environments without workspace caches, editable installs or unpublished dependencies. Reuse existing clean-consumer lanes and parameterize the journey where practical.
• At least two reviewers who did not author the quickstart follow the primary journey without undocumented help. Record prerequisite/install time separately from hands-on time to first useful result, commands, failures and interventions. Target a result within ten minutes after documented prerequisites; record and resolve usability blockers or explicitly document the practical timing outcome rather than fabricating a timing pass. This is usability evidence, not a noisy timing-only CI gate.
• Automated smoke coverage verifies the exact result, installed version/native engine, and persisted reopen where the documented path uses persistence. Public documentation distinguishes memory-only examples from durable examples.
• Repair verified install/docs/example defects through focused changes with appropriate checks. No hidden manual steps, weakened filesystem admission, skipped required platforms or assertions accepting missing results. Record any unresolved blocker in release: complete approved v0.6.0 scope and certify candidate readiness #1096.
• Hand off the tested documentation revision, candidate identities, reviewer findings, platform matrix and repeatable commands to release: complete approved v0.6.0 scope and certify candidate readiness #1096. release: ship coordinated v0.6.0 candidates and final publication #1095 repeats the primary journey against final public package identities; this issue does not publish artifacts.

Proof and scope

Given a fresh supported environment and only public instructions, the user installs the candidate and obtains the exact documented useful result. A broken command, missing dependency or wrong result fails the journey. Reviewers may be independent maintainers; this does not claim external adoption or replace M14's real-user pilots.

M13 native child and blocker of #1096. Coordinate positioning/examples with the companion launch-material issue. No new onboarding application, hosted service or unrelated feature work. Use synthetic fixtures and redact environment secrets from evidence.

Pre-v1.0.0 policy: backward compatibility, legacy support and migration machinery are out of scope. Explain intentional breaks and supported current versions without promising compatibility. Current-version correctness, authentication, recovery, active snapshots, resource budgets and supported binding/interchange behavior remain required. This issue does not authorize unrelated breaking changes.

Urgent first-use ergonomics and actual entry environments — 2026-09-17

Treat the verified low-level ceremony in the primary path as an RC blocker, within this issue's existing repair acceptance. Use a bounded implementation child only when an independently reviewable repair is ready; do not create parallel onboarding trackers.

• Primary Python/Node use needs no handwritten UUIDv7 generator, positional undefined chains or native IPC plumbing to inspect a useful result. Supply supported typed conveniences as needed while keeping behavior Rust-owned and data-bearing results Arrow. Retryable operations retain/expose the original operation identity and receipt; convenience calls must not create a fresh identity for a replay or weaken conflict refusal.
• Prove the expected entry paths: packaged VS Code extension with an agent, agent-led setup with installed skills/tool schemas, and a fresh Jupyter kernel. Qualify Kaggle and Colab separately with recorded results/limitations; a local notebook is not hosted-environment evidence. Reuse consumer/application tests rather than adding a second full release workflow.
• The assisting agent operates from public instructions and supported tool results, not repository internals or invented APIs. Record prompts/actions, exact native outputs, errors and interventions. Explain temporary memory-only state, kernel/session reset and a supported retain/export path without silently relaxing filesystem admission or sending source material externally.
• Apply the stage-specific comprehension questions in docs(analyst): define agent-assisted entry journeys and comprehension evidence #1399 and docs/engineering/analyst-ux.md: what is in the Branch, what supports the claim, what accepting a contribution changes, and how research continues. Independent reviewers explain answers against actual state; an agent self-report is not human comprehension evidence.
• Coordinate exact GraphForge/XYG/VSIX/docs versions with Prepare and verify the XYG candidate artifact cohort for every GraphForge host xyg#40/#108 and Project canonical GraphForge Arrow results into typed XYG visualizations graphforge-vscode#80/#82. Application rendering and access enforcement remain owned there; record which entry experiences are actually qualified before advertising them.

The ten-minute target, full existing Rust/Python/Node/CLI consumer proof, no-hidden-help rule and clean final package handoff remain. #1208 owns the comprehensive RC guide rewrite; #1211 owns post-release external pilots, including nontechnical analysts assisted by agents. Designing and checking the questions starts as capabilities land, not at final certification.

[DecisionNerd]

M12 decision-workflow handoff

M12's runnable examples and evidence are merged in PR #1604, squash commit dc34c18a120ef293abf1cb95648731ae6cb802da. The tested source package metadata is GraphForge 0.5.2; coordinated 0.6 package/version changes remain with #858.

• Python entry: examples/decision-workflow/analyst.py (in-memory native GraphForge, caller-owned typed-record function).
• Node entry: examples/decision-workflow/agent.mjs (in-memory native GraphForge, caller-produced Arrow artifact; needs the Node package and apache-arrow).
• Method-only task evaluation: examples/decision-workflow/evaluate_fixtures.py.

Observed offline fixture results: Mystery routes to research with rubric high; Voyage is uncertain and routed to human review with rubric medium; project review probability is 0.25. The agent fixture returns continue / uncertain clarify / review, with project review probability 0.25; caller policy applies the permitted continue action. The four-row fixture evaluation reports rule-baseline errors 0, producer answer errors 1, one missing result, one uncertain result, three policy reviews, and fixture-only Brier 0.1825.

Direct composition evidence is crates/graphforge-api/tests/decision_results.rs::composed_workflow_supports_independent_producers_explicit_action_and_replay; it includes the caller-record path, independently loaded Arrow fixture, private-field omission, stale and cancelled action refusal, explicit human override after uncertainty, retained Artifact cleanup/reopen, and exact receipt replay. Exact-head CI Gate and merge-group CI passed on the merged commit.

These are deterministic interoperability examples, not real-model accuracy, calibration, speed, or human-comprehension claims. The examples are memory-only; durable retention is covered by the Rust integration test. #1209 still owns clean-candidate installs, fresh-environment entry-path coverage, independent reviewers and comprehension evidence.

[DecisionNerd]

Context change, 2026-10-01: the consumer infrastructure this issue says to reuse has changed. #1705 (issue #1703) deleted Binding RC, the offline rehearsal and the clean-environment lanes. What exists now, per RELEASING.md:

• Before publication: a publish.yaml dry run builds every artifact and installs and runs the packed wheel and npm packages. Its artifacts (wheels, sdist, npm tarballs) are downloadable from the run for seven days, which is the source of "actual candidate artifacts" for the fresh-environment journeys here.
• After publication: the verify-published job installs the wheel from PyPI and the main and CLI packages from npm and runs smoke tests.

Neither runs the quickstart journey this issue specifies; that remains this issue's work. No acceptance criterion changes.