GW-034: Run and document first-user beta

[trippyogi]

Outcome

Run and document Gitworthy's first external-user beta with a small, deliberate cohort using real MCP and CLI workflows.

The beta should validate whether new users can install the tool, configure access, scout and interpret candidate queues, recheck before execution, report incorrect decisions, and understand the local-first data model without maintainer hand-holding.

Why this matters

The maintainer's daily dogfooding proves utility but not onboarding clarity or general reliability. Before freezing 1.0 contracts, Gitworthy needs evidence from users who did not build it and do not share the maintainer's implicit workflow knowledge.

Scope

• Recruit 3–5 design partners representing at least:
  • MCP-first agent use
  • direct CLI use
  • different operating systems
  • at least two contribution ecosystems/languages
• Define consent, privacy, support, capture, and outcome-recording expectations.
• Provide a clean-install beta checklist and task set: doctor, check, hunt, interpret queue, select/recheck, record outcome, report a problem.
• Collect structured feedback on setup time, errors, confusing verdicts, missing evidence, false decisions, performance, docs, and support burden.
• Capture anonymized product metrics locally or through explicit user-submitted artifacts—not hidden telemetry.
• Convert every correctness or safety failure into a regression case or tracked blocker.
• Publish a beta report with what worked, what failed, what changed, and unresolved release risks.

Non-goals

• No broad public launch.
• No paid plan or billing test.
• No private-repository requirement.
• No silent collection of user data or conversations.
• No success metric based only on install count.

Dependencies and readiness

• Depends on GW-033 / issue GW-033: Add onboarding, verdict, security, data, eval, and MCP docs #42.
• Contributor readiness: BLOCKED until GW-033: Add onboarding, verdict, security, data, eval, and MCP docs #42 lands. Recruitment and beta protocol can be drafted earlier.

Beta entry criteria

• Current release installs from a clean environment.
• Doctor, check, and bounded hunt work through CLI and MCP.
• Frozen eval meets the 0.8 target: at least 75 adjudicated cases and zero false hard SKIP.
• Documentation, support, security disclosure, and incorrect-verdict issue forms are live.
• Local data/capture behavior is documented and safe.
• No known P0 correctness or data-loss issue.

Acceptance criteria

• At least 3 external users complete the core workflow; target 5.
• At least two MCP hosts/harnesses and two operating systems are represented.
• Setup time, first successful result, and support interventions are recorded.
• Every reported false or confusing verdict receives an adjudicated disposition.
• Safety/correctness failures become frozen cases or release blockers.
• Users can identify ACT as a queue candidate and recheck before execution.
• No participant data is collected or published without explicit consent.
• A written beta report summarizes outcomes and recommended contract changes.
• Open beta findings are resolved, deferred with rationale, or explicitly block 0.9.

Tests and validation

• Dry-run the beta protocol internally from a clean machine/account.
• Verify support, security, privacy, and incorrect-verdict paths.
• Confirm capture/export bundles redact credentials and unrelated data.
• Reproduce and regression-test every accepted product defect.
• Review beta findings against schema-freeze readiness.

Suggested beta tasks

1. Install and run doctor.
2. Configure GitHub access and an MCP host.
3. check a known issue.
4. hunt a repo or org and explain the top candidates.
5. Select one candidate and recheck it.
6. Record or export the outcome.
7. Report one confusing or missing piece of evidence.

Deliverables

• Beta protocol and participant guide.
• Anonymized results table.
• Issue/case links for defects found.
• Public or repository-local beta report.
• Go/no-go recommendation for 0.9 contract freeze.

Compatibility

The beta is the last intended window for materially changing public contracts before GW-035. Any contract change discovered here must be documented and included in migration planning.

[trippyogi]

Beta playbook: https://github.com/trippyogi/gitworthy/blob/feat/0.9-reliability-contracts/docs/BETA.md (landing via PR #78). Sequencing: run design partners on pinned 0.4.1 now; grow corpus from dogfood.