RT-19: CLI and terminal-interface acceptance parity

Campaign: eve-post-development-20261011

EASY SUBSET AUTHORIZED: Ray authorized easy live tasks on 2026-10-11. Remaining cases and higher difficulty stay deferred.

Matrix: #414
Project: https://github.com/users/R4yHarris/projects/3
Spec: FEATURE_SPEC section 5.7: Human interface; honor sections 3 and 7.
Baseline: pending final reviewed/integrated candidate SHA and frozen configuration; never reuse an old uncommitted fingerprint.
Mode: TTY | 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

• RT-04: Cross-platform installation, onboarding and endpoint discovery
• RT-07: Ask classification and bounded-slice planning
• RT-10: Documentation and code slices through the complete execution stack

Operator procedure

1. Use installed roster --help, non-TTY empty invocation and an interactive TTY session; record process exit behavior.
2. Run equivalent bounded tasks through CLI issue run and shell /run, and separately through shell plain text and /ask local intake.
3. Compare artifacts, scope, verification, review and attribution while recording entry interface explicitly.

Acceptance checks

• Help exits zero; empty non-TTY usage exits two; installed roster opens the documented shell in a TTY.
• Equivalent delivery operations preserve shared lifecycle gates, model provenance and worktree isolation.
• CLI ask issue/draft behavior remains distinct from local shell asks, which do not silently create GitHub issues.
• Each interface run has explicit evidence and outcome; a stored command line or unit-test fixture is not a completed interface acceptance run.

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

Write a short Markdown guide explaining the difference between a Git branch and a worktree, with one safe PowerShell example for listing each. Do not execute the examples or change existing files. Output it in a new "easy-git-guide" directory

Use: Easy-level live delivery sample approved by Ray on 2026-10-11; only this bounded subset is authorized now.
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.