36 lines
5.3 KiB
JSON
36 lines
5.3 KiB
JSON
{
|
|
"task_id": "P18-01-CODE",
|
|
"commit": "0084760ee05a97adfcbd783a71161491f3629918",
|
|
"status": "changes_requested",
|
|
"summary": "I compared all four acceptance criteria against the spec, the full diff, the target sources, the identity catalog, the Runner p18-model result (exit 0) and the coordinator's native evidence (7 suites, 843 checks, 308 parse, 9 distinct PIDs, no guard or cleanup errors). I did not edit or run anything. Every change is inside allowed_paths. No existing test was deleted, disabled or weakened. Two new marker rows and two new suite-policy rows were added, pinned to the source hashes.\n\nP18-C-1 is met. The original relationship state is separate from the legacy one, with explicit directional subject/protagonist/rival identities. It requires all fields, rejects non-finite values, and enforces shield_max == affection. An unset record reads as configured:false with null values, distinct from an explicit zero. No production values or coefficients are introduced.\n\nP18-C-2 and P18-C-3 are mostly implemented: v2 nests the full v1 record, restore is atomic, the Runtime command and restore/rebind are real, and the report projection is read-only. But three things are unproven or change legacy behavior:\n(1) The merge-back of legacy aliases is not tested for changes to the aliased axes (affection/dependence).\n(2) Restore now rejects legacy saves it used to accept, through stricter type checks and a new actor-reference check.\n(3) Original records have no lifecycle once the subject leaves staff, which could make saves unloadable.\n\nP18-C-4: native local and affected evidence exists. Integration and the final affected validation have not happened yet, and the backend task correctly does not claim the P18-01 unit complete. Because of the verification gaps above, I am not passing it.",
|
|
"acceptance_ids": [
|
|
"P18-C-1"
|
|
],
|
|
"findings": [
|
|
{
|
|
"severity": "high",
|
|
"message": "Possible silent loss of affection/dependence changes on legacy saves (P18-C-2, P18-C-3), not verified. RelationshipService._merge_legacy_changes copies the original raw entry and writes only the fields that changed into it, so old aliases like metrics.affinity=117 stay next to a newly changed canonical metrics.affection. If RelationshipState.from_snapshot lets the alias win over the canonical key, a change to affection or dependence after loading a legacy save would be lost on the next save/load. The test only changes trust ('changed metric preserves raw alias'), and RelationshipState.from_snapshot precedence is not shown in the review packet. Needed: a test that changes affection and dependence on an alias-bearing legacy record, then saves and restores through both the service and the Runtime, and confirms the value persists (or the alias is resolved some other way)."
|
|
},
|
|
{
|
|
"severity": "medium",
|
|
"message": "Legacy behavior changed beyond the spec (P18-C-2 says v1 relationships 'remain usable'; P18-C-3 requires 'legacy unchanged behavior'). Two new checks reject v1 data that loaded before: _legacy_types_valid requires strict int/String/Dictionary types for metrics, shield, day counters, flags, route_lock and so on, and _restore_snapshot_internal now requires every relationship actor to be player, a restored staff member or a restored guest. Legacy relationships pointing at departed or persistent-record guests, non-staff unique characters, or numbers stored as floats would now fail to load. There is no evidence this was checked against the retained P02-01/P02-02 representative saves. Needed: evidence or tests that those saves still load, or restrict the new rejections to the original payload."
|
|
},
|
|
{
|
|
"severity": "medium",
|
|
"message": "Original records have no lifecycle once the subject stops being staff. _original_relationship_identities_valid requires the subject to still be hired UNIQUE staff. It is checked on restore (using restored_staff) and in validate_invariants. If any existing path removes or replaces the heroine's staff record after registration, the Runtime would fail its invariants and that save could no longer be restored. Needed: either show that no such path exists for UNIQUE heroines, or define and test what happens (keep the record without the staff check, or reject the removal)."
|
|
},
|
|
{
|
|
"severity": "low",
|
|
"message": "During restore, the identity validator reads the live mvp_content_catalog instead of restored_catalog, which _restore_snapshot_internal builds and installs later. The content is identical today, but the candidate validation is not fully self-contained. Suggest passing restored_catalog into _original_relationship_identities_valid."
|
|
},
|
|
{
|
|
"severity": "low",
|
|
"message": "Runtime-level negative tests are thin. test_original_relationship_runtime covers corrupt original fields, but not a duplicate original subject, an unknown or mistyped relationships.version, a mismatch between the top-level relationships projection and legacy.relationships, or a non-heroine UNIQUE subject at the Runtime level. These are covered at the service level only."
|
|
},
|
|
{
|
|
"severity": "low",
|
|
"message": "P18-C-4 process items are still pending: integration and the final affected validation come after this review. The native evidence (843 checks, 308 parse, PIDs and cleanup recorded) and the Runner verify-only pass are present. Correctly, nothing claims P18-01 unit completion."
|
|
}
|
|
]
|
|
}
|