RT-04: Cross-platform installation, onboarding and endpoint discovery

Campaign: eve-post-development-20261011

DEFERRED - do not execute. Development must be reviewed/integrated before the final candidate is frozen and Ray authorizes the round.

Matrix: #414
Project: https://github.com/users/R4yHarris/projects/3
Spec: FEATURE_SPEC section 5.2: Roster and staffing; honor sections 3 and 7.
Baseline: pending final reviewed/integrated candidate SHA and frozen configuration; never reuse an old uncommitted fingerprint.
Mode: Cross-platform | Priority: P0 | Initial result: Not run | Evidence stage: Not run

Outcome

Demonstrate the named operational behavior with attributable evidence, or record a failure, blocker or unresolved spec decision without claiming success.

Prerequisites

• No scenario prerequisites; execution still requires the safety approvals below.

Operator procedure

1. Perform a fresh submodule-initialized installation on Windows, macOS and Linux with Node 20+; record OS, Node version and revision.
2. Invoke installed roster, onboard and doctor from a separate disposable consumer repository; select an approved local OpenAI-compatible endpoint and probe /v1/models.
3. Exercise no endpoint, unreachable endpoint, ambiguous model list and a configured endpoint; inspect saved private fleet/config without copying secrets.

Acceptance checks

• The installed roster executable starts without runtime package dependencies and resolves the contracts publisher through the documented resolver.
• Onboarding saves only explicitly confirmed private configuration, and doctor reports actionable prerequisites without exposing credentials.
• Served model and reported context are retained; absent context remains unknown. Failed probes do not claim a configured endpoint is healthy.
• Windows, macOS and Linux each have direct host evidence; simulated path tests do not count as completed platform onboarding.

Evidence and result

Use the matrix observation template. Append one redacted observation per actual attempt/case. Do not replace failed attempts with a later pass. Include run/seat IDs, exact interface, actual verification/review and human rating only when observed. Fixture results must be labeled fixture, not live operational evidence.

Fresh campaign starts at Not run. Previous comments, observations and evaluations are retained as historical evidence; they are not new-round results. Only observations tied to this candidate and campaign count. All required cases need new evidence and human review before Result becomes Pass. Unavailable prerequisites are recorded as fresh Blocked observations, not inherited old outcomes.

Safety and non-goals

This is TEST work, not a build task. No product/source/policy/workflow/vendor edits are requested; do not execute this issue as an implementation slice. Use disposable approved fixtures and separately approved bounded model tasks. No actual credentials, prompt/source bodies or transcripts may be posted.

No model calls, spend, publication, process termination or destructive cleanup are authorized by issue creation. Obtain explicit operator approval before those operations. Keep this issue only in Roster Test. Cross-link a separate Roster Build issue for any discovered defect; keep test failure evidence here and rerun after the fix.

Workflow and release gate

Backlog -> Ready only after dependencies, candidate freeze, disposable scope and budgets are approved. In progress means actual authorized execution; In review means evidence is awaiting independent/human review. Done/Pass requires all original required cases and genuine human acceptance, not a subset of green fixtures. A defect creates a separately scoped Roster Build issue; retain its failing observation here.

Plain-text Ask example

Give me safe Windows PowerShell installation and local endpoint onboarding instructions for Roster; do not install software or change saved configuration. Output it in a new "onboarding-guide" directory

Use: Illustrative entry point only. This scenario remains deferred; the original operator procedure and acceptance cases are still required.
A prompt alone does not verify this scenario. Operator-controlled fixtures, actual evidence and genuine human review remain mandatory. Never execute a TEST issue as a product implementation issue.