Is there an existing issue or feature request for this?

• I have searched the existing issues and feature requests.

What area does this improvement affect?

New Feature

What actions does this improvement affect?

Commit

Description of the idea or improvement

Follow-up to #910 and #915. Extend Commit to evaluate legitimate acceptance scope that exceeds the current single assessment envelope.

Proposed contract

• Build a complete, versioned scope manifest with host-owned requirement and exclusion IDs. IDs are stable for the same frozen source across batch sizes, order and retries. Bind each ID to its original issue lines or verified published SDD location, with case references, qualifiers and exclusions intact. Preserve 🐛🧑‍💻 - Progress scope assessment rejects an API requirement with scope clause limit in generated issue plan metadata #828 configuration separation and 🐛🧑‍💻 - Progress verification counts the published SDD seed against the scope clause limit #910 verified-seed reconciliation.
• Bind the manifest and every batch receipt to one repository, issue snapshot, owning PR when present, immutable base SHA and evaluated head SHA. Plan bounded classification and assessment batches against the existing immutable comparison evidence. Give every source span and requirement a checked owner across the whole attempt.
• Require one validated outcome and traceable evidence for every required or uncertain ID from that same evaluated head before publishing any progress. A missing implementation can count as assessed when its evidence substantiates that outcome. Missing evidence, guessed status, omitted or foreign IDs, incompatible duplicate receipts, stale input or an exhausted budget retain the previous assessment and labels.
• Recheck issue and SDD authority, PR base and head before the existing publication boundary. Only the complete validated aggregate may update progress. Use an idempotent publication identity and preserve the existing single-batch path and independent CI, review and approval gates.

Capture → inventory → bounded batches → validate complete same-head evidence → recheck freshness → publish once.

Keep finite per-request and per-attempt budgets. Document measured limits for batches, aggregate bytes, calls and retries in the SDD. Keep the publication gate fixed and expose safe counts, missing IDs and the failing batch in Checks and the Job Summary.

Specification ownership and publication

Publish the implementation contract as a canonical companion SDD for the existing github-communication-experience capability, at the new companion path specs/batched-progress-scope.md. Retain the existing scope ownership and capacity SDDs as owning references and update those documents and their catalog evidence with implementation. The preparation attempt 42334359034 could not append an update because the existing owner failed the required-heading contract. The companion must satisfy all canonical headings, validation and acceptance criteria. All same-head evidence and complete-aggregate publication requirements above remain mandatory.

Current limitations or challenges

Primary reproducer — Domus #23 / PR #29

Use Domus #23 and PR #29. Freeze the issue body with SHA-256 f5c01613456235e349179026a023ad992b3d95fc427568f27c8f7e31fbf8b2d0, base 5b7bdcdee3a9e98d6669bfd34ce750ae30a8c775 and head 2a35e2a3bcfe98b58ddf184b6e781a1f8e3745d5.

The Commit job used v3.10.8 and gathered complete comparison evidence for 157 required paths in 16 parts. It then captured 300 human and 60 operational lines and rejected 108 required-or-uncertain lines against 32, at L136. Copilot Verification retained previous progress. Independent CI passed on that head.

The issue contains an ordinary fenced companion proposal. Its publication card records a companion without a selected-seed receipt. Preserve that human scope and verify any published SDD authority before reconciliation. The hosted count measures classified lines. Use a separate deterministic fixture with at least 33 genuinely distinct obligations to demonstrate capacity.

Expected impact

Acceptance

1. Replay the pinned Domus case through Commit with deterministic responses and the full scope and comparison inventory. Assert that every requirement has exactly one accepted result with its source reference and evidence tied to the evaluated head. Record the legacy rejection and the candidate result separately.
2. A fixture with 33 or more distinct requirements completes in multiple bounded batches. Reordering and retry preserve IDs, evidence links and one aggregate result. Keep ordinary one-batch and 🐛🧑‍💻 - Progress verification counts the published SDD seed against the scope clause limit #910 approved-seed controls.
3. Missing or wrong-SHA evidence, a missing/foreign/conflicting ID or batch, changed issue/SDD/PR/base/head, an incomplete aggregate or exhausted budget preserve previous progress. Assert zero publication attempts for these cases. Test duplicate delivery and stale concurrent attempts.
4. Show batch coverage and a safe reason when publication is withheld. Example: “Progress retained. Verified 2 of 3 batches. R-17 has no evidence for the evaluated head.” Only a complete result can reach the progress card and labels.

Budget at least 20 deterministic cases: 5 inventory/identity, 5 batching and schema, 6 evidence/freshness/publication, and 4 replay/compatibility/diagnostics. Update the progress scope and capacity SDDs, their catalog evidence, and the Commit troubleshooting docs. Validate the repository contracts and coverage on the final implementation SHA.

Alternatives considered

No response

Version of copilot

v3.10.8 (8246440)

Additional context or comments

Consolidation candidates — 2026-11-07

Reviewed 37 open PR heads in vypdev and inspected 32 failing Commit jobs. Domus #23 / PR #29 is the confirmed live scope-clause-limit reproducer in that survey.

• 🐛 - Progress assessment rejects R1 remaining with requirement remaining invalid #887 is an adjacent assessment-response case. Add an invalid remaining response as a batch-contract regression. Consolidate its diagnostics or recovery only if the same failing contract is reproduced. Its original consumer ha-ui PR #10 is merged.
• 🐛 - Commit progress still fails above 300 files when the owning PR inventory is complete #903 and ✨ - Support added screenshot evidence in progress assessments or report exact unsupported binary paths #760 are separate evidence acquisition and media cases. Keep their completeness guarantees as controls. 🐛 - Bugbot completes all analysis but fails freshness with opaque provider.unavailable diagnostics #870 concerns Bugbot freshness, a separate review phase.
• Closed 🐛🧑‍💻 - Progress scope assessment rejects an API requirement with scope clause limit in generated issue plan metadata #828 and 🐛🧑‍💻 - Progress verification counts the published SDD seed against the scope clause limit #910 / fix: Progress verification counts the published SDD seed against the scope clause limit (#910) #915 are regressions for operational-state separation and verified published-seed reconciliation. The owning scope SDD and capacity SDD define the current boundary.

Commit scope batches and same-head evidence

• Status — Draft awaiting maintainer selection
• Date — 2026-11-07
• Capability — github-communication-experience
• Owners — Copilot maintainers
• Scope — Complete bounded acceptance assessment and atomic eligibility for progress publication
• Related work — ✨🧑‍💻 - Evaluate Commit acceptance scope in bounded batches with stable requirement IDs #916 and feat: add the household task workspace (#23) domus#29
• Review gates — architecture, test coverage, documentation, GitHub UX and security
• Open product decisions — none proposed. Maintainer selection is required before Action publication.

1. Executive summary

Commit evaluates complete acceptance scope in bounded batches. Every required or uncertain obligation has one validated outcome with traceable evidence from the same immutable evaluated head. Only a complete, current aggregate becomes eligible for the existing progress publication flow. Previous progress remains visible during assessment and after any completeness failure.

Capture source → freeze inventory → classify bounded parts → collect comparison receipts → assess bounded requirement groups → validate every same-head outcome → recheck authority and refs → publish one aggregate

2. Problem, current behavior, and evidence

The pinned Domus issue body has SHA-256 f5c01613456235e349179026a023ad992b3d95fc427568f27c8f7e31fbf8b2d0. Base is 5b7bdcdee3a9e98d6669bfd34ce750ae30a8c775 and head is 2a35e2a3bcfe98b58ddf184b6e781a1f8e3745d5. Release v3.10.8 at 8246440d6d9158f6d6b75231b081e612ed76a789 recovered 157 paths in 16 comparison parts, captured 300 human and 60 operational lines, and rejected the historical classification of 108 required-or-uncertain lines against 32 at L136. The classified count does not establish semantic uniqueness.

The released capture and full Commit rejection can be replayed without a model, using the original public comparison, immutable Git objects and an explicitly identified deterministic classification fixture. Independent consumer CI passed on that head. Domus subsequently advanced to c64c6a75a0731b16d4b376d981acf90753f44310 and again hit the same capacity boundary with 129 classified lines. Keep this later observation separate from the pinned replay.

Existing scope, comparison recovery, response validation and freshness logic live in src/application/usecases/actions/progress_analysis_workflow.ts, src/application/usecases/actions/check_progress_workflow.ts and src/application/policies/progress_scope_policy.ts. This prospective contract extends that behavior. Historical motivations beyond the documented finite response envelopes remain unverified.

3. Actors, surfaces, and terminology

Maintainers inspect the issue, PR, progress card, Check and Job Summary. Commit owns an invocation-local attempt. The host owns source spans, requirement IDs, assignment, budgets and publication eligibility. The model supplies classified observations and requirement outcomes through strict schemas. An evidence receipt is a validated reference to admitted immutable comparison content, with its evaluated head and source identity. A missing implementation is an assessable outcome when cited evidence supports that finding. A missing evidence receipt leaves assessment incomplete.

4. Goals, non-goals, and fixed invariants

Implementation acceptance excludes merge or release authorization. Independent CI and review retain their existing roles. Configuration cannot weaken same-head evidence, completeness or freshness checks.

5. Current versus proposed product journey

flowchart LR
  A[Capture frozen source] --> B[Classify every span]
  B --> C[Validate comparison receipts]
  C --> D[Assess bounded groups]
  D --> E[Validate complete same-head inventory]
  E --> F[Recheck authority and refs]
  F --> G[Publish aggregate]

The sequence captures all source, validates all evidence, assesses every obligation, verifies completeness and freshness, and then permits one aggregate publication.

6. Functional behavior and state model

The application freezes repository identity, full issue body digest, PR ownership, base and evaluated head before querying the agent. It uses the existing configuration exclusion and verified draft publication policies. Stable IDs identify original physical source spans within that frozen source, including the canonical selected SDD obligation and retained aliases. Classification order cannot allocate IDs.

Classification assigns every host span once. Required and uncertain entries remain obligations. Exclusions and context retain their ownership. The complete manifest retains source quotes, qualifiers, case provenance and publication authority. Assignment plans contain at most 32 obligations per assessment request. Source classification may use different bounded groups without renumbering obligations.

Comparison facts retain their native source or unit identities and pinned head. Requirement outcomes cite admitted evidence receipts. Supported outcomes require implementation evidence from regular source content. Generated metadata alone cannot establish implementation or test execution. Missing or uncertain outcomes require a traceable observation or complete-inventory absence justification bound to the evaluated head. A model echoing the requested SHA without an admitted evidence reference is insufficient.

The host rejects missing IDs, foreign assignments, incompatible duplicates, missing source coverage and unverified references. Compatible duplicate delivery is idempotent. Aggregate order follows the frozen manifest. Preserve ordinary one-batch assessment behavior, including existing progress scoring and completion validation. For multiple batches, aggregate each validated batch percentage weighted by its obligation count, while requiring all obligations and preserving the completion invariant. Batch order and duplicate delivery cannot change that aggregate. Different batch sizes preserve source and evidence identities.

Cancellation discards invocation-local partial receipts. A later attempt reconstructs the complete frozen inventory. No partial state is promoted to a percentage.

7. User-facing configuration

No new Action input, secret, permission, repository switch or operator-selected ref is introduced. Existing agent and locale settings keep their documented precedence and validation. The protocol snapshots its fixed profile per attempt.

These are proposed fixed ceilings. Implementation records measured Domus usage and tests every boundary. Byte and deadline accounting includes retries. An exhausted bound retains prior progress. Operators use the default bounded flow. A larger legitimate scope requires a reviewed future profile. Unchanged incomplete attempts cannot opt out of evidence validation.

8. Clean Architecture design

Pure policies own manifest identities, assignment, receipt validation, capacity accounting and deterministic reduction. Application workflows orchestrate existing issue, comparison, agent and publication ports. Provider adapters retain immutable content recovery and native PR ownership. Composition binds repository identity and capabilities. Existing entrypoints continue to invoke Commit and CheckProgress. Presentation renders safe counts, compact source references and recovery actions separately from mutation decisions.

flowchart LR
  C[Commit entrypoint] --> A[Progress application workflow]
  A --> P[Pure manifest and receipt policies]
  A --> R[Semantic read ports]
  G[GitHub adapters] --> R
  A --> V[Existing semantic publication boundary]

The entrypoint delegates orchestration to the application, which uses pure decisions and semantic ports, then exposes a validated aggregate to presentation. Domain and application code cannot import concrete GitHub SDKs or subprocess execution. Repository architecture checks, TypeScript and deterministic application tests enforce these boundaries. Receipts are invocation-local. Existing semantic publication identity and freshness fences own durable convergence. A stale competing attempt cannot acquire publication eligibility from another attempt's receipts.

9. UI/UX and content contract

The primary view states retained or verified progress first, then the next action and links. Batch counts remain supplemental diagnostic state. During processing show “Checking all acceptance requirements. Previous progress remains available.” A retained example is “Progress retained. Verified 2 of 3 batches. R17 has no evidence for the evaluated head. Inspect this run and retry after resolving the missing evidence.” A completed example is “Acceptance assessment completed for this head. Verified all 4 batches and 108 requirement outcomes.” These are representative fixture counts, not claims about the pinned historical classification.

After a partial provider write, report the completed operation and the failed synchronization separately. Reconcile the same semantic publication instead of claiming rollback of a successful label write. Keep one existing progress card, with no comment per batch. Existing locale resolution supports English and Spanish with the existing fallback. Use textual state labels, descriptive run and comparison links, readable narrow layouts and plain text diagnostics. Source prose, mentions, Markdown markers, commands and URLs remain untrusted and pass existing publication sanitization.

10. Failure, recovery, and cleanup

Temporary source and receipts expire with the attempt. Cleanup preserves source changes and necessary verification evidence. No model output, partial percentage or unverified snapshot is durable progress authority.

11. Security, permissions, and privacy

Keep existing least-privilege read and progress mutation ports. Agent requests remain read-only and operate exclusively on supplied immutable evidence. Bind receipts to repository, issue and PR identities to reject cross-repository replay. Validate evidence references against the host inventory, not model claims. No workspace inspection, arbitrary URL fetch, secret logging or provider output dumping is introduced. Diagnostics contain bounded host-owned IDs and counts. Forged provenance, stale deliveries and prompt injection cannot grant publication authority.

12. Observability and operational UX

Checks and the Job Summary identify phase, verified and expected batches, requirement coverage, evaluated head, failing assignment and safe missing IDs. The run and native comparison provide navigation. Log resource usage and the aggregate publication identity without raw model responses. Waiting for evidence retains existing progress and has no partial percentage. Preserve genuine authentication, rate-limit and transport errors. The 120-call attempt budget covers retries and existing one-repair categories. No notifications are emitted for individual batches.

13. Compatibility, migration, rollout, and rollback

Ordinary one-batch behavior retains its normal entrypoints, percentage interpretation, native evidence recovery, locale and completion rules, with the same-head receipt validation added at publication eligibility. Preserve #828 operational configuration separation and #910 selected published draft authority. Legacy persisted progress remains visible until a complete fresh assessment succeeds. No issue configuration schema migration is needed because receipts are invocation-local. Roll out through the reviewed PR and existing maintainer release process. Rollback restores the previous evaluator and its finite limits while preserving existing progress cards and labels.

14. Testing strategy and numeric budget

At least 20 distinct deterministic cases are required. Parameterized variants count only for different observable behavior. Existing repository thresholds remain in force and all added pure-policy branches require coverage. The changed patch targets full coverage. Use frozen clocks, immutable IDs and agent fakes. CI does not depend on live GitHub or model calls. Inspect representative English and Spanish retained and completed views manually and record that review.

15. Documentation and discoverability

Update the owning scope and capacity SDDs with the new contract and evidence. Update Commit behavior and troubleshooting with the normal batch journey, fixed profile, same-head gate, complete retry behavior and safe diagnostics. Existing setup and credential requirements remain applicable. Explain rollback and one-batch compatibility. Validate links, specifications, generated catalog and build artifacts with the repository tooling.

16. Acceptance scenarios

Given the pinned Domus body and complete comparison, deterministic Commit replay records the legacy failure separately and allows the candidate to proceed only with an accepted outcome and same-head evidence for every manifest obligation. Given 33 distinct obligations, multiple bounded assignments preserve their IDs and reduce to one validated result. Given absent or foreign evidence, incompatible duplicates, changed authority, stale refs or an exhausted budget, no progress publication is attempted. Given supported ordinary one-batch or selected published-seed input, existing entrypoints and complete freshness controls remain supported. Given a failed larger attempt, the prior percentage remains visible and safe diagnostics explain its incomplete coverage.

17. Requirements traceability

18. Implementation sequence

After maintainer selection and verified Action publication, implement pure manifest, assignment and receipt policies with deterministic tests. Integrate bounded orchestration and publication eligibility through existing application ports. Add Commit replay and race coverage. Update presentation, English and Spanish diagnostics, documentation, owning SDDs and catalog evidence. Run applicable architecture, type, specification, test, build and coverage validations. Run graphify update . and verify the final PR head and review checks.

19. Definition of Done

Every requirement has linked acceptance and test evidence. All 20 minimum cases, repository checks, changed-patch coverage and architecture constraints pass on the final implementation SHA. Domus legacy and candidate results remain distinguishable and every accepted outcome cites that candidate's evaluated head. Same-head, complete-aggregate, source authority and resource boundaries hold through Commit. Documentation, catalog and generated artifacts are synchronized. English and Spanish primary views receive human-readable review. The PR links #916 and the final SHA evidence. Maintainer review controls merge and release.

20. References and decisions

Primary evidence is https://github.com/vypdev/domus/actions/runs/42326869987/job/128264082043 and https://github.com/vypdev/domus/runs/128264839973. Independent CI is https://github.com/vypdev/domus/actions/runs/42326875268/job/128267393049. The implementation contract uses the existing capability and a new companion document because automated updates require canonical owner headings. Existing source ownership, immutable comparison, capacity diagnostics and selected-seed contracts remain applicable. The fixed batching profile is an engineering proposal for maintainer selection, with measured usage to be recorded during implementation.