- Add password_reset_required column (migration 004) + repository support
- auth.Service.ChangePassword verifies current, hashes new, clears flag,
emits PasswordChange audit events for success and failure
- Bootstrap: when no ORCHESTRAD_BOOTSTRAP_PASSWORD[_FILE] is set, seed
admin/admin with password_reset_required=true and log a one-time warn
banner; env/file-supplied passwords keep the flag clear
- Expose passwordResetRequired in UserInfo / /auth/me / login response
- POST /api/v1/auth/change-password behind the authenticated group
- Frontend: /change-password page + ChangePasswordForm, AuthLogin and
RequireAuth bounce any other route to it while the flag is set
- Docs: DesignSpecification 8.6/8.8 and Template 7.6/7.7 rewritten,
Trusted Proxy renumbered to 7.8 in the template, acceptance items
updated to match the new default-credential behavior
Bake the hardening work from recent commits into the spec and template so
future apps built from this template don't need the same refactors:
- Route protection as a public/authenticated split in Phase 1, with
an explicit public allowlist logged at startup. Per-handler auth
attachment is forbidden; the router must inherit protection by
construction.
- Trusted-proxy middleware in Phase 1, empty default CIDR list,
X-Forwarded-* honored only from operator-configured peers, and
downstream code forbidden from re-reading forwarded headers.
- First-run admin bootstrap wired into the run command immediately
after migrations, using BOOTSTRAP_PASSWORD/_FILE or a generated
password printed once to stdout and the structured log.
- Env-or-file indirection mandatory for every secret-bearing
environment variable, with a centralized loader.
- Origin-agnostic frontend: no hardcoded backend scheme/host/port
anywhere in the bundle, including SSR/prerender fallbacks. Resolve
from window.location.origin at runtime and return an empty string
during SSR so relative URLs are produced.
- Flatten Spike template demo routes (for example /auth/auth1/login
becomes /login) in the first frontend commit so features are not
wired to paths that must later be rewritten.
Also extends the guardrail list and MVP acceptance criteria to make these
requirements concrete verification steps rather than implicit guidance.
Add a machine-parseable 'embed_ui_in_binary' yes/no question to both the product specification (DesignSpecification.md) and the reusable framework template (DesignSpecificationTemplate.md). Default is 'yes' so the released binary ships the full product (API + UI) from a single artifact via //go:embed. Document the behavior contract for both answers (embedded-binary vs separate-deployment) and add a new UI Delivery Model section covering: static-export requirements for Next.js, SPA fallback for deep links while preserving /api/v1 and /healthz routes, cache/content-type expectations, build ordering (frontend before backend), and a clear build failure when the UI output directory is missing or empty. Extend the Binary Branding / Embedded Resources sections and MVP acceptance criteria in both docs to cross-reference the question so AI implementers can trace the answer through every affected area.
GraceSolutions