The seed profile carries a password flag only the web form reads

Retire inherits_admin_password from ores.iam.seed_profile: the model field, its column, everything generated from it, and the hand-written places listed below. The provisioning path consults it nowhere.

The flag reads as a provisioning rule and is not one.

• The C++ provisioning path never consults it. tenant_provisioning_service::provision() takes admin_password from its caller, and bootstrap setup passes --tenant-admin-password.
• A dataset's staff take their hash from the dataset: ores_iam_publish_accounts_from_dq_fn writes r.password_hash into the credential row. ACME's people sign in on the dataset's hash whatever the profile says, which is the whole of why ACME works today.
• The only reader is the web setup journey. journeys/state.ts sets useMyPassword: profile.inheritsAdminPassword && creatingPassword != '', and =journeys/parts.tsx renders the Use my password checkbox from it, so a profile that sets the flag offers to hand the creator's password to the new tenant's administrator. Standalone first-run holds no password, drops the offer, and asks instead.

So the flag is a journey affordance wearing a provisioning name. ACME is a test database and the dataset is the right home for its passwords, which is what makes the removal worth doing rather than implementing the flag.

Generated from the model, so a regeneration covers them: seed_profile.hpp, seed_profile_protocol.hpp, seed_profile_generator.cpp, seed_profile_entity.hpp, seed_profile_history_field_mapper.cpp, seed_profile_mapper.cpp, seed_profile_service.cpp, iam_seed_profiles_create.sql, the two generated protocol/domain TS files, seed_profile_commands.{hpp,cpp}, seed_profile_commands_tests.cpp and doc/recipes/shell/seed_profiles/seed_profile.org; then compass build --direct tangle_shell_scripts for the three .ores examples that quote the command's positional arguments.

Hand-written: projects/ores.sql/populate/iam/iam_seed_profiles_populate.sql (three rows), packages/wire-protocol/src/operations.ts (the schema and the mapping to inheritsAdminPassword), src/seed-profiles.test.ts and packages/bff/src/seed-profiles.test.ts.

The affordance itself: journeys/state.ts, state.test.ts, parts.tsx (six sites), parts.test.tsx, firstRunSteps.test.tsx, NewTenantJourney.test.tsx, newTenantSteps.tsx, and journey.details.useMyPassword in en, fr and pt.

The ER diagram (ores_schema.iam.puml and .svg) regenerates separately.

Dropping the checkbox means the embedded journey always asks for the new tenant's administrator password, where a profile that inherits it could offer to reuse the creator's. Keeping that offer without the flag needs another source for it. Decide this before starting: it is a change to a journey, not a column drop.

The setup journeys are brave hopper's area. Its recent commits there are Do not ask a browser that holds the session to sign in and Take a bootstrap answer as it stands while the rail is open, so state.ts, parts.tsx and newTenantSteps.tsx are likely to move under this. Land it after that work, or tell brave hopper to expect the conflict.

• The model field: projects/ores.iam/modeling/ores.iam.seed_profile.org
• Its only reader: projects/ores.web/packages/web/src/journeys/state.ts and parts.tsx
• Where the administrator's password really comes from: projects/ores.iam/core/include/ores.iam.core/service/tenant_provisioning_service.hpp, projects/ores.shell/scripts/library/provisioning/
• Where staff passwords really come from: projects/ores.sql/create/iam/iam_publish_from_dq_create.sql, projects/ores.seeder/datasets/acme_corporation/
• The journeys that carry the affordance: doc/knowledge/journeys/setup/journey_new_tenant.org and journey_first_run.org

• The seed profiles themselves: projects/ores.sql/populate/iam/iam_seed_profiles_populate.sql
• The ACME accounts dataset, whose one hash is the password every one of its people signs in with: projects/ores.seeder/datasets/acme_corporation/accounts.json