gitea-agent/harness/agents/impl/skills/gitea-issue-rework/references/input-gate.md

Ordered initial review input gate

Canonical invocation and artifacts

Run the public entry point before choosing no-op or editing source:

python3 -B harness/agents/impl/skills/gitea-issue-rework/scripts/rework_comment.py input-gate \
  --target <rework-input.json> --target-sha256 <exact-file-sha256> \
  --provider-contract <provider-contract.json> \
  --provider-contract-sha256 <exact-file-sha256> --actor-id <impl-stable-id> \
  --output <admitted-verification-run>/decision.json

The canonical output is <harness-root>/repositories/<owner>/<repository>/worktrees/issue-<issue>/verification/<run-id>/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:

{"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.

Initial diagnostic intake remains unchanged. Publication requires strict counter validation and explicit version-specific cache opt-in only: optional aggregate semantics are supported for cache_mode: "gitea-conversation-v1", version 1.27.3, with comments components exactly ["top_level", "reviews"]; omission of the mode retains strict legacy behavior. No numeric fitting or automatic profile/provider adjustment. 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: at least one role has a current usable latest REQUEST_CHANGES, and there are no blocking reasons other than review absence. A missing counterpart is retained as missing_current_review information and does not block acting on the valid request. decision.rework_review_ids contains only selected current request IDs, never absent roles, excluded history or 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 without a usable latest request, pending authoritative reviews, malformed/ambiguous bindings, same-instant conflicts, current manual COMMENT, or blocked_spec prevent automatic action. Actual blocking reasons take precedence even when a valid request exists. 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.