# Ordered initial review input gate ## Canonical invocation and artifacts Run the public entry point before choosing no-op or editing source: ```sh python3 -B harness/agents/impl/skills/gitea-issue-rework/scripts/rework_comment.py input-gate \ --target --target-sha256 \ --provider-contract \ --provider-contract-sha256 --actor-id \ --output /decision.json ``` The canonical output is `/repositories///worktrees/issue-/verification//decision.json`. First prepare/admit this run root using the existing `verification_root.py prepare` procedure in `harness/operations/repository-cache.md`. The caller derives exact identity/path from authenticated workflow state. The CLI checks private descriptor-relative filesystem safety; it does **not** authenticate a broker lease or canonical verification-root identity. Do not infer authority from an arbitrary `--output` path. Use a fresh run and receipt after source/head/decision inputs change. Existing outputs are refused before credential loading or GETs; atomic no-clobber publication also preserves a file created concurrently. There is no update-in-place mode for this immutable artifact. The entire serialized receipt, including raw snapshot, is bounded to 1,000,000 bytes and fails closed rather than truncating. Legacy completion output size/replacement behavior is unchanged. ## Independent input The target file is exactly schema `gitea-agent.rework-input/v1`: ```json {"schema":"gitea-agent.rework-input/v1","target":{"owner":"acme","repository":"demo","issue":7,"pr":9},"head":"<40 lowercase hex>","contract_sha256":"<64 lowercase hex>"} ``` Use the independently verified current PR head and SHA-256 of the exact fresh Source Issue UTF-8 body. Names/positive integer IDs/digests/field sets are strict; Issue and PR differ. No selected review ID, final rework head, rendered comment, or `expected.json` is required. The schema and explicit provider contract are validated before credentials or network access. Two authenticated GET-only captures reuse identity-first native metadata, repository/PR/Issue/author binding, complete bounded pagination, Link provenance, per-review inline record counts and drift checks. Initial intake requires every review's real inline endpoint; 404/405 counter-only fallback is not allowed, even with a `per_review_or_pr_count` provider declaration. The initial phase also requires the repository's native default branch to match PR base ref, the exact discovery-draft/v2 first line, and exact Source Issue digest. Discovery structural approval, unresolved-question checks and edit authorization are independent upstream requirements, not claims made by this gate. ## Initial collection checks versus publication counter checks Initial intake validates collected rows, endpoint/pagination provenance, duplicate IDs (including cross-review inline IDs), review-level `comments_count`, record cardinality and the Source Issue comment collection. These remain blocking checks. PR-wide `comments` and `review_comments` projection crosschecks are separate diagnostics, not evidence that a complete collection is missing records and not initial decision blockers. Source Issue `comments` crosschecking is unchanged. The receipt adds `counter_diagnostics`, with keys `inline`, `pr` and `pr_issue`. Each entry records the declared `field`/`components`, unmodified `observed` value, collection-derived `expected` value, and `status`: `match`, `mismatch`, or `unverified` (missing, negative or non-integer observed counter, including booleans). A match means only that the explicitly declared formula matches this observation; it does not attest deployed-provider semantics or counter freshness. Diagnostics never auto-select a projection, modify raw counts, or grant edit/publication permission. Missing/malformed PR counters do not bypass malformed native records, failed GETs, incomplete lists or drift checks. Provider schema/version binding and explicit declarations are still required. Rework/no-op/blocked decisions retain their role/head/contract/state rules regardless of diagnostics. `snapshot`/`verify-live` publication readback continues to require strict provider counter crosschecks and its existing explicitly declared fallback; an initial receipt cannot substitute for that verification. ## Derived decisions The `gitea-agent.rework-input-gate/v1` receipt retains parsed native records, provider row order and body text in `raw_input_snapshot`, bound by `raw_input_sha256`; it is not a byte archive of HTTP serialization. A separate derived timeline records every review's ID, native author stable ID/login/role, state, submitted timestamp, reviewed SHA, stale/dismissed flags, canonical body marker, body digest and eligibility/exclusion reasons. Sorting does not mutate raw evidence. Order by UTC instant with exact up-to-nine-digit fractional precision, then numeric review ID for deterministic display ties. ID order is not causal attestation. Conflicting same-instant same-role state/body/marker records block and have no selected review. Markers use the actual canonical code FIRST-line and spec LAST-line formats; spec result digest and correlation match its renderer's separator-LF algorithm. Current authoritative marker/head/contract/state contradictions block. Role IDs must be positive, distinct from impl, and consistent; unrelated roles cannot supply required approvals. Old-head history is recorded but cannot determine current-head action. - `rework`: both roles have a current usable selection, and the only remaining decision reason is latest role-specific `REQUEST_CHANGES`. `decision.rework_review_ids` contains those request IDs only, never spec/code approvals. Validate their findings and authorization independently before source edits. - `no_op`: both spec and code-review role-specific latest current-head, nonstale, nondismissed reviews are `APPROVED` for the fresh contract. A spec approval cannot supersede a code request. Earlier same-role requests may be superseded by a later valid same-role approval, never by another role. - `blocked`: missing current roles, pending authoritative reviews, malformed/ambiguous bindings, same-instant conflicts, current manual `COMMENT`, or `blocked_spec` prevent automatic action. `blocked_spec` is explicit and routes to Discovery investigation, not impl repair. No keyword heuristic or marker alone proves actionable finding semantics. This gate's no-op means skip implementation rework, not native review publisher idempotent reuse (which can reuse an existing REQUEST_CHANGES review). Publication, journals and their candidate-selection rules remain unchanged. A receipt is neither publication success nor edit permission, lease/worktree admission, full Discovery approval, independent reviewer-ID attestation, or causal event proof. Do not reuse an old receipt as authority; recheck provider/head/contract and independent upstream gates before an action.