20 lines
3.7 KiB
JSON
20 lines
3.7 KiB
JSON
{
|
||
"task_id": "MP-01-r02",
|
||
"commit": "6b78f8fd71131e61ba695939f4629fec9f51d7a9",
|
||
"status": "pass",
|
||
"summary": "I checked acceptance item MP-01-r02 (P06-01) against the spec, the diff, the target sources and the Runner results. All requirements are met, so the status is pass.\n\nScope:\n- Only the two files inside allowed_paths were changed: PROPOSAL.md and proposal.json.\n- No product source, original spec, ledger, Runner config or test files were touched.\n- No tests were deleted or disabled.\n- The Runner reports product_changed=false and original_completed_units_added=0.\n\nSpec checks:\n1. proposal.json has status=proposed_unapproved and applied_to_product=false. All 8 required top-level keys are present.\n2. recommended has all 4 numeric fields (100/300/20/10) as integers, with initial amount ≤ capacity.\n3. The furnace candidate states input and output (1 eligible generic slave → 100 Mana), eligibility, timing, atomicity, history and interruption handling. It sets actual_actor_consumption=false. It keeps the original constraints (6×3, back underground, slave consumption) and excludes irreplaceable, unsellable and unique people.\n4. demand_catalog lists all 37 definitions with the 3 required fields. I re-added the values myself: one of each definition totals 63, and the normal mix totals 16. The 4 facilities that omit maintenance_mana are recorded as 0 based on the FacilityDefinition default. The 13 original facilities with no definition are kept as unknown, not treated as 0.\n5. source_pins is now a repo-relative path → raw-file SHA256 dictionary. The Runner matched all 53 pins against the current files. Provenance is kept separately in source_provenance and the provenance section, which keeps original, current implementation, fixture and candidate values distinct.\n6. Each of these is described separately with its basis: initial mana=100 as a stock amount vs. STARTER_MANA_OUTPUT=100 as network supply capacity, the current use of maintenance_mana, and the fact that the conversion is only a proposal.\n7. There are 21 comparison series covering low load, normal, demand excess, zero stock, capacity limit, supply loss and return, and same-boundary resend. The Runner independently recomputed all 126 rows. My spot checks also matched: recommended excess 100→57→14→0 with shortage 29; generous case at 16 after interval 8 and first zero at interval 9; overflow 16/18/38. Both furnace headroom policies also matched (96/100/0 and 80/84/0).\n8. D05 is marked as unapproved, with a recommended order inside the MANA phase. A legacy 0 is kept as 0 (stopped) and is never silently converted to full or unlimited. Open decisions and their approval scope are listed.\n9. PROPOSAL.md states at the top that the proposal is unapproved and not applied to the product. It claims neither completion of the original 88 deliveries nor acceptance of P06-01. The proposal-consistency check passed (exit 0).\n\nThe only problems are leftover metadata, listed as low findings.",
|
||
"acceptance_ids": [
|
||
"MP-01-r02"
|
||
],
|
||
"findings": [
|
||
{
|
||
"severity": "low",
|
||
"message": "Leftover metadata in proposal.json: id is still \"MP-01\" and base_commit still points to an older commit (0bdc4886…) instead of this contract's base (5536bc04…). The r02 traceability would be clearer if these were updated. The values and source pins match the current files, so this does not affect substance."
|
||
},
|
||
{
|
||
"severity": "low",
|
||
"message": "source_pins points to the old spec docs/spec/acceptance/P06-mana-proposal.json and does not include the spec that governs this round (P06-mana-proposal-r02.json). Adding the governing spec would make traceability easier. This does not affect acceptance."
|
||
}
|
||
]
|
||
}
|