Skip to content

fix(people): revalidate confirmed-hire evidence at application and PostgreSQL entry boundaries #228

Description

@seonghobae

Finding

Canonical #64 hardens generic People mutation commands/results after construction, but confirmed-hire retained a symmetric consumer-boundary gap. HireAcceptanceCommand and HireAcceptanceResult are frozen dataclasses and can still be rewritten through object.__setattr__ after constructor validation.

At predecessor 8c40a184acab06732ba88234910876247f215ceb, accept_confirmed_hire(...) exact-gated the outer command type but did not rerun the exact class invariant before rendering selection_decision_id.hex for authorization. It also exact-gated the returned HireAcceptanceResult but returned it without rerunning the result invariant. PostgresHireAcceptancePort.accept_hire(...) likewise exact-gated the command but called _validate_authorization(...) before revalidation; _validate_authorization(...) renders the selection-decision UUID before it checks the authorization object.

A post-construction rewrite could therefore execute caller-defined UUID behavior before the governed hire invariant, or let a rewritten exact result cross the application boundary. This is an Orgmetra People consumer-boundary defect and does not copy mutable #65 authorization source.

Causal repair

  • Test-first 1ab0bd0dc22d73293d1472946b00fe8f98d08d25 adds three regressions: application command rewrite, exact result rewrite, and direct PostgreSQL command rewrite. The command tripwire raises if .hex is touched before exact constructor revalidation, and the direct durable test forbids DB acquisition.
  • Application production 0a394553c21df407ae4bafe8fee568c70d5e8e62 reruns HireAcceptanceCommand.__post_init__ immediately after the exact outer-type gate and HireAcceptanceResult.__post_init__ immediately before return.
  • Durable production bf24c2e43f75e6e9438b228abb959157b4f7a589 reruns HireAcceptanceCommand.__post_init__ immediately after the direct PostgreSQL outer-type gate and before _validate_authorization(...) can render resource identity.
  • Compare evidence from 1ab0bd0… → bf24c2e… is two production files with only +3/-0; SQL, schema, transaction, HR domain semantics, Keyverse policy, audit/idempotency behavior, and owner boundaries are unchanged.

Current acceptance state

Exact current #64 head is bf24c2e43f75e6e9438b228abb959157b4f7a589 over protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f. Foundation CI 33934946495 / Repository quality 101220929871 is queued before checkout with steps=[], labels:["ubuntu-24.04"], and no runner. SAST 33934946504, Security Scan 33934946478, and CodeQL PR 33934946474 are also queued. Hosted RED/GREEN, PostgreSQL acceptance, repository-wide 100% statement/branch coverage, and current-head security completion are not claimed.

Fresh CodeRabbit review was explicitly requested for exact bf24c2e…; predecessor review evidence is not transferred. Keep this issue open until exact-head hosted/review acceptance is available and #64 can progress through normal protected-branch gates.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions