gnubok_create_customer takes a personnummer (encrypted before approval)
but gnubok_update_customer did not, so an existing customer whose
personnummer sat in the org-number field could not be corrected via MCP.
The REST PATCH already supports it; this closes the MCP/pending-operations
gap across its three layers:
- tool inputSchema: personal_number (string or null) on the strict
whitelist. The tool validates the plaintext before any DB read and
mirrors the REST PATCH semantics: masked echo (********-1234 or
********-????) = leave unchanged, explicit null = clear, absent =
untouched. Setting is refused unless the row ends up as an individual
(GDPR art. 5.1 c), including via a simultaneous type change.
- CustomerChangesSchema: personal_number_encrypted (nullable, ciphertext
shape per customers_personal_number_check 20260726110000). The
plaintext key stays forbidden by .strict() and staging-pii-guard.
- update executor: maps the staged ciphertext onto customers
.personal_number (set/clear/leave), re-checks the individual-only rule
against a tampered row, and returns only personal_number_masked.
PII handling: the personnummer is encrypted at staging time
(AES-256-GCM, same path as create); pending_operations params carry only
the ciphertext and the approval preview only the masked form. Idempotency
hashing switches to the masked preview for personnummer-bearing updates
(random-IV ciphertext would break retries); other updates keep their
previous hash identity.
catalogVisibility stays 'search': tools/list is at its 59.95K token
ceiling with zero headroom (see DECISIONS.md).
Fixes#1876
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Mattsson
77cacdcf34