Add explicit non-heuristic primary/secondary (TFT) tag to assignment_record

[seonghobae]

Buyer-visible gap

Orgmetra must record a worker’s primary operational Assignment separately from simultaneous secondary/auxiliary Assignments without inference from allocation, row order, Position identity, hierarchy, or UI ordering. PR #163 remains canonical at 5d4133b29f19a8db92bda0e03ba3ae1470aae594; new facts use explicit primary | concurrent_secondary, while legacy_unspecified is historical/restoration provenance only.

Protected develop is eb9757f8649aaad026a9865508d9aad50c1a7a4f; #163 remains a preserved Draft/non-mergeable repair lane against predecessor truth.

Current protected-owner chain is #63 72070cb4b8d636825ce5b1a326df4c296596ed7e → #64 8f986853a6f234c317e29080c4982bab34f3dc51 → #65 1caf8f760e81f1cb6954fdf1d0d13a46dbb6c0b1 → #141 8d12ee7cd05549a69c6debf5e0de0c5fc8668f33 → #163.

#63 exact Foundation CI is now terminal success after the predecessor 218-test/99.43%-coverage RED was repaired; remaining gates still govern integration. #64 retains #229–#232 runtime-integrity work and #233, which now aligns Assignment allocation (0, 1.0000] across parser, published OpenAPI, regression tests and deterministic manifest evidence. #64 source repair is complete on its mutable head but exact hosted/security/review evidence is non-terminal. #65 must then non-force adopt protected #64 while preserving its purpose-bound validate_authorization_decision(...) flow. #141 contains a valid employing-legal-Organization feature but is Draft/non-mergeable on an old overlapping People/OpenAPI/auth base; it follows #65 and must non-force adopt protected owner truth before #163.

After those owners integrate through ordinary gates, non-force adopt resulting protected develop into #163, preserve the explicit Assignment-category delta, resolve real conflicts only, reacquire exact-head product/PostgreSQL/security/review evidence, and integrate normally. #165 remains dependent.

Keep #162 open until #163 normally integrates or a verified successor fully carries its semantic/test/contract/evidence delta. No administrator bypass, self-approval, force-push, destructive rebase, gate weakening, mutable-owner source copy, or predecessor-evidence transfer.

[seonghobae]

2026-09-02 fresh writer reconciliation: PR #163 is now at exact head 046e3fc798e69e84979676e30697e04fcd7122e2 on protected base develop@9e3e4847510e1e612b48474ba42b177b8ed824df.

A late review first tested whether legacy_unspecified should be rejected inside the generic HRIS validate_assignment_write helper. Regression-only commit 2f5c5556df37b4bc463c27e2cdb63ce76806bb4c was not promoted to production after repository evidence showed that helper also validates legitimate pre-contract historical assignment fixtures; authoritative new-write rejection already exists in AssignmentMutationCommand, HTTP parsing and PostgreSQL. 8ccb1125f88573586d35517e0018ade66c6914eb removes that false-positive regression non-destructively.

The same review found a real deterministic test-contract gap: the canonical assignment_command() fixture in services/people-api/tests/test_people_mutations.py still omitted the newly required assignment_category_code, and downstream PostgreSQL mutation tests import that helper. 046e3fc798e69e84979676e30697e04fcd7122e2 adds explicit primary to that fixture only; no production default or heuristic classification was introduced.

Exact-head required/product workflows are still queued/pending and CodeQL PR run 33623264781 remains a central zero-job startup_failure. Reviews and inline threads remain absent. Keep #162 open until #163 passes ordinary protected integration; do not transfer predecessor evidence or use administrator bypass.

[seonghobae]

PR #163 fresh manifest audit found a deterministic source RED: the sealed metadata for tests/test_assignment_category_postgres.sh lagged the current regression contract (old 6768 bytes / 92 lines versus current 8180 bytes / 113 lines and SHA-256 dbe84c56da410313820d81ee0567e2e272b9b6bb8b8cc06198e99bb1b059b56e). Because repository and recovery validation compare SHA-256, byte count, and line count, Foundation/Recovery would fail even if hosted-runner admission recovered.

The repair is now on #163 at exact head c67a54e640666ae5c947f59ca538f740e0f8a8d8; predecessor→current net delta is only the intended three manifest fields. #162 remains open until ordinary protected integration. Current-head CodeQL still has a zero-job startup_failure, and the remaining exact-head gates are queued, so this is not merge/release evidence.

[seonghobae]

Current exact-head refresh — 2026-09-02: active writer PR #163 is now c67a54e640666ae5c947f59ca538f740e0f8a8d8 on protected develop@9e3e4847510e1e612b48474ba42b177b8ed824df. The successor delta after 046e3fc798e69e84979676e30697e04fcd7122e2 is manifest-only (a7a2ae5d…, then c67a54e…), so the assignment-category domain/API/PostgreSQL contract described above is unchanged. Current-head review submissions and inline threads are empty. CodeQL PR run 33628451197 ended as a zero-job startup_failure; the remaining current-head product/Foundation/Recovery/Security/SAST/Assignment Category workflows are queued at the latest read, so none are treated as passing or transferable predecessor evidence. Keep #162 open and #163 Draft until current-head evidence is terminal and ordinary protected integration succeeds; no admin bypass or heuristic classification is authorized.

The authoritative Dependency Review root-cause lane is now ContextualWisdomLab/.github#1725: it fails closed on every non-200 exact base/head dependency-graph comparison and restores the thin caller contents: read + pull-requests: read permission envelope. That owner branch has been non-force reconciled with protected .github/main@63bf49835da44aa8257eb76a92368e6485ae6e94 at exact head ca7cb12c78d37b797399488182b6f43e0ba8b076; its new exact-head security fleet is queued/pending, so Orgmetra must wait for ordinary protected owner integration and an immutable protected-main SHA before any consumer pin/bump.

[seonghobae]

#163 exact-head update: d4cc84c0729ffdf925fca5c6b9ad437f1214ec07 now also protects the existing Employment allocation invariant under concurrent assignment writes. Regression commit 628ffd44e19ac558ef1106bf2b756f9e4664425e first corrected the stale 9-column historical assignment fixture for the new category-bearing row shape and required an Employment aggregate row lock. Repair d4cc84c0729ffdf925fca5c6b9ad437f1214ec07 adds FOR UPDATE OF employment before Position locking and portfolio reads, preventing same-Employment/different-Position writers from both validating against a stale allocation snapshot and committing total allocation above 1.0000. The issue remains open until ordinary protected integration; current exact-head hosted product/security evidence is still queued/pending and central CodeQL is startup-failed.

[seonghobae]

Correction to the immediately prior note: the suspected same-Employment concurrency race was disproved on full adapter review. _CONVERSION_SQL already holds FOR UPDATE OF conversion for the tenant/person before assignment validation, so valid writers for the same Employment are already serialized through their shared Person conversion row. The redundant Employment lock and its regression assertion were removed non-destructively in 22c93ef8530032f1bd953408184101f5a7184db3 and e23f12624b410ca17bf961d34618d0be2e6b63ed. Net a2c220a… -> e23f126… is only the real one-line fixture repair: the historical PostgreSQL assignment tuple now includes legacy_unspecified so it matches the 10-column category-bearing reconstruction contract. Issue #162 remains open pending protected integration.