Enable development owner login, Studio access, and management API token issuance

[alexeygrigorev]

Outcome

On https://web.dtcdev.click, the owner can authenticate with one development-only local owner identity, use Django admin at /admin/ and the distinct custom Studio at /studio/, and issue a scoped, expiring, revocable Bearer token for a development automation service principal. Runtime Studio and /api/v1/admin/ expose credential list/create/rotate/revoke through the existing hashed APICredential services. The first automation token can call the implemented /api/v1/admin/health; the UI and API do not claim unavailable domain actions.

This is a rapid development vertical slice. It does not weaken or decide the production OIDC, MFA, break-glass, or final high-risk policy owned by #20/#28/#32/#33/#61.

Authority and current facts

• _docs/specs/06-studio-and-admin-api.md: distinct management adapters, explicit permissions, Bearer tokens, one-time secrets, lifecycle, parity, audit, and private caching.
• _docs/specs/07-security-privacy-operations.md: protected staff/session/API credentials, CSRF, redaction, and deny-by-default authorization.
• _docs/specs/10-verification-strategy.md: staff denial and API-token one-time-display browser coverage.
• Exact reviewed baseline: 872fd8a9145a0e29de8890e9ea3e9d8df8c63cfd.
• Closed Add the decision-free Studio authorization and audit foundation #86 provides explicit Studio roles/permissions, revocable StaffSession, audit, and private Studio middleware. Closed Build the decision-free admin API and service-principal foundation #87 provides APIPrincipal, password-style hashed APICredential, Bearer authentication, scope/permission checks, rate limits, idempotency, concurrency, OpenAPI/parity, and test-only credential lifecycle adapters/services. Closed Consolidate the adopted course account as the single website identity #100 preserves one durable website account model.
• Current deployed reality is intentionally empty of production-origin users, tokens, sessions, SocialApps, and SocialAccounts; the login page therefore reports no configured providers. The owner's production password/account cannot work in this development database unless a separately approved exact identity is loaded. This issue does not load it.

Canonical management surfaces

• /admin/ remains Django admin for low-level model administration. Do not rename, replace, or style it as Studio.
• /studio/ remains the custom management product over capability-registered application services.
• /api/v1/admin/ remains the JSON automation API over the same services and permissions.
• Safe GET/HEAD requests to /admin return one permanent redirect directly to /admin/; /studio does the same to /studio/. Preserve the query string, produce no redirect chain, and do not redirect unsafe methods.
• Anonymous /admin/ follows Django admin's own login flow. Anonymous /studio/ redirects once to /accounts/login/?next=%2Fstudio%2F; authenticated but unauthorized requests return 403, not a misleading login loop.

Scope

Development owner bootstrap and login

Implement one secret-safe bootstrap interface for an authorized operator. The preferred application contract is an idempotent bootstrap_development_owner management command/service that:

• refuses unless DTC_ENVIRONMENT=development; test code may exercise the underlying service only with explicit test settings;
• accepts exactly one operator-confirmed owner email and a new development password via a non-echoing interactive channel, never a command-line argument, URL, committed file, issue comment, CI input/output, application log, or persisted bootstrap record;
• creates exactly one accounts.CustomUser when absent, or resets only that same normalized identity after explicit reset confirmation; a conflicting existing identity or second owner attempt fails closed;
• sets active/staff/superuser for Django admin, assigns the code-owned site_admin group for explicit Studio authority, and creates/updates the owner's linked human APIPrincipal with only the credential-management and health permissions registered by this issue;
• creates/updates one named development automation service principal with only core.access_studio initially and no plaintext credential; the owner issues its first token in Studio;
• on reset, revokes the owner's existing StaffSession rows and owner-human API credentials before accepting a new login; it does not silently revoke or recreate the separately visible service credential;
• prints only a fixed success/failure category and safe counts—never email, password, token, digest, session key, database value, or provider material.

Document the exact authorized execution handoff without embedding a secret. If the deployed interactive execution mechanism is still under operational/AWS audit, engineering must still deliver and test this command/service interface; the operator invocation is [HUMAN] and must not broaden CI/deployer AWS permissions or block the code deployment.

On development only, /accounts/login/ adds a CSRF-protected local email/password form using the durable account backend. It uses generic invalid-credential responses and bounded throttling, preserves only a validated same-host next, rotates the Django session on success, and creates the existing revocable StaffSession for active staff. Production/local-test behavior does not silently enable routine local staff passwords.

Explicit Studio authority

• is_staff/is_superuser permits Django admin as Django intends, but neither bypasses Studio authorization.
• Studio requires active staff, an unrevoked StaffSession, and explicit site_admin permissions checked on every request.
• Logout, owner disablement, role removal, session revocation, and owner password reset deny Studio on the next request.
• The site_admin role gains one explicit credential-management permission; lower roles receive none.

Runtime credential workflows

Register non-test capabilities and readable CMP-based, line-broken Django templates for:

Action	Studio	Admin API
List safe credential metadata	GET /studio/access/api-credentials/	GET /api/v1/admin/credentials
Create for an allowed service principal	POST /studio/access/api-credentials/	POST /api/v1/admin/credentials
Rotate	POST /studio/access/api-credentials/<uuid>/rotate/	POST /api/v1/admin/credentials/<uuid>/rotate
Revoke	POST /studio/access/api-credentials/<uuid>/revoke/	POST /api/v1/admin/credentials/<uuid>/revoke

All adapters call shared management_auth query/command services through the capability registry; no adapter writes models directly. Target querysets are limited to active service principals the actor may manage. Missing, malformed, out-of-scope, human, and unauthorized targets do not leak object existence.

Create allows a safe name, an expiry within the existing 90-day maximum (default 30 days), and one or more non-test capability scopes that the target principal currently possesses. For this slice the development automation principal is entitled only to studio.home.read, so its first token can call GET /api/v1/admin/health. No wildcard, future implicit scope, or unimplemented action is shown. Future registered capabilities become selectable only after their owning issue grants the service principal permission and the owner explicitly issues a new scoped credential.

List responses contain only safe metadata: credential UUID, name, principal label/UUID, prefix, scopes, expiry, state, approximate last-used time, created time, and revision. They never expose the token, secret digest, password material, authorization header, or a recovery action.

Create and rotate reveal the raw token exactly once in the immediate successful response. Refresh, back navigation, idempotent replay, later GET/list, audit, database, logs, errors, OpenAPI examples, test artifacts, and screenshots cannot recover it. A create/rotate replay returns the existing safe result as secret_unavailable_on_replay without a token. Rotation preserves approved scopes, defaults to zero overlap, permits only an explicitly requested overlap up to the existing one-hour maximum, and marks the predecessor unusable after that bound. Revocation is immediate and safely idempotent.

Studio mutations require CSRF and explicit confirmation. Admin API create/rotate/revoke require Bearer authentication, the exact management scope/permission, confirmed: true, and Idempotency-Key; rotate/revoke also require the current revision (If-Match or the existing exact revision convention). Stale writes return 409 without mutation. Use existing bounded JSON, field allowlist, CORS-deny, rate, and safe error conventions.

Every allowed and denied create/rotate/revoke and bootstrap/reset action writes redacted audit evidence with actor, target snapshot, outcome, request/idempotency correlation, scopes, expiry/state, and safe reason. Never audit credentials, passwords, digests, headers, cookies, session keys, email values, or request bodies containing secrets.

Management response policy

Every response and redirect under /admin, /admin/, /studio, /studio/, /api/v1/admin/, and the development owner login flow is Cache-Control: private, no-store and X-Robots-Tag: noindex, nofollow; authenticated responses must not enter a public sitemap. Login, logout, denial, validation, one-time reveal, stale, and error states follow the same policy.

Non-goals

• Importing any production user table, password hash, session, token, reset material, Allauth provider/app/account row, other user's PII, registration/activity data, or a broad production database.
• Configuring a social/OIDC provider or deciding production MFA, break-glass, high-risk freshness/dual approval, production Django-admin availability, or final credential retention; Decision: Select the staff OIDC provider and break-glass policy #20/Decision: Confirm high-risk action approvals and reauthentication #28/Complete Studio production identity, role, audit export, and high-risk controls #32/Complete production admin API identity and credential lifecycle controls #33/Integrate staff OIDC/MFA login, session lifecycle, and break-glass recovery #61 retain those responsibilities.
• Replacing Django admin with Studio, folding Studio into /admin/, exposing Django admin models through the admin API, or restoring legacy accounts.Token/plaintext CMP tokens.
• Principal/role administration beyond the two bootstrap principals, domain CRUD, content sync, course/event/email actions, wildcard scopes, token recovery, production cutover, or AWS/IAM/Secrets Manager mutation.
• Claiming the development automation token can perform any action not present in the runtime capability registry.

Acceptance criteria

• One authorized development bootstrap creates/resets only the exact owner, assigns Django-admin flags plus explicit site_admin, creates the human and development service principals, leaks no identity/secret, and refuses production, noninteractive secret input, conflicts, and a second owner.
• The owner can use the development login form, receives a fresh revocable StaffSession, reaches both distinct /admin/ and /studio/ surfaces, and loses Studio access immediately after logout, reset, disablement, role removal, or session revocation.
• /admin and /studio perform exact one-hop permanent safe-method redirects to their slash routes with query preservation; unsafe methods do not redirect; canonical surfaces remain distinct.
• Runtime capability registry, Studio, admin API, OpenAPI, permissions, services, audit, idempotency, concurrency, and results cover list/create/rotate/revoke with no test-only fixture route used at runtime.
• The first service token is scoped only to studio.home.read, succeeds on /api/v1/admin/health, and is denied on missing scopes, credential-management operations, test-only operations, and unknown domain operations.
• Secrets are one-time only and hashed at rest; list/replay/back/refresh/log/audit/error/database/artifact/screenshot checks expose no raw token, password, digest, cookie, or authorization header.
• Expiry (default 30/max 90 days), zero/default and max-one-hour rotation overlap, immediate revocation, owner/principal disablement, permission removal, stale revision, replay, mass assignment, target scoping, throttling, and generic denials behave fail closed.
• CSRF protects every Studio/login mutation; admin API mutations enforce Bearer scope, confirmation, idempotency, revision where applicable, bounded input/rate, and deny-by-default CORS.
• All management/login responses are private/no-store/noindex and templates are CMP-based, readable, indented, line-broken, and non-minified.
• Focused Django/auth/management/OpenAPI/parity tests and core Playwright pass; after independent tester and PM acceptance, normal main deployment proceeds automatically. The operator's real bootstrap invocation/login/token copy is reported separately as [HUMAN] without secret evidence.

Focused Django and security scenarios

1. Exercise bootstrap create, same-owner idempotent run, explicit reset, second/conflicting owner, production refusal, noninteractive refusal, rollback on failure, and output/log/audit secret canaries. Assert exact user/group/principal/session/credential counts and no production identity/provider/token rows.
2. POST valid/invalid local login with CSRF, throttling, hostile external next, duplicate normalized email, inactive/nonstaff/unassigned/superuser-only users, session fixation, logout, reset, revoke, and permission change. Studio never accepts flag-only authority.
3. Assert exact slashless redirect status/location/query/hop count for GET/HEAD and non-redirect behavior for POST, followed by canonical Django-admin versus Studio auth behavior.
4. Through both adapters, create/list/rotate/revoke the service credential; compare status, safe result, database effect, audit action, and permission decisions. Assert one-time token display and password-style digest verification without persisting raw secrets.
5. Replay create/rotate/revoke, reuse idempotency keys with changed payloads, race/stale revisions, expire/rotate/revoke/disable/remove permission, malformed IDs, human/out-of-scope targets, unknown/extra fields, invalid scopes/expiry/overlap, and rate exhaustion. Assert no existence leak or partial mutation.
6. Call /api/v1/admin/health with the first token, then prove missing/malformed/wrong/expired/revoked/rotated tokens and test-only/unregistered operations fail with the existing safe envelope. Regenerate OpenAPI and parity artifacts with only real runtime routes.
7. Scan response bodies, redirect locations, database rows, captured logs, audits, idempotency records, templates, OpenAPI, and test artifacts for token/password/digest/header/session/email canaries.

Browser acceptance

At desktop (~1440×900) and mobile (~390×844), using isolated synthetic identities only:

1. Visit /admin and /studio; verify direct slash redirects, distinct branding/purpose, correct login destination, no redirect loop, and private/noindex headers.
2. Log in through the development owner form with keyboard-only controls; verify safe invalid credentials, preserved local next, Studio navigation, separate Django admin, responsive layout, visible focus, and logout/back-cache denial.
3. In Studio list zero credentials, create the health-only automation token, verify the one-time warning/copy affordance without capturing the token, navigate away/back/refresh and confirm it cannot be revealed again.
4. Rotate with zero overlap, inspect safe predecessor/successor states, revoke the successor, and verify confirmation/cancel/stale/error/empty states. No secret appears in URL, page title, history, screenshot, or console/network diagnostics.
5. Use a separately injected synthetic token in the API client to prove health success then expiry/revocation denial; screenshots contain redacted placeholders only.

Store screenshots only under .tmp/screenshots/issue-107/, inspect each image, and post an independent tester report before PM acceptance.

Dependencies and delivery

Closed #86, #87, and #100 are sufficient implementation prerequisites. #20/#28/#32/#33/#61 are production-policy follow-ups, not blockers for this development-only owner slice. #99's safe review-data boundary is evidence that production identities are absent, not a dependency and not permission to import them.

Follow _docs/PROCESS.md: engineer implements/tests without committing; independent tester verifies and captures safe screenshots; PM accepts; engineer commits; orchestrator locally merges/pushes without a pull request; on-call alone observes CI/deployment. No secret may be used as lifecycle evidence.

[alexeygrigorev]

Grooming Complete

Verdict: READY FOR ENGINEERING — development-only login/token vertical slice

Groomed against exact main 872fd8a9145a0e29de8890e9ea3e9d8df8c63cfd, specs 06/07/10, closed Studio/admin-API foundations #86/#87, the single-account contract #100, and #99's explicit zero-production-identity boundary.

The issue now keeps Django admin, Studio, and the admin API distinct; defines direct slash redirects; specifies one secret-safe development owner bootstrap interface without production user/provider/session/token import; requires explicit site_admin plus revocable StaffSession; and promotes the existing hashed credential lifecycle from test-only services to real Studio/admin-API list/create/rotate/revoke adapters. Scopes, expiry, one-time reveal, audit redaction, CSRF, confirmation, idempotency, revision conflicts, rate/input bounds, private/no-store/noindex behavior, readable CMP templates, and focused Django/security/browser acceptance are explicit.

The first service token is honestly limited to the implemented studio.home.read scope and /api/v1/admin/health. Future domain actions require their owning capability, explicit service-principal permission, and a newly issued scope; no wildcard or unimplemented action is claimed.

Production OIDC/MFA/break-glass/final high-risk policy issues remain separate follow-ups and do not block this owner-directed development experiment. The exact deployed interactive operator mechanism may be completed as [HUMAN] after the tested bootstrap command/service exists; it must not broaden AWS permissions or expose a secret.

No repository file, implementation, database, credential, AWS resource, deployment, commit, or push was changed by this PM pass. needs grooming was removed; enhancement and testing were added.

[alexeygrigorev]

Software Engineer Report

Implemented issue #107 from reviewed baseline 872fd8a9145a0e29de8890e9ea3e9d8df8c63cfd in the isolated issue-107-development-owner worktree. Changes remain uncommitted.

Behavior delivered

• Added an idempotent, interactive, development-only bootstrap_development_owner command and application service. It creates or reconciles one exact owner, explicit site_admin authority, one linked human principal, and one health-only development automation service principal. Reset revokes owner staff sessions and human credentials while preserving visible service credentials.
• Added the CSRF-protected development owner form to /accounts/login/, with an exact-owner principal gate, generic failures, database-backed identity/network throttling, validated local next, session rotation, revocable staff-session creation, and production refusal.
• Preserved distinct surfaces: /admin/ is branded as Django admin and /studio/ remains the custom Studio. Slashless safe requests redirect once with query preservation; unsafe methods do not redirect.
• Promoted credential list/create/rotate/revoke to non-test capability-registry services shared by Studio and /api/v1/admin/. Added explicit permission, immutable high-risk confirmation policy, object/field scoping, bounded expiry and overlap, optimistic concurrency, idempotency, rate limits, hashed storage, one-time secret responses, safe replay results, and redacted audit evidence with fenced idempotency correlation.
• Added the readable CMP Studio credential UI and generated OpenAPI contract. The initial service token has only studio.home.read: health succeeds and credential management is denied.
• Removed legacy plaintext accounts.Token from Django admin and documented the authorized operator handoff.

Changed files

• Docs/artifacts: _docs/adoption/course-platform/behavior-inventory.md, _docs/adoption/course-platform/integration-patched-files.tsv, _docs/api/admin-openapi.json, _docs/runbooks/development-owner-bootstrap.md.
• Accounts: accounts/admin.py, accounts/backends.py, accounts/development_owner.py, accounts/forms.py, accounts/management/commands/bootstrap_development_owner.py, accounts/studio_roles.py, accounts/templates/accounts/login.html, accounts/tests/test_development_owner.py, accounts/tests_token_admin.py, accounts/views/login.py.
• Core/site: core/static/core/site.css, core/tests/test_course_platform_adoption.py, core/views.py, website/settings/base.py, website/urls.py.
• Management API/auth: management_api/dispatch.py, management_api/errors.py, management_api/openapi.py, management_api/parity.py, management_api/tests/test_runtime_credentials.py, management_api/urls.py, management_api/views.py, management_auth/idempotency.py, management_auth/migrations/0003_apiprincipal_manage_api_credentials.py, management_auth/models.py, management_auth/policies.py, management_auth/runtime_capabilities.py, management_auth/services.py, management_auth/tests/test_runtime_policies.py, management_registry.py.
• Studio/browser: studio/checks.py, studio/urls.py, studio/views.py, templates/studio/credentials.html, playwright_tests/test_development_owner_credentials.py.

Verification

• make lint: pass.
• make format-check: pass, 320 files formatted.
• make typecheck: pass, 246 source files.
• make migrations-check: pass, no changes detected.
• make django-check: pass; generated OpenAPI and capability/runtime parity are current.
• make deployment-check: pass with production settings.
• make terminology-check: pass.
• Focused owner/runtime-policy/credential/adoption suite: 25/25 pass.
• make test-core: 700/700 pass.
• make test-playwright-core: 44 pass, 3 deployed-smoke cases skipped because no deployed target was supplied.
• git diff --check: pass.
• Inspected eight desktop/mobile images under .tmp/screenshots/issue-107/: login, empty credentials, one-time reveal with a redacted placeholder, and revoked states. Layouts are responsive and contain no raw credential.

Remaining handoff

• [HUMAN] An authorized operator must run the documented interactive command against the development deployment, choose the owner email/password through the non-echoing channel, log in, and copy the one-time token. No production database, identity, password, token, session, provider row, or AWS resource was imported or changed.
• The first token intentionally calls only GET /api/v1/admin/health. Domain actions remain unavailable until their owning issues register capabilities, grant the service principal permission, and a new explicitly scoped credential is issued.
• Independent tester verification/screenshots and PM acceptance remain required before commit. No commit, push, deployment, PR, or AWS mutation was performed.

[alexeygrigorev]

Software Engineer Report — QA Corrections

Status: ready for independent tester re-verification. The implementation remains uncommitted on issue-107-development-owner from reviewed baseline 872fd8a9145a0e29de8890e9ea3e9d8df8c63cfd.

QA failure reproduced and corrected

• Reproduced the reported cadmin.tests.test_campaign_views regression: 4 of 5 tests failed because the durable password backend rejected every staff password whenever the development-owner login flag was disabled, including Django's requestless Client.login() test-fixture path.
• Kept runtime behavior fail closed. Base/deployed settings still deny routine staff password authentication outside the development owner flow. Test settings now opt into a narrowly scoped requestless staff-fixture path used by Client.login(); real HTTP requests do not qualify.
• Added regression coverage proving that, with development owner login disabled, the explicit test fixture can authenticate programmatically while both the public local-login POST and the Django-admin HTTP password login remain denied. Disabling the test-only fixture flag also restores requestless denial.

Contract corrections

• OpenAPI APIError now permits the optional safe result field returned by idempotent credential replay and constrains it to CredentialMetadata.
• Runtime parity now compares the registered service, result schema, and audit action for every operation. The credential collection route exposes distinct method bindings for list and create. A regression test proves drift in each binding is detected.
• Parity still executes only the safe health query; credential command services are never invoked by the parity check.

Verification

• Exact QA reproducer: DJANGO_SETTINGS_MODULE=website.settings.test uv run python manage.py test cadmin.tests.test_campaign_views --verbosity 2 — 5/5 passed.
• Focused owner/runtime/API/policy/adoption/campaign set — 32/32 passed.
• make test — compatibility suite 289 passed; Django suite 1,429 passed.
• make test-core — 702 passed.
• make test-playwright-core — 44 passed, 3 deployment-only tests skipped; desktop and mobile owner login/credential lifecycle coverage passed.
• make lint, make format-check, make typecheck, make migrations-check, and make django-check — passed.
• make deployment-check, make terminology-check, and git diff --check — passed.

No commit, push, deployment, AWS/IAM mutation, production-data import, or production credential operation was performed. No raw credential or owner identity was included in test output, artifacts, or this report.

[HUMAN] remaining

An authorized operator must separately invoke the interactive bootstrap in the deployed development environment, log in with the resulting owner identity, and copy the one-time service token. This evidence must remain secret and is intentionally not part of the automated lifecycle report.

[alexeygrigorev]

QA Review

Verdict: PASS

Reviewed the complete uncommitted candidate diff from baseline 872fd8a9145a0e29de8890e9ea3e9d8df8c63cfd, including the follow-up corrections documented in the engineer report. No product files were edited during QA.

Automated verification

• Focused corrected-candidate suite: 40/40 passed across development-owner bootstrap/login, Django admin, runtime credential lifecycle, management API, runtime policy, and adoption coverage.
• make test: 289 compatibility tests + 1,429 Django tests passed.
• make test-core: 702/702 passed.
• make test-playwright-core: 44 passed, 3 deployment-only tests skipped.
• make lint, make format-check, make typecheck, make migrations-check, make django-check, make deployment-check, make terminology-check, and git diff --check: all passed.
• OpenAPI and management-registry parity checks are current.

Acceptance evidence

• Development-owner bootstrap is development-only and interactive-only; it creates the exact configured owner, reconciles memberships/permissions, handles conflicts, supports explicit reset, is idempotent, and does not print passwords or credential material.
• The configured owner can authenticate locally and reach both Studio and the separate Django admin. Non-owner/staff denial and session/logout behavior are covered.
• Legacy /admin and /studio GET redirects preserve query strings; unsafe methods do not redirect and remain denied.
• Runtime management capabilities are registry-driven and parity-checked against the exposed API.
• Credential creation defaults to the health capability; scope validation, expiry, maximum lifetime, disablement, rotation overlap, revocation, stale-write handling, idempotency, audit metadata, rate policy, malformed input, and mass-assignment resistance are covered.
• Credential secrets are returned only once, stored as digests, never replayed, and Bearer authentication correctly enforces active state, expiry, scope, and rotation/revocation status. CSRF/session boundaries are covered.
• Login, Studio, credential-management, and Django-admin responses include the expected private-cache and indexing protections.
• The API error/result schema and method-specific audit/result parity corrections were verified.

Browser and visual verification

Ran against an isolated SQLite database on local port 8107. Verified desktop (1440×900) and mobile (390×844) states for:

• development login and generic invalid-login response;
• Studio home;
• distinct Django admin surface;
• empty credential state;
• created health-only credential;
• zero-overlap rotation;
• revoked credential.

All 16 fresh screenshots are in .tmp/screenshots/issue-107-qa/ and were individually opened and inspected. Pages are fully styled, responsive, free of debug/error output and horizontal overflow. One-time token values were redacted before capture; an artifact scan found no raw credential, digest, authorization header, or session cookie. The isolated QA database was removed and the test server was stopped after capture.

The modified login and credential templates were also reviewed directly and remain readable, indented, and non-minified.

No production database, production identity, production credentials, deployment, AWS mutation, commit, or push was used. The remaining real-operator development bootstrap/login/token-copy smoke check is appropriately human-only and is not an automated-QA blocker.

[alexeygrigorev]

Product Acceptance

Verdict: REJECT — owner password control is not visibly usable

I reviewed the groomed contract, corrected engineer handoff, independent tester PASS, complete uncommitted candidate from baseline 872fd8a9145a0e29de8890e9ea3e9d8df8c63cfd, the changed templates directly, and the fresh desktop/mobile screenshots under .tmp/screenshots/issue-107-qa/.

The management experience is otherwise aligned with the issue:

• Django admin and Studio remain clearly separate products at /admin/ and /studio/.
• The local form and Studio authorization are limited to the exact bootstrapped owner authority, with generic invalid-login copy and safe session/denial behavior.
• Studio presents understandable empty, create, one-time reveal, rotate, and revoke states.
• The credential is described and enforced honestly as health-only (studio.home.read); no unavailable domain action is promised.
• Management responses remain private/no-store/noindex, secrets are redacted from visual evidence, and the Studio credential template is readable, line-broken, responsive CMP markup.
• The runbook explicitly leaves the real development bootstrap/login/token-copy operation as [HUMAN]; this review does not claim any deployed owner login or token exists.

One critical-flow defect prevents acceptance. In both development-login-desktop.png and development-login-invalid-mobile.png, the owner email field has a visible input boundary, but the Development password label is followed by an effectively invisible blank area before the submit button. The source explains the visual result: DevelopmentOwnerLoginForm gives the password widget no CMP form-control class, while the adopted courses/static/courses.css form rules style email/text/url/number/search fields but omit input[type="password"]. An owner cannot confidently identify or focus the password control from the presented page. That fails the understandable owner-login and CMP-consistency acceptance even though keyboard automation can locate the semantic field.

Required correction and re-verification

1. Give the password control the same visible CMP input treatment as the email control in light/dark and focus states, without changing authentication or secret handling.
2. Add a focused regression assertion for the intended password control class/style contract.
3. Re-run the focused login tests and make test-playwright-core.
4. Capture and inspect fresh desktop/mobile initial-login and invalid-login screenshots showing a clearly visible password field, with no password value or other secret present.
5. Return the corrected uncommitted candidate to the independent tester, then to PM acceptance again.

No repository file, commit, push, deployment, AWS resource, database, identity, password, or token was changed by this PM review.

[alexeygrigorev]

Software Engineer Report — Owner Login Visual Correction

Status: the PM visual blocker is corrected and the uncommitted candidate is ready for independent tester re-verification.

Correction

• Both DevelopmentOwnerLoginForm fields now declare the existing CMP form-control class.
• The shared CMP form selectors now include input[type="password"] in light, dark, and dark-focus rules, giving the password field the same border, opaque background, full width, minimum height, and focus treatment as the email field.
• Authentication, secret handling, throttling, and authorization behavior are unchanged.

Regression coverage

• The focused Django test asserts that both owner-login widgets retain the CMP class contract.
• The core browser scenario now checks both controls for a visible border, opaque light/dark background, at least 40px height, matching width/height, and a computed focus indicator.
• The scenario captures initial and generic invalid-login states at 1440×900 and 390×844. It asserts that the submitted invalid password is cleared and absent from the rendered page before screenshot capture.

Verification

• accounts.tests.test_development_owner — 14/14 passed.
• Focused desktop/mobile owner lifecycle browser scenario — 2/2 passed.
• make lint, make format-check, make typecheck, and make django-check — passed.
• git diff --check — passed.
• The broader core browser gate on the immediately preceding corrected candidate was 44 passed with 3 deployment-only skips; the changed owner scenario was then rerun directly at both viewports after this styling correction.

Visual inspection

Inspected these fresh files under .tmp/screenshots/issue-107/:

• development-login-desktop.png
• development-login-mobile.png
• development-login-invalid-desktop.png
• development-login-invalid-mobile.png

All four show clearly bounded, equal-width email and password inputs without clipping or horizontal overflow. The invalid screenshots show only the generic safe error and empty controls. No password, token, authorization header, cookie, or production identity is visible.

No commit, push, deployment, AWS/IAM mutation, production-data import, bootstrap invocation, login, or token generation was performed. The real deployed bootstrap/login/token-copy step remains [HUMAN].