fix(people): reject zero assignment allocation at the published HTTP contract

[seonghobae]

Finding

Canonical People mutation owner #64 exposed a real buyer-contract split around Assignment allocation_ratio.

• AssignmentMutationCommand, HRIS-kernel assignment validation, and PostgreSQL require (0, 1.0000].
• The fix(people): require exact allocation-ratio text before Decimal parsing #232 parser and published schemas/openapi.yaml both used ^(0\.[0-9]{4}|1\.0000)$, which accepted 0.0000 even though the parser error text said 0.0001-1.0000.
• TRD requires generated server validation to enforce the OpenAPI contract before domain handlers execute, so accepting zero in generated validation and rejecting it later was not an acceptable public contract.

Test-first repair lineage

• Predecessor owner head: #64@8d3877650865f71c4d9708b06eb55f43a7cb7661.
• Test-only abd5dc506d363897d0396dc9e75b1e389b47c71f added two causal RED contracts: the scalar parser must reject 0.0000, and the published Assignment OpenAPI pattern must reject zero while accepting 0.0001, 0.2500, 0.9999, and 1.0000.
• 7a95aa95a6a9cf4497b301ffee0748555d98776e repaired the runtime parser while preserving fix(people): require exact allocation-ratio text before Decimal parsing #232 exact built-in-str validation.
• f659b652fbe307134792370ac273514f0b1830a0 repaired the published OpenAPI pattern to the same strictly-positive four-decimal contract.
• da4b628fe344372ec22421cfa010e15105ad2c50 resealed the deterministic manifest but accidentally changed one unrelated 0005_outbox_delivery_finalization.sql digest while reconstructing the manifest. That was treated as an immediate repair finding, not hidden or rewritten.
• Current ordinary successor 8f986853a6f234c317e29080c4982bab34f3dc51 restores that untouched digest. Compare from the schema-repair head f659b652… to current now shows only the intended two OpenAPI manifest fields (SHA-256 and byte count) as net manifest delta.

Independent local reconstruction of the pre-change schema reproduced its recorded manifest evidence exactly (29503 bytes, 1020 lines, SHA-256 09c1e43486779198574fe31b8bcabbd1c1f74beec7bf86245ae578061619838f). The repaired schema is 29511 bytes, 1020 lines, SHA-256 c37522504d1f6ac6410eaac833dddbf09aacc85572da38a1cf7539541833ea8e, which is the value now sealed in manifest.json.

Current state — intentionally open

Source/contract repair is complete on current #64@8f986853a6f234c317e29080c4982bab34f3dc51, but normal integration evidence is not. Exact-head Foundation 33947715482, SAST 33947715342, Security 33947715430, and CodeQL PR 33947715346 are non-terminal; Foundation Repository quality job 101256719960 is queued before checkout with steps=[] and ubuntu-24.04 runner label. Hosted GREEN, PostgreSQL completion, 100% statement/branch coverage, and qualifying approval are therefore not claimed.

Keep this issue open until the repair is normally integrated or a verified successor fully carries its tests, runtime, schema, and manifest evidence. Do not close merely because the source fix exists on a mutable PR head.

Owner order

schemas/openapi.yaml is also modified by valid feature PR #141. #141 has been lowered to Draft because it is non-mergeable on an old owner base and overlaps #64/#65 on People/API contract files. Canonical order remains #63 shared-kernel protected integration as gates allow → #64 normal integration → #65 non-force protected adoption preserving #229–#233 and authorization-decision validation → #141 non-force adoption preserving its employing-legal-Organization feature → Assignment descendants. No mutable sibling source copy, force-push, destructive rebase, or bypass.