# Application adoption contract The foundation is designed and tested as independent software before an existing application migrates to it. No application's historical schema, roles, route names, analytics categories, or operator workflow belongs in a general package merely because it makes one migration easier. An application adopts one boundary at a time: 1. implement a narrow adapter at the application edge; 2. run the old and new decisions against the same reviewed fixtures; 3. explain intentional differences; 4. deploy without deleting the retained implementation; 5. observe a defined production soak; and 6. remove old code only after rollback and data-compatibility evidence passes. EQL Helper is intended to be the first demanding adopter, not the design template. Its private evidence, persistent bans, account data, route policy, operator exclusions, synchronization, and publishing workflow remain application-owned. Useful pressure from that migration may improve a general interface, but it may not smuggle EQL-specific policy into this module. ## Optional personal-profile editing `auth.OwnProfileRepository` supports a narrow self-service boundary independently of instance-directory authorization. Load the profile using the current session digest; derive the target from that result. Normalize one username or display name using `auth.NormalizeProfileValue`. Never decode an HTTP body directly into `auth.ProfileEdit`, which carries trusted identity and credential-check state. Require CSRF/origin validation for browser writes and rate-limit credential work. For username changes, verify the current password (supply its hash as `ExpectedPasswordHash`) or consume an exact operation-bound passkey approval; enforce any additional authentication policy your application requires. Include the session, user, value and expected profile revision in the passkey binding. The SQLite transaction rechecks session/account/revision and any verified hash, updates one field, revokes other sessions for username edits, and appends audit. Do not log the command or include secret material in its audit. Schema 11 adds `profile_revision` without changing stable identity keys. Run an explicit migration before starting an adopter with automatic migration disabled. Keep the pre-migration backup; adjacent older binaries are not approved writers for the migrated schema. Email-change enrollment/confirmation is not implemented by this interface and must not be simulated with an unverified direct update.