cclohmar/NextMyDay
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
NextMyDay/AGENT.md
Claus Lohmar 13133717e1 docs(spec-010): record the admin & account UI implementation 
SPEC-010 is implemented: status + §8 implementation notes and the §9 deviations
(D-1…D-5). The plan, AGENT status, README and the spec index move to M0.2 —
M0, M0.1 and M0.2 are complete; next is M1 (org structure).
2026-10-15 07:58:27 +00:00

3.7 KiB
Raw Permalink Blame History

AGENT.md — MyDay

Operating instructions for AI agents working in this repository. Status: M0 + M0.1 + M0.2 implemented (SPEC-002…010); next milestone M1 — org structure.

1. What MyDay is

MyDay is Sechpoint's self-hosted, single-tenant employee app (a PWA for mobile and desktop): time & absence, reporting, and the company org structure those depend on.

It is one Go binary — a small core (MyDay.auth) plus drop-in modules.

2. The source of truth

Artefact Role
PROJECT_PLAN.md the decision log of record — read it first. If a decision changes, update it in the same change.
docs/specs/ implementation specs. Specs precede code.
README.md the human quickstart.
.opencode/git.env the agent git-workflow contract (gitignored; see .opencode/git.env.example).

3. Doctrine — the rules that must not be broken

  1. The path is the request. Identity lives in the path; the query carries only transient state.
  2. The rule of the door. The door resolves; the handler authenticates. A module never parses a raw path.
  3. Identification ≠ authorisation. The GUID is a username; the session cookie is the credential. A bookmark is never a login.
  4. Two doors, one destination. ROUTER (path) and HANDLER (do/action) both resolve to (module, function, params) (D-039).
  5. Modules are independent. A module depends only on core interfaces and owns its own tables — never reach into another module's data.
  6. Delete, don't redirect. Reserved names come from one source.
  7. Every page renders inside the shell. The core layout owns the document, the header and the nav (Registry.Nav()); a module supplies content only. The CSP is script-src 'self': no inline <script>, no on*=, no javascript: — the WebAuthn ceremonies are driven from data-* attributes by static/webauthn.js. Static assets are served by the reserved static workflow (internal/core/server/static.go).

4. Stack & layout

  • Go (single binary) · SQLite (WAL · foreign keys ON · CGO-free driver) · sqlc · slog
  • internal/core/ — the door · registry · identity · sessions · roles · chain · DB
  • internal/modules/<name>/ — app.go · routing.go · handlers.go (+ queries.go · migrations/ · web/)

See PROJECT_PLAN.md §12.1.

5. Working rules

  • Read PROJECT_PLAN.md before changing anything structural. Decisions live there.
  • Spec before code. New work starts as docs/specs/spec-NNN-*.md.
  • Commit AND push at every submilestone (each spec slice or revision) once the gate — go build · go vet · go test -race — is green. main is the source of truth. Group into Conventional Commits (feat: · fix: · docs: · chore: …), one per area/submilestone.
  • Never commit secrets — config.yaml, .opencode/git.env, *.db are gitignored (D-010).
  • Never set git identity globally — repo-local only.
  • Do not force-push.
  • When a decision changes, update PROJECT_PLAN.md in the same commit.

6. Current phase

M0 (auth + routing foundation), M0.1 (the web layer / PWA) and M0.2 (the admin & account UI) are complete — SPEC-002 … SPEC-010 are implemented: routing · identity/sessions · the door · /setup · enroll/login (+ the passkey nudge) · roles/chain/recovery · the module registry · the web shell & PWA · the role-gated nav, the account page (factors · add a passkey · opt-out), the admin Users page (list · create + invite) and the post-setup passkey banner.

Next: M1 — org structure (PROJECT_PLAN.md §11).