Summary
lamb user create has no --org option. It creates the user in whatever organization the authenticated admin's session belongs to — in practice the system organization — with no indication that this happened. An admin who has just created an organization and then creates a user for it ends up with the user in the wrong place, and nothing in the output says so.
Reproduction
lamb login -s http://localhost:9099 -e admin@owi.com -p <admin-pass> # system org
lamb org create probe-x --slug probe-x --signup-enabled --signup-key k -o json
lamb user create creator@probe-x.example "Creator" <password> -t creator -o json
lamb user list --org probe-x -o json # the new user is absent
lamb user list --org lamb -o json # it is here instead
Verified on dev (2026-08-01): lamb user create --help exposes only --user-type, --enabled/--disabled, and --output.
Why it matters
Creating an organization and populating it is the ordinary bootstrap path — for a new institution, a pilot, a course, or a test fixture. Today the only way to place a user in a target organization from the command line is the signup-key flow (POST /creator/signup with secret_key), which does route correctly. That works, but it is indirect, undocumented as the required path, and requires the key to have been captured at creation time (see the related gap: the key value cannot be read back afterwards — lamb org get reports only signup_key_configured: true).
The failure is silent, which is the worst property here: the command reports success, the account exists and can log in, and the mistake only surfaces later when the user is missing from the organization roster.
Suggested fix
- Add
--org <slug|id> to lamb user create, defaulting to the admin's current organization.
- Until that exists, make the placement explicit in the command output (
created in organization: lamb) so the behaviour is at least visible.
- Document the signup-key flow as the supported way to populate a target organization, and consider a
lamb org signup-key read command so the key can be recovered.
Provenance
Found by an automated black-box agent test run (organization-bootstrap module) and verified by hand.
Summary
lamb user createhas no--orgoption. It creates the user in whatever organization the authenticated admin's session belongs to — in practice the system organization — with no indication that this happened. An admin who has just created an organization and then creates a user for it ends up with the user in the wrong place, and nothing in the output says so.Reproduction
Verified on
dev(2026-08-01):lamb user create --helpexposes only--user-type,--enabled/--disabled, and--output.Why it matters
Creating an organization and populating it is the ordinary bootstrap path — for a new institution, a pilot, a course, or a test fixture. Today the only way to place a user in a target organization from the command line is the signup-key flow (
POST /creator/signupwithsecret_key), which does route correctly. That works, but it is indirect, undocumented as the required path, and requires the key to have been captured at creation time (see the related gap: the key value cannot be read back afterwards —lamb org getreports onlysignup_key_configured: true).The failure is silent, which is the worst property here: the command reports success, the account exists and can log in, and the mistake only surfaces later when the user is missing from the organization roster.
Suggested fix
--org <slug|id>tolamb user create, defaulting to the admin's current organization.created in organization: lamb) so the behaviour is at least visible.lamb org signup-keyread command so the key can be recovered.Provenance
Found by an automated black-box agent test run (organization-bootstrap module) and verified by hand.