RT-01: App-authored delivery and measured publication attribution

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.1: Identity and authority; honor sections 3 and 7.
Baseline: pending final reviewed/integrated candidate SHA and frozen configuration; never reuse an old uncommitted fingerprint.
Mode: Live App | 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-10: Documentation and code slices through the complete execution stack
• RT-13: Per-check review truthfulness and unchanged-review publication gate

Operator procedure

1. With explicit operator approval, use a disposable acceptance repository and a bounded one-file issue. Record baseline commit, served model, fleet profile, interface, requested flags and run ID.
2. Run the configured planner/coder/reviewer without publication; inspect verification and REVIEW.md before explicitly requesting App publication from that task worktree root.
3. Inspect the resulting PR and commits using read-only GitHub queries; retain PR URL, commit SHA, required-check conclusion and merge actor separately.

Acceptance checks

• No publication occurs without the explicit request; App author/committer and authenticated publishing principal are observed, not inferred from AI_MODEL.
• AI-Agent, AI-Model and AI-Run contain the actual completed coder model/session/task and response-backed usage, with unknown slots explicitly unknown; inherited GHCP metadata does not replace seat evidence.
• The issue remains open for human evaluation after publication. PR author, pusher evidence if available, and merger are recorded independently; unavailable audit fields stay unknown.
• Spec decision required before execution: FEATURE_SPEC 4.9 and 8 say draft PR, whereas repository publication guidance requires reviewed non-draft publication/merge-when-green. Obtain a human decision; do not silently reconcile this discrepancy.

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

Prepare a small reviewed change explaining a branch versus a worktree. After review, stop and show the App-only publication handoff and actual coder attribution. Do not publish yet.

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.