The Open-Source Infrastructure Foundation

Confirm the supplied behavioral contract, original source license, and narrow repair scope. State that the current reference is deliberately not release-ready and that no public release is authorized by this seed.

Inputs: starter/docs/charter.md, starter/docs/contract.md, starter/LICENSE.txt, starter/docs/issue-register.csv

Outputs: deliverables/repair-scope.md

Depends on: No prerequisites

• The scope names ll-duplicate and ll-order as unresolved starter defects.
• No third-party code, credentials, live project data, or runtime authority is required.
• A strict all-pass release gate is specified.

Run the authored baseline tests, the characterization mode, and the strict checker on the supplied inert fixtures. Record expected and actual counts and item states. A zero characterization exit is not a release pass.

Inputs: deliverables/repair-scope.md, starter/reference/line_ledger.py, starter/reference/test_baseline.py, starter/reference/check_acceptance.py, starter/data/events-clean.jsonl, starter/data/events-duplicate.jsonl, starter/data/events-out-of-order.jsonl, starter/data/expected-contract.json, starter/docs/issue-register.csv

Outputs: deliverables/reproduced-issues.json

Depends on: maintainer-scope

• Strict checking passes the clean case and fails exactly the duplicate and out-of-order cases.
• Characterization mode is labeled known-failure reproduction, not success of the desired behavior.
• The report includes exact commands and no host-affecting fixture execution.

Review the original reducer and documented input limits. Check that fixtures are data, not commands, and that any proposed fixes preserve rejection of conflicting IDs, invalid actions, oversized input, and invalid minute values. Produce defensive findings only; no hostile host tests.

Inputs: deliverables/repair-scope.md, starter/docs/security-boundary.md, starter/reference/line_ledger.py, starter/reference/test_baseline.py, starter/docs/contract.md

Outputs: deliverables/input-boundary-review.md

Depends on: maintainer-scope

• File reads are explicitly selected and bounded; no network, execution, write, or identity capability is introduced.
• The review distinguishes logic defects from claims of an exploitable vulnerability.
• Any remaining boundary concern has a concrete proposed regression case using inert in-memory data.

Create a reviewable patch that counts each identical event ID once while retaining rejection of conflicting payloads. Add or update regression tests; do not weaken expected-contract.json to make the defect disappear.

Inputs: deliverables/reproduced-issues.json, deliverables/input-boundary-review.md, starter/reference/line_ledger.py, starter/reference/test_baseline.py, starter/data/events-duplicate.jsonl, starter/data/expected-contract.json, starter/docs/contribution-guide.md

Outputs: deliverables/deduplication.patch

Depends on: issue-reproduction, input-boundary-review

• The duplicate fixture's event_count becomes 3 and item-a event_count becomes 2.
• Conflicting duplicate payloads remain rejected.
• Expected desired results are unchanged and the second defect remains visible until separately repaired.

Build on the deduplication patch and normalize event order by at_minute then event_id before reduction. Add a same-minute tie case and retain deterministic item ordering. Do not claim the patch was merged or released.

Inputs: deliverables/deduplication.patch, deliverables/reproduced-issues.json, starter/reference/line_ledger.py, starter/data/events-out-of-order.jsonl, starter/data/expected-contract.json, starter/docs/contract.md

Outputs: deliverables/ordering.patch

Depends on: deduplication-repair

• The out-of-order fixture ends item-a closed with last_minute 20.
• Equal-minute events resolve by event_id rather than input order.
• The patch preserves original inputs and the deduplication fix.

Use observed reproduction evidence to explain the project, safe fixture commands, two failure modes, and the difference between characterization and strict acceptance. Keep the documentation useful before fixes exist.

Inputs: deliverables/reproduced-issues.json, starter/docs/contribution-guide.md, starter/docs/contract.md, starter/README.md

Outputs: deliverables/contributor-quickstart.md

Depends on: issue-reproduction

• A contributor can reproduce both defects without installing packages or starting a server.
• Expected nonzero strict-check exit is explicit.
• Documentation does not describe pending repairs as completed.

Apply reviewed patches only to the consumer's explicitly selected candidate copy, then run strict acceptance and regression tests. Record actual evidence or a blocker; the seed reference itself remains the historical failing baseline.

Inputs: deliverables/deduplication.patch, deliverables/ordering.patch, deliverables/input-boundary-review.md, starter/reference/check_acceptance.py, starter/data/expected-contract.json, starter/reference/test_baseline.py, starter/docs/release-checklist.md

Outputs: deliverables/candidate-acceptance.json

Depends on: ordering-repair, input-boundary-review

• Strict checker exit 0 and every desired contract case are required for pass.
• Regression expectations are updated to fixed behavior without weakening contract targets.
• No missing candidate, failed test, or unperformed check is represented as release-ready.

Draft a lightweight issue intake using the supplied synthetic examples. Ask for a minimal inert fixture, command, expected result, and actual result; discourage credentials, private logs, and host-affecting reproduction steps.

Inputs: deliverables/repair-scope.md, starter/docs/community-intake.md, starter/docs/security-boundary.md

Outputs: deliverables/community-issue-form.md

Depends on: maintainer-scope

• The form can describe both current defects using only public synthetic data.
• It requests no credential, private repository, contact list, or personal record.
• No issue, invitation, or community membership is actually created.

Review the candidate acceptance, contributor quickstart, and scope. Confirm the repairs are limited, the boundary is preserved, and unresolved limitations are visible. Produce a decision proposal rather than a forged approval.

Inputs: deliverables/candidate-acceptance.json, deliverables/contributor-quickstart.md, deliverables/repair-scope.md, deliverables/input-boundary-review.md, starter/docs/contract.md

Outputs: deliverables/maintainer-review.md

Depends on: candidate-acceptance, contributor-quickstart

• The review references observed strict acceptance and regression evidence.
• Only actual repairs may be described as implemented in the candidate.
• Publication and signing remain separate owner-authorized operations.

Draft notes that explain desired fixed behavior, compatibility, remaining limits, and actual candidate evidence. If the maintainer recommendation is blocked, say so and retain draft status.

Inputs: deliverables/maintainer-review.md, deliverables/candidate-acceptance.json, deliverables/contributor-quickstart.md, starter/docs/release-checklist.md

Outputs: deliverables/release-notes-draft.md

Depends on: maintainer-review

• Notes distinguish the failing source baseline from any tested candidate.
• No tag, package upload, signature, download count, or released version is invented.
• Event ordering, duplicate semantics, and remaining limitations are described accurately.

Prepare an inert release plan with candidate hashes, proposed version, exact artifacts, checks, publication destination to be selected by an owner, and withdrawal steps. Do not publish, tag, sign, or mint identities.

Inputs: deliverables/release-notes-draft.md, deliverables/maintainer-review.md, deliverables/candidate-acceptance.json, starter/docs/release-checklist.md, starter/LICENSE.txt

Outputs: deliverables/publication-plan.json

Depends on: release-notes-draft

• A failing or unreviewed candidate blocks publication.
• Every external operation remains a separate explicit approval boundary.
• Hashes identify public candidate files only and are not represented as signatures.

Prepare a concise announcement tied to the publication plan, explaining the original reference project and how to reproduce its behavior. Keep it a draft until actual authorized release evidence exists.

Inputs: deliverables/publication-plan.json, deliverables/community-issue-form.md, deliverables/release-notes-draft.md, starter/docs/community-intake.md

Outputs: deliverables/community-announcement-draft.md

Depends on: release-plan, community-intake

• No contributors, adoption statistics, downloads, customers, or completed release are fabricated.
• The announcement gives safe local reproduction guidance.
• No external message or membership operation is performed.