Compare commits

...
23 changed files with 1720 additions and 84 deletions
+413
View File
@@ -0,0 +1,413 @@
# Lab Timesheet — Three-Iteration Delivery Plan
**Artifact purpose:** Local agent coordination and progress tracking
**Implementation branches:** `work/platform`, `work/projects`, `work/tasks`, `work/attendance`, `work/reports-ui`
**Requirements authority:** `labtimesheet-docs-hub/requirements-specification.md`
**SRS:** `labtimesheet-docs-hub/software-requirements-specification.md`
**Initial status:** Planning complete; implementation remains subject to requirements approval
This file divides the approved product scope across three iterations and five persistent work branches. It is a coordination artifact, not an alternative requirements source. When this plan and a numbered requirement disagree, the numbered requirement wins.
## 1. Progress rules
Use these exact status values:
| Status | Meaning |
|---|---|
| `TODO` | No implementation work has started. |
| `IN_PROGRESS` | One named owner is actively working on the item. |
| `BLOCKED` | Work cannot continue; the tracker must name the evidence and required decision/dependency. |
| `DONE` | Required RED/GREEN evidence exists, affected tests pass, and the integrated behavior satisfies the requirement. |
Before editing production code, an agent shall:
1. Read the applicable numbered requirements and acceptance scenarios.
2. Claim one bounded tracker item by setting its status to `IN_PROGRESS` and recording owner/date.
3. Identify the test level and evidence file that will protect the behavior.
4. Write and run the failing test before production code.
5. Confirm the test fails because the required behavior is missing, not because the test or environment is broken.
When completing an item, the agent shall record:
- the exact RED command and expected failure;
- the exact GREEN and affected-suite commands;
- the evidence Markdown path under `docs/tests/`;
- the implementation commit or final local commit SHA;
- any remaining limitation that is explicitly allowed by the requirements.
No item becomes `DONE` based only on compilation, an isolated happy path, screenshots, or a verbal claim.
## 2. Branch ownership and conflict boundaries
| Branch | Sole or primary ownership |
|---|---|
| `work/platform` | Maven/application baseline, feature-package foundation, Flyway migration files, account/security/bootstrap, internship lifecycle, integration credential lifecycle, notification delivery infrastructure, Docker, and CI. |
| `work/projects` | Projects, membership intervals, invitations, membership-exit requests, leadership terms, Project lifecycle, Project-scoped authorization, member-removal orchestration, and Project completion. |
| `work/tasks` | Tasks, generic creator/assignment actors, member self-Task rules, comments, work logs, fixed status transitions, assignment/reassignment, Task soft deletion, and Project Task-progress calculations. |
| `work/attendance` | Attendance-policy versions, configured workdays, global calendar, HolidayAPI import interpretation, attendance, corrections, leave, deadline schedulers, and attendance/compliance metrics. |
| `work/reports-ui` | Shared Thymeleaf shell/fragments, Tailwind tokens/assets, dashboards, invitation/exit-request screens, shared report datasets, Chart.js presentation, XLSX/PDF exports, and cross-product UI/accessibility consistency. |
Conflict-prevention rules:
- `LabtimesheetApplication` shall remain in `com.lab.labtimesheet`, shared wiring in `config`, and business code in `feature.account`, `feature.integration`, `feature.project`, `feature.task`, `feature.attendance`, `feature.notification`, or `feature.reporting`. Each feature repeats only the controller/model/model.dto/model.entity/repository/service/exception layers it needs, and tests mirror that feature/layer shape.
- Cross-feature code may call another feature's service contract and DTOs but shall not import that feature's repository or JPA entity. Do not create empty `utils`, `common`, or `core` packages.
- Business persistence shall use Spring Data JPA repositories. Direct SQL is limited to Flyway migrations and schema/catalog verification; services shall not use `JdbcTemplate` or embed SQL.
- `work/platform` owns `src/main/resources/db/migration/**`, Maven/dependency configuration, Compose, container build files, and CI workflow files. Other branches request schema changes instead of independently allocating migration versions.
- `work/reports-ui` owns shared templates/fragments, shared design tokens, and general UI assets. Each domain branch owns its module-specific controllers and pages while consuming those shared fragments.
- `work/tasks` exposes focused Task query/transfer operations required by Project workflows. `work/projects` owns the transaction that removes a member or completes a Project.
- `work/platform` owns HolidayAPI credential storage and the tested HTTP client. `work/attendance` owns preview interpretation, selection, deduplication, import, and day-off effects.
- Attendance time and Task work time remain separate. No branch may make one mutate or prove the other.
- Do not introduce a generic workflow engine, generic event-sourcing layer, multi-assignee Task model, Project-level day-off model, or speculative cross-module abstraction.
## 3. Iteration overview
| Iteration | Theme | Required demonstration | Status | Integration commit |
|---|---|---|---|---|
| 1 | Working vertical slice | Bootstrap users, create/activate Project, assign/change a Task, and check in/out with role-correct UI. | `DONE` | `b9b150ff8ca9333e3b46d77537ec91875a970d57` |
| 2 | Complete business workflows | Policy/calendar changes, leave/corrections, leadership/member transfer, work logs, notifications, and full HTML workflows. | `TODO` | — |
| 3 | Hardening and delivery | Historical/concurrency proof, production security, HTML/XLSX/PDF parity, accessibility, containers, and CI publication boundary. | `TODO` | — |
## 4. Iteration 1 — Working vertical slice
### 4.1 `work/platform`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I1-PLAT-01 | Establish the Maven/Spring Boot modular baseline and root/config/feature package boundaries. | Context/load test; root-package and package-by-feature/layer check; no cross-feature repository/entity access or direct-SQL business services. | `DONE` | platform_agent / 2026-08-15 | Approved Platform head `692b23e9b9891d360882671d8247965b44920b2f`; integrated architecture/full-suite gates passed. |
| I1-PLAT-02 | Promote the reviewed 23-table/56-foreign-key PostgreSQL baseline into the platform-owned initial Flyway migration after explicit approval. | Fresh PostgreSQL 18.4 migration replay, catalog assertions, and invitation/exit same-Project constraints. | `DONE` | platform_agent / 2026-08-15 | Fresh local replay produced exactly 23 application tables and 56 foreign keys at the integrated head. |
| I1-PLAT-03 | Configure PostgreSQL Testcontainers and shared test-only encryption/clock facilities. | Affected integration tests require no developer database or SMTP. | `DONE` | platform_agent / 2026-08-15 | Taskmaster full PostgreSQL 18.4 Testcontainers suite passed 197/197. |
| I1-PLAT-04 | Implement atomic first-Admin bootstrap and permanent bootstrap closure. | Concurrent submissions create exactly one first Admin; restart keeps bootstrap closed. | `DONE` | platform_agent / 2026-08-15 | Bootstrap/restart/concurrency evidence approved at `692b23e9b9891d360882671d8247965b44920b2f`; fresh local bootstrap passed. |
| I1-PLAT-05 | Implement initial SMTP draft/test/active path sufficient for Mailpit onboarding. | Failed test cannot activate; tested revision supports delivery. | `DONE` | platform_agent / 2026-08-15 | Real local Mailpit draft, test delivery, activation, active-state, and health checks passed at the integrated head. |
| I1-PLAT-06 | Create Mentor/Intern accounts, deliver activation, set first password, and authenticate/logout. | SMTP gate, single-use token, expiry, normalized email, role/state access. | `DONE` | platform_agent / 2026-08-15 | Activation/authentication evidence and independent review approved at `692b23e9b9891d360882671d8247965b44920b2f`. |
| I1-PLAT-07 | Provide development Compose with PostgreSQL and Mailpit plus initial Gitea verification workflow. | Fresh developer start and branch/main verification. | `DEFERRED` | taskmaster / 2026-08-15 | Explicitly excluded from this exit gate; application containerization, Compose, and CI remain future work. |
### 4.2 `work/projects`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I1-PRJ-01 | Atomically create a Mentor-owned `PLANNED` Project, eligible initial Leader membership, and first leadership term. | No committed Project is empty or leaderless; non-owner, ineligible Leader, and guessed-ID access are denied. | `DONE` | projects_agent / 2026-08-15 | Approved Project head `baa0695c60153bc997ebf8b11adcfbdd2cbc1962`; Project suite and review passed. |
| I1-PRJ-02 | Directly add eligible Interns through owning-Mentor-controlled interval memberships. | Multiple concurrent Projects per Intern; duplicate active membership rejected; no acceptance step for direct add. | `DONE` | projects_agent / 2026-08-15 | Membership/eligibility/IDOR evidence approved at `baa0695c60153bc997ebf8b11adcfbdd2cbc1962`. |
| I1-PRJ-03 | Appoint and change one current Leader from active same-Project members. | One current Leader; non-member/ineligible selection rejected. | `DONE` | projects_agent / 2026-08-15 | Leadership-term invariants and completed-history behavior approved at `baa0695c60153bc997ebf8b11adcfbdd2cbc1962`. |
| I1-PRJ-04 | Activate a Project when initial member, Leader, date, and assignee guards pass. | Missing Leader/member or invalid assignee blocks activation. | `DONE` | projects_agent / 2026-08-15 | Task-bound activation guard approved at `baa0695c60153bc997ebf8b11adcfbdd2cbc1962`. |
| I1-PRJ-05 | Provide Project list/detail/member/leadership pages with owning-Mentor and member visibility. | MockMvc authorization plus direct-ID denial. | `DONE` | projects_agent / 2026-08-15 | Authorized pages, retained errors, and former-member history approved at `baa0695c60153bc997ebf8b11adcfbdd2cbc1962`. |
### 4.3 `work/attendance`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I1-ATT-01 | Resolve the seeded attendance policy, timezone, configured workdays, schedule, and separate check-in/checkout grace boundaries. | Both grace defaults are 30; values are 0720; checkout cutoff must stay before local midnight. | `DONE` | attendance_agent / 2026-08-15 | Approved Attendance head `01b8095e9459417e2cf5bd1079c796d4f01ec549`; fresh seed verified both grace values at 30. |
| I1-ATT-02 | Manage manual future global calendar events and day-off decisions. | Admin-only mutation; past-event immutability; workday/day-off distinction. | `DONE` | attendance_agent / 2026-08-15 | Calendar authorization and day-off evidence approved at `01b8095e9459417e2cf5bd1079c796d4f01ec549`. |
| I1-ATT-03 | Check in once on an eligible day using server time and the effective policy. | Off-day, approved-leave, duplicate, lifecycle rejection, and inclusive 09:00 check-in-grace boundary. | `DONE` | attendance_agent / 2026-08-15 | Boundary, eligibility, leave-day, and real duplicate-race evidence approved at `01b8095e9459417e2cf5bd1079c796d4f01ec549`. |
| I1-ATT-04 | Check out once through the attached-policy checkout cutoff and derive basic daily classification. | Default 16:00 succeeds; first later instant and zero-grace late attempt fail; no checkout becomes only `MISSING_CHECKOUT` with raw checkout unchanged. | `DONE` | attendance_agent / 2026-08-15 | Historical-policy cutoff, eligibility recheck, and missing-checkout-only evidence approved at `01b8095e9459417e2cf5bd1079c796d4f01ec549`. |
| I1-ATT-05 | Provide own-attendance history and authorized Mentor/Admin inspection. | Own/global-view authorization and historical applied-policy display. | `DONE` | attendance_agent / 2026-08-15 | Policy-local history, all violations, and role authorization approved at `01b8095e9459417e2cf5bd1079c796d4f01ec549`. |
### 4.4 `work/tasks`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I1-TSK-01 | Create one-assignee Tasks in `PLANNED` or `ACTIVE`: any active member for self, current Leader for any active same-Project member. Store generic creator/assigner/assignee actors. | Self-Task actor equality, other-assignee denial for members, Leader allowance, and cross-Project actor rejection. | `DONE` | tasks_agent / 2026-08-15 | Approved Task head `e38e2cdea912160b183c65398c4e8d5682c1b00e`; actor/assignee/IDOR evidence passed review. |
| I1-TSK-02 | Validate optional due dates against Project dates and current global days off. | Boundary dates accepted; outside/day-off dates rejected. | `DONE` | tasks_agent / 2026-08-15 | Due-date/calendar validation and retained field-error behavior approved at `e38e2cdea912160b183c65398c4e8d5682c1b00e`. |
| I1-TSK-03 | Enforce the complete fixed Task status graph through current-assignee authorization. | Parameterized allowed/forbidden transition matrix and ID denial. | `DONE` | tasks_agent / 2026-08-15 | Server graph and legal UI choices approved at `e38e2cdea912160b183c65398c4e8d5682c1b00e`. |
| I1-TSK-04 | Add append-only Task comments for active members, current Leader, and owning Mentor. | Unauthorized/non-member and completed-Project mutation denial. | `DONE` | tasks_agent / 2026-08-15 | Comment authorization, lock order, and completed-history behavior approved at `e38e2cdea912160b183c65398c4e8d5682c1b00e`. |
| I1-TSK-05 | Show Task list/detail and initial DONE/non-deleted progress/status counts. | Empty Project renders `N/A`; soft/deleted data not yet exposed as current. | `DONE` | tasks_agent / 2026-08-15 | Progress/N/A, assignee display, visibility, and dashboard ordering approved at `e38e2cdea912160b183c65398c4e8d5682c1b00e`. |
### 4.5 `work/reports-ui`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I1-UI-01 | Establish Tailwind tokens and reusable Thymeleaf shell/fragments. | Fragment rendering, local assets, no unauthorized navigation items. | `DONE` | reports_ui_agent / 2026-08-15 | Shared local-asset shell and persistent SMTP restriction contract verified at `039fe25c7c2622a015c8962892dd99ff58be321d`. |
| I1-UI-02 | Implement the supported desktop sidebar/header, forms, tables, badges, alerts, confirmations, empty/error states, and theme bootstrap. | Keyboard labels/focus, no desktop page-level overflow, pre-paint theme application. | `DONE` | reports_ui_agent / 2026-08-15 | Edge/Chromium 1365x900 focus, collapse tooltip, theme pre-paint, and overflow gates verified at `039fe25c7c2622a015c8962892dd99ff58be321d`. |
| I1-UI-03 | Build basic Admin, Mentor, and Intern dashboards from real queries. | Role-correct metrics/actions; illustrative data never leaks into production paths. | `DONE` | reports_ui_agent / 2026-08-15 | Public service/DTO dashboards and role-correct navigation verified at `039fe25c7c2622a015c8962892dd99ff58be321d`. |
| I1-UI-04 | Integrate bootstrap, authentication, Project, Task, and attendance pages into the shared shell. | Critical MockMvc web flows and server-side authorization. | `DONE` | reports_ui_agent / 2026-08-15 | Integrated shell, SMTP five-step journey, forms, history, errors, and authorization verified at `039fe25c7c2622a015c8962892dd99ff58be321d`. |
### 4.6 Iteration 1 integration gate
Integration order:
1. `work/platform`
2. `work/projects`
3. `work/attendance`
4. `work/tasks`
5. `work/reports-ui`
Exit demonstration:
- First Admin bootstraps the installation.
- SMTP is tested through Mailpit.
- Admin creates and activates Mentor and Intern accounts.
- Mentor atomically creates a Project with its first Leader, directly adds another member, and activates it.
- Ordinary member creates a self-assigned Task; Leader creates and assigns another Task.
- Assignee changes Task status and comments.
- Intern checks in and checks out.
- Every role sees only authorized navigation, actions, and records.
- Full integrated tests pass at the iteration integration commit.
Taskmaster exit result (2026-08-15): `DONE` at main integration commit `b9b150ff8ca9333e3b46d77537ec91875a970d57`, incorporating reviewed candidate `039fe25c7c2622a015c8962892dd99ff58be321d` and the verified development configuration/documentation follow-up. The final merged-main PostgreSQL 18.4 suite passed 197/197; Flyway produced 23 application tables and 56 foreign keys; Node 24/Tailwind assets built successfully; compile and full Javadoc/doclint passed on the reviewed candidate. A real local Java 25 process completed fresh bootstrap, login, five-step SMTP deferral, persistent restriction recovery, and a separate real Mailpit draft/test/activate flow with aggregate health `UP`. Temporary exit databases and Mailpit were removed; the existing development PostgreSQL service remained intact. Project/Task/Attendance role flows are protected by the approved branch suites and real desktop E2E evidence. Application containerization, Compose, CI, and production liveness/readiness hardening remain deferred as recorded above.
## 5. Iteration 2 — Complete business workflows
Iteration 2 starts only after every continuing branch incorporates the integrated Iteration 1 `main`.
### 5.1 `work/platform`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I2-PLAT-01 | Complete account lock/unlock/deactivation and session invalidation. | State graph, authentication denial, retained attribution. | `TODO` | — | — |
| I2-PLAT-02 | Implement activation failure/resend and forgot/reset-password workflows. | Failed token invalidation, single-use/expiry, generic enumeration-safe responses. | `TODO` | — | — |
| I2-PLAT-03 | Implement internship start activation, completion, and withdrawal guards. | Scheduler plus request-time activation; Leader/unfinished-Task terminal guards. | `TODO` | — | — |
| I2-PLAT-04 | Complete encrypted SMTP and HolidayAPI draft/test/active revision lifecycles. | AES-GCM round trip, wrong-key failure, one active revision, no browser secret disclosure. | `TODO` | — | — |
| I2-PLAT-05 | Expose the tested VN HolidayAPI client to the attendance module. | Valid preview, invalid key/rate limit/unavailable responses without local-data outage. | `TODO` | — | — |
| I2-PLAT-06 | Persist in-app notifications and initial ordinary-email delivery states, including Project invitation and membership-exit created/resolved types. | Recipient deduplication, domain commit independent of SMTP, self-Task silence, and `UNAVAILABLE`/sent/failed behavior. | `TODO` | — | — |
### 5.2 `work/tasks`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I2-TSK-01 | Add dated 11440-minute Task work logs and author corrections. | Membership/date boundaries and author-only editing. | `TODO` | — | — |
| I2-TSK-02 | Enforce the combined 1440-minute daily total across all Projects. | PostgreSQL integration and concurrent over-allocation proof. | `TODO` | — | — |
| I2-TSK-03 | Reassign unfinished Tasks while preserving creator, state, comments, and work history and updating generic assignment actor/time. | DONE requires assignee reopen; creator attribution and prior logs/comments remain unchanged. | `TODO` | — | — |
| I2-TSK-04 | Implement Task edit/soft deletion and authorized historical inspection for Leader and self-Task creator. | Leader controls any unfinished Task; creator controls only while still current assignee; deleted Task leaves normal progress but remains historical. | `TODO` | — | — |
| I2-TSK-05 | Provide Task transfer and completion-query operations to the Projects module. | Atomic bulk transfer behavior and non-deleted/DONE counts. | `TODO` | — | — |
| I2-TSK-06 | Complete Project status counts, percentage, total minutes, and per-member work queries. | Empty `N/A`, authorization scopes, hand-checkable totals. | `TODO` | — | — |
### 5.3 `work/projects`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I2-PRJ-01 | Issue and revoke non-expiring Leader invitations while retaining the issuing leadership term. | Eligibility, one pending Project/Intern pair, Leader-own versus Mentor-any revocation, ordinary notification behavior. | `TODO` | — | — |
| I2-PRJ-02 | Let only the intended authenticated Intern accept or decline; support Mentor direct-add supersession. | Email is not a bearer join token; exactly one membership; terminal status/code and provenance retained. | `TODO` | — | — |
| I2-PRJ-03 | Create/cancel Leader-removal and member-leave requests without changing current rights. | Nonblank reason, same-Project/type shape, one pending request per target, requester-only cancellation. | `TODO` | — | — |
| I2-PRJ-04 | Let only the owning Mentor approve/reject exits, using the assisted unfinished-Task transfer and Leader-replacement transaction. | Transfer/replacement/interval/request resolution commit together; reject/cancel changes request only. | `TODO` | — | — |
| I2-PRJ-05 | Retain leadership history, change Leader without moving assignments, and complete only when every non-deleted Task is `DONE`. | Exactly one current Leader in PLANNED/ACTIVE; completion closes intervals, revokes invitations, and supersedes exits. | `TODO` | — | — |
| I2-PRJ-06 | Provide invitation, exit, former-member, and completed-Project historical read-only views. | Historical visibility and attribution without stale mutation authority. | `TODO` | — | — |
### 5.4 `work/attendance`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I2-ATT-01 | Schedule future-month attendance-policy versions, including separate grace values, and preserve effective history. | First-of-future-month rule; effective immutability; old checkout cutoff/report stability. | `TODO` | — | — |
| I2-ATT-02 | Preview/import VN HolidayAPI candidates with Admin selection, override, provenance, and deduplication. | Public suggestion not authority; manual fallback; repeated import safety. | `TODO` | — | — |
| I2-ATT-03 | Materialize frozen full-day leave allocations and monthly/cross-month quota reservations. | Workday/day-off classification, policy snapshot, quota per month. | `TODO` | — | — |
| I2-ATT-04 | Implement leave submit/approve/reject/cancel and overlap protection. | Same-day boundary, pending/approved reservations, concurrent overlap/quota. | `TODO` | — | — |
| I2-ATT-05 | Implement missed-checkout correction submission and effective-checkout derivation. | Reject before/at checkout cutoff; accept afterward through scheduled end +24 hours; raw checkout remains null. | `TODO` | — | — |
| I2-ATT-06 | Implement Mentor approve/reject/revert and separate decision-window locking. | Valid state graph, concurrent decision, expired pending auto-rejection. | `TODO` | — | — |
| I2-ATT-07 | Add idempotent schedulers and equivalent request-time deadline guards. | Late/multiple scheduler invocation cannot duplicate transitions/notifications. | `TODO` | — | — |
### 5.5 `work/reports-ui`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I2-UI-01 | Complete Admin/Mentor/Intern/Leader dashboards and notification UI. | Authorization-correct actions and deadline/state summaries. | `TODO` | — | — |
| I2-UI-02 | Complete account, integration, Project, invitation, membership-exit, Task, policy/calendar, attendance, correction, and leave desktop workflows using shared fragments. | Leader invite/revoke/removal request, Intern accept/decline/leave/cancel, and Mentor exit decision forms retain safe input and expose conflicts clearly. | `TODO` | — | — |
| I2-UI-03 | Build one authorized attendance/compliance HTML report dataset. | Date filters, detailed versus own scope, formulas and `N/A`. | `TODO` | — | — |
| I2-UI-04 | Build one authorized Project/Task HTML report dataset. | Project/member/status/date filters and per-member visibility rules. | `TODO` | — | — |
| I2-UI-05 | Add only meaningful Chart.js trends with adjacent text/table alternatives. | Accessible label, equivalent data, theme tokens, reduced motion. | `TODO` | — | — |
### 5.6 Iteration 2 integration gate
Integration order:
1. `work/platform`
2. `work/tasks`
3. `work/projects`
4. `work/attendance`
5. `work/reports-ui`
Exit demonstration:
- Admin schedules a future policy without changing historical output.
- Admin previews/imports holidays and overrides a suggested day-off decision.
- Intern submits cross-month leave and Mentor decides it.
- Intern submits a missed-checkout correction; Mentor decides and may revert it inside the window.
- Leader reassigns an unfinished Task while preserving work history.
- Leader invites an eligible Intern; the signed-in Intern accepts or declines; Mentor direct-add safely supersedes a pending invite.
- Mentor changes Leader without moving the former Leader's Tasks.
- Member requests to leave and Leader requests removal; Mentor rejects or approves through assisted transfer and required replacement.
- Mentor completes a Project after all non-deleted Tasks are done.
- Ordinary domain actions retain in-app notifications when SMTP is unavailable.
- Full integrated tests pass at the iteration integration commit.
## 6. Iteration 3 — Hardening, reports, and delivery readiness
Iteration 3 starts only after every continuing branch incorporates the integrated Iteration 2 `main`.
### 6.1 `work/platform`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I3-PLAT-01 | Add normalized-email-plus-source-IP login throttling. | Five-in-15 and 15-minute throttle boundaries; successful-login clearing. | `TODO` | — | — |
| I3-PLAT-02 | Finish ordinary email retry schedule and terminal failure handling. | Exact 1m/5m/30m/2h/12h attempts; idempotent bounded worker. | `TODO` | — | — |
| I3-PLAT-03 | Add token cleanup and production-safe operational/status views. | Expired token behavior, no secret/stack/SQL disclosure. | `TODO` | — | — |
| I3-PLAT-04 | Enforce production HTTPS/origin/proxy/header/cookie/master-key readiness. | Prod fails unsafe configuration; dev/test relax only transport/origin controls. | `TODO` | — | — |
| I3-PLAT-05 | Produce the non-root application image and bundled/external PostgreSQL deployment modes. | Same immutable image becomes healthy in both configurations. | `TODO` | — | — |
| I3-PLAT-06 | Finalize Gitea verification, main-only OCI publication, and disabled SSH deployment/rollback template. | Work branches never publish; disabled deploy receives no secrets; exact-SHA flow is testable when enabled. | `TODO` | — | — |
### 6.2 `work/projects`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I3-PRJ-01 | Harden concurrent membership, invitation acceptance/direct-add, exit approval, and leadership operations. | One valid winner; locks/rechecks cover invitation, Project, membership, leadership, request, and unfinished Tasks; stale requests produce explicit conflict without partial history. | `TODO` | — | — |
| I3-PRJ-02 | Complete the global-role/context/ownership authorization matrix for direct membership, invitations, exits, and leadership. | Direct-ID, stale Leader, wrong invitee, cross-Mentor/member, requester, target, and decision-maker negative cases. | `TODO` | — | — |
| I3-PRJ-03 | Prove completed/historical read-only behavior and terminal Intern guards. | No mutation through UI or direct request after lifecycle closure. | `TODO` | — | — |
| I3-PRJ-04 | Verify Project list/progress query indexes and bounded performance. | Explain plan/catalog evidence for actual report paths. | `TODO` | — | — |
### 6.3 `work/tasks`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I3-TSK-01 | Harden concurrent status, reassignment, deletion, and daily-minute operations. | Optimistic conflicts and serialized daily total. | `TODO` | — | — |
| I3-TSK-02 | Complete due-date impact behavior for later-created global days off. | Existing due date retained and disclosed; new/changed due date rejected. | `TODO` | — | — |
| I3-TSK-03 | Complete former-assignee work-log correction and historical-deletion boundaries. | Author/member/Project lifecycle matrix. | `TODO` | — | — |
| I3-TSK-04 | Complete Task authorization/ID-guessing matrix and progress query verification. | Admin/Mentor/Leader/member/creator/current-assignee distinctions, creator-right loss after reassignment, generic same-Project actors, and real query indexes. | `TODO` | — | — |
### 6.4 `work/attendance`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I3-ATT-01 | Finalize attendance-rate and compliance formulas plus `N/A` denominators. | Hand-derived expected values across absence, leave, days off, and violations. | `TODO` | — | — |
| I3-ATT-02 | Prove historical stability after workday, schedule, check-in/checkout grace, quota, penalty, and calendar changes. | Before/after report equality plus unchanged cutoff for an older attendance row. | `TODO` | — | — |
| I3-ATT-03 | Harden concurrent leave quota/overlap and correction-decision races. | PostgreSQL exclusion plus transactional locking/optimistic conflicts. | `TODO` | — | — |
| I3-ATT-04 | Prove request-time and scheduler equivalence at checkout/correction boundaries and both expiry windows. | Pre-cutoff correction rejection; inclusive submission deadline; delayed/repeated scheduler produces one final transition. | `TODO` | — | — |
| I3-ATT-05 | Complete terminal-Intern and date-classification edge cases. | Terminal date with/without attendance, approved leave, and global day off. | `TODO` | — | — |
### 6.5 `work/reports-ui`
| ID | Deliverable | Test/evidence emphasis | Status | Owner/date | Result/commit |
|---|---|---|---|---|---|
| I3-UI-01 | Export attendance/compliance and Project/Task datasets to XLSX. | Parse workbook and compare filters, rows, totals, and `N/A` with HTML. | `TODO` | — | — |
| I3-UI-02 | Export the same datasets to PDF through a print-safe template and embedded Unicode font. | Vietnamese sample text and HTML/XLSX/PDF total parity. | `TODO` | — | — |
| I3-UI-03 | Complete desktop light/dark themes and all required desktop screens/states. | Theme before paint, system override, contrast, error/empty/stale/unavailable states. | `TODO` | — | — |
| I3-UI-04 | Complete WCAG-focused keyboard, focus, labels, icon names, and chart alternatives. | Web/accessibility evidence for representative critical pages. | `TODO` | — | — |
| I3-UI-05 | Add critical end-to-end flows across the integrated application. | Bootstrap/onboarding, Project/Task, attendance/correction/leave, and reports. | `TODO` | — | — |
| I3-UI-06 | Perform best-effort narrow-screen smoke checks only. | Prevent catastrophic corruption where practical; no mobile parity or mobile mockup gate. | `TODO` | — | — |
### 6.6 Iteration 3 integration gate
Integration order:
1. `work/platform`
2. `work/projects`, `work/tasks`, and `work/attendance` after their platform dependencies are available
3. `work/reports-ui`
Exit demonstration:
- Historical results and checkout cutoffs remain stable after later policy/calendar changes.
- Concurrent bootstrap, invitation/direct-add, membership exit/transfer, leadership, Task, leave, and correction operations fail safely.
- HTML, XLSX, and PDF expose identical authorized totals.
- Production refuses unsafe origin, proxy, datasource, or master-key configuration.
- The same non-root image works with bundled and external PostgreSQL.
- Work branches verify without publishing; only `main` publishes immutable SHA and convenience tags.
- SSH deployment remains dormant without secrets or an explicit enable variable.
- Desktop light/dark and accessibility acceptance passes; mobile/tablet remains best-effort only.
- Full integrated tests pass at the final integration commit.
## 7. Mandatory TDD workflow
Every feature follows this sequence:
1. Select a requirement and acceptance scenario.
2. Write the smallest behavioral test.
3. Run it and confirm the intended RED failure.
4. Record the RED command/result in the appropriate evidence file.
5. Write the minimum production code required for GREEN and add its meaningful Javadoc in the same implementation milestone.
6. Run the focused test.
7. Run the affected module/integration/web suite.
8. Refactor without weakening assertions.
9. Run the affected suite again.
10. Record final commands/results and commit SHA.
Recommended history:
```text
test(attendance): prove 09:00 check-in grace boundary [RED]
feat(attendance): enforce inclusive check-in grace boundary [GREEN]
```
The RED and GREEN commits may be pushed together after the branch head is green. The failing historical commit proves test-first order without leaving the remote branch intentionally broken.
Required evidence locations:
| Test level | Evidence directory |
|---|---|
| Unit/state/calculation | `docs/tests/unit/` |
| PostgreSQL/module integration | `docs/tests/integration/` |
| MockMvc/Thymeleaf/security web behavior | `docs/tests/web/` |
| Cross-module/browser journey | `docs/tests/e2e/` |
Every evidence Markdown record must include:
- requirement and scenario IDs;
- protected behavior and why it matters;
- test method and hand-derived expected result;
- exact RED command and relevant failure;
- exact GREEN and affected-suite commands/results;
- external dependency or environment boundaries;
- final commit SHA when available.
Javadoc is part of production implementation, not a later documentation phase. Every new or materially changed production type and every declared public/protected method shall document its business contract, including non-obvious authorization, transaction/locking, lifecycle/history, unit, timezone, or deadline semantics. Do not add prose that merely repeats names. Iteration 1 alone may retrofit Javadocs after feature implementation is complete; those branch-owned retrofit commits still require affected verification and independent scoped re-review. Every later iteration and turn shall add/update Javadocs during the implementation milestone.
## 8. Branch-level test emphasis
| Branch | Non-negotiable evidence |
|---|---|
| `work/platform` | Bootstrap concurrency, token lifecycle, account/security authorization, encryption, SMTP failure, session invalidation, production-profile failure. |
| `work/projects` | Lifecycle graphs, ownership, membership/invitation/exit/leadership intervals, transfer transactions, optimistic locking, guessed-ID denial. |
| `work/tasks` | Parameterized status graph, Leader/member creator/assignee distinction, self-Task and same-Project generic actors, daily-minute concurrency, progress totals. |
| `work/attendance` | Injected-Clock boundaries, PostgreSQL overlap/uniqueness, policy history, quota concurrency, schedulers and request-time guards. |
| `work/reports-ui` | MockMvc forms/authorization, accessible rendering, report query totals, XLSX/PDF parsing/parity, critical browser journeys. |
## 9. Iteration handoff protocol
At each iteration boundary:
1. Each branch owner updates every claimed item to `DONE`, `BLOCKED`, or returns it to `TODO`.
2. The owner provides commit SHA, evidence paths, exact verification commands, and remaining risk.
3. Integrate branches in the iteration's declared order.
4. Resolve cross-module conflicts through the owning branch rather than duplicating code in the integrator.
5. Run the full affected integrated suite.
6. Record the integration commit in Section 3.
7. Bring the integrated `main` into all five persistent work branches before the next iteration begins.
Handoff template:
```markdown
### <tracker ID> — <short title>
- Status: DONE | BLOCKED | TODO
- Owner:
- Requirements/scenarios:
- RED evidence:
- GREEN evidence:
- Focused verification:
- Affected-suite verification:
- Commit SHA:
- Remaining risk/blocker:
- Required next owner/action:
```
## 10. Global definition of done
A tracker item is complete only when:
- the numbered requirement and acceptance behavior are satisfied;
- the test existed and failed for the intended reason before production code;
- focused and affected suites pass;
- authorization and negative cases are covered where applicable;
- PostgreSQL-specific rules are tested against PostgreSQL, not H2;
- concurrency/deadline/history behavior has proportionate evidence;
- UI behavior uses server-side authorization and shared fragments;
- documentation/evidence paths are recorded in this tracker;
- new or changed production types and public/protected methods have accurate Javadoc created during implementation (Iteration 1 retrofit exception only);
- no unrelated files or another branch's ownership area were changed without coordination;
- the final branch head is green;
- integration does not alter totals, state graphs, or historical meaning.
## 11. Progress log
Append material coordination events only. Do not duplicate every commit.
| Date/time | Agent/person | Event | Tracker IDs | Evidence/commit | Next action |
|---|---|---|---|---|---|
| — | — | Plan initialized; no implementation item claimed. | — | — | Obtain requirements approval and begin Iteration 1. |
| 2026-08-15 | Taskmaster + five feature owners | Retrofitted targeted Lombok boilerplate after every owner fast-forwarded to the latest `main`; all five exact heads passed independent review and the combined merge passed 201 PostgreSQL 18.4 tests, compile, Javadoc/doclint, deterministic assets, and final integration review. | Iteration 1 maintenance | Platform `c9499732`; Project `58712710`; Task `469d7e27`; Attendance `5ddbd75f`; Reporting `8500cb6e`; integrated `b764707716f54ad164547b087f658c277cf46e0f`; `docs/tests/unit/lombok-*-boilerplate.md` | Push reviewed `main`, then fast-forward all five persistent work branches before Iteration 2 work. |
@@ -0,0 +1,210 @@
---
name: orchestrate-labtimesheet-iteration
description: Use when initiating, resuming, integrating, or completing a multi-branch Lab Timesheet iteration defined by .agents/PROJECT_PLAN.md.
---
# Orchestrate a Lab Timesheet Iteration
Run the iteration continuously from repository audit through an evidence-backed local exit demonstration. Preserve the five long-lived work branches and keep business features isolated behind public services and DTOs.
## Load authority and preserve state
1. Read the repository `AGENTS.md`, `.agents/PROJECT_PLAN.md`, `PRODUCT.md`, `DEVELOPMENT.md`, `TESTING.md`, and the applicable numbered requirements in `labtimesheet-docs-hub/requirements-specification.md`.
2. Apply authority in this order: current user decisions, numbered requirements, approved plan, tests/code, then inference.
3. Inspect every worktree and the root `git status` before mutation. Record and preserve unrelated dirty or untracked files.
4. Confirm the actual Maven, Spring Boot, Java, Node, PostgreSQL, Flyway, and Testcontainers versions. Use the documented project baseline even if a newer JDK is installed.
5. Create or update the active goal and plan only when the user requests goal-mode execution.
## Enforce the project structure
Keep `LabtimesheetApplication` in `com.lab.labtimesheet`, shared wiring in `config`, and business code under:
```text
feature.account
feature.integration
feature.project
feature.task
feature.attendance
feature.notification
feature.reporting
```
Repeat only the layers a feature needs: `controller`, `model`, `model.dto`, `model.entity`, `repository`, `service`, and `exception`. Mirror these packages in tests.
- Call another feature only through its concrete public service methods and DTOs.
- Never import another feature's repository or JPA entity.
- Use Spring Data JPA for business persistence.
- Limit direct SQL to Flyway and schema/catalog verification.
- Do not add empty `common`, `core`, `utils`, or boundary-placeholder packages.
- Do not add one-implementation interfaces, shadow mappings of foreign tables, or speculative abstractions.
Use the installed Lombok processor as the default for safe Java boilerplate:
- `@RequiredArgsConstructor` for injection-only constructors with required final dependencies;
- targeted `@Getter`, `@Setter`, and protected `@NoArgsConstructor` instead of blanket `@Data`;
- no generated JPA entity `equals`, `hashCode`, or `toString` over mutable state, associations, or secrets;
- records remain records for immutable DTOs and commands;
- explicit constructors and methods remain when they validate, normalize, enforce invariants, preserve history, define identity, or select qualified dependencies.
Require each owner to audit its production package, record a source-contract RED for eligible handwritten boilerplate, make the smallest behavior-preserving Lombok conversion, and prove compile/Javadoc, Spring injection, JPA mapping, template property access, and affected behavior remain green. Do not add annotations that generate unused API.
## Establish the shared baseline first
Before dispatching feature work:
1. Verify the Maven wrapper, application profile, Flyway baseline, PostgreSQL connectivity, test-only clock/encryption, and frontend asset toolchain.
2. Run a clean baseline test and capture any pre-existing failure separately.
3. Run the application locally against a disposable or dedicated PostgreSQL service. A PostgreSQL or Mailpit test container is acceptable; do not containerize the application when the exit gate says local process.
4. Commit the shared platform foundation before dependent branches use it.
5. Hand off only full immutable commit SHAs from clean worktrees.
## Own five branches and worktrees
Use exactly these persistent branches unless the user changes the plan:
| Branch | Ownership |
|---|---|
| `work/platform` | Baseline, migration, accounts, security, bootstrap, integrations, notification plumbing |
| `work/projects` | Projects, membership, leadership, lifecycle, project authorization |
| `work/tasks` | Tasks, comments, work logs, status, task progress |
| `work/attendance` | Policy, calendar, attendance, corrections, leave, metrics |
| `work/reports-ui` | Shared Thymeleaf UI, dashboards, reports, exports |
Create one isolated worktree per branch. Give each implementation agent explicit ownership, tell it other agents share the repository, forbid reverting others' work, require medium-milestone local commits, and forbid push unless separately authorized.
Before any owner edits its module, require it to:
1. verify its worktree has no uncommitted changes;
2. confirm the taskmaster's exact latest `main` SHA;
3. fast-forward its persistent work branch to that SHA with `git merge --ff-only main`;
4. prove `git rev-parse HEAD` equals the supplied main SHA;
5. stop rather than resolving unexpected divergence or overwriting user work.
Store durable coordination under `.superpowers/sdd/PROJECT_PLAN/`:
- `progress.md` with exact SHAs, dependency pins, tests, blockers, and review rounds;
- one task report per branch;
- review packages and reviewer reports.
Trust this ledger and Git history after context compaction. Never redispatch a completed milestone.
## Require RED, GREEN, Javadoc, and companion evidence
For every behavior:
1. Read its requirement and acceptance scenario IDs.
2. Write the narrowest production-shaped test first.
3. Run it and record RED for the expected missing behavior, not an environment or test defect.
4. Implement the minimum coherent change and its meaningful Javadoc in the same milestone. Document every new or materially changed production type and declared public/protected method, emphasizing business contracts, authorization, transactions/locking, state/history semantics, units, and time boundaries rather than restating names.
5. Run focused GREEN, affected-suite verification, then the branch-wide suite.
6. Refactor only while tests remain green.
7. Commit when a medium milestone is complete.
Use PostgreSQL 18.4 Testcontainers for persistence semantics; do not substitute H2. Keep time and randomness controllable. Test public outcomes, persisted state, authorization denial, and boundary cases.
Create a Markdown evidence record under the matching directory:
```text
docs/tests/unit/
docs/tests/integration/
docs/tests/web/
docs/tests/e2e/
```
Start from that directory's `_TEMPLATE.md`. Every record must include requirement/scenario IDs, protected behavior, test method, hand-derived expected result, exact RED command/result, exact GREEN and affected-suite commands/results, implementation milestone, and external-test boundaries. Never replace executable evidence with a verbal claim.
Iteration 1 is the only retrofit exception: after all feature tasks finish, return each branch to its original owner to add missing Javadocs before integration, rerun affected verification, commit, and undergo scoped re-review. In every later iteration or turn, reject delayed Javadoc cleanup; it belongs in the implementation milestone.
## Merge dependencies by immutable pin
Derive the dependency graph from the current iteration plan. For Iteration 1, use:
```text
platform foundation
-> projects base
-> attendance
-> tasks (projects + attendance public APIs)
-> projects activation guard (final Task query API)
-> reports-ui (final public dashboard APIs)
```
- A producer reports a clean full SHA and public API before a consumer merges it.
- Never merge a moving branch or a short ambiguous SHA.
- Preserve dirty consumer work during the merge and immediately rerun its structure test.
- If a consumer needs data, add the smallest producer-owned public query DTO/service method; never map or query the producer's tables locally.
- Keep final integration order from `.agents/PROJECT_PLAN.md` even when development dependencies require a temporary producer/base round trip.
- Reuse the last reviewed consumer branch as the integrated candidate when it already contains every approved producer pin in order. An extra integration branch adds no safety by itself.
- After a Platform merge, run the architecture test and every `@WebMvcTest` controller slice. Global advice and shared beans can invalidate otherwise unrelated slice fixtures; fix only the test fixture, never production security to accommodate a slice.
## Coordinate agents without losing control
Let the five owners work in parallel where dependencies permit. Resolve normal in-scope questions without pausing the run. Stop only for a genuine blocker, consequential ambiguity, destructive action, or sensitive external effect requiring user approval.
For a sensitive action, state the exact effect and obtain approval in the root task. If a child cannot inherit that approval, the root may apply only the isolated approved patch; return the worktree to its owner for tests, evidence, self-review, and commit.
Do not accept an agent's completion claim alone. Require:
- exact branch and full SHA;
- clean worktree;
- focused, affected, and full test counts;
- confirmation that new/changed production APIs carry accurate Javadoc;
- a list of Lombok conversions and explicit boilerplate deliberately retained with its business reason;
- evidence/report path;
- public API handoff;
- blockers and unverified boundaries;
- confirmation of no push.
## Review only after all five owners finish
After every implementation owner reports `DONE`, dispatch independent code-review assignments, one branch per assignment. Give each reviewer the plan/requirements paths, branch report, ledger, merge base, full diff package, and exact structure/TDD constraints.
Each review must return both spec-compliance and code-quality verdicts with file/line evidence. For Critical or Important findings:
1. Send the complete finding list back to that branch's original owner.
2. Require a focused regression test, RED when applicable, GREEN, affected suite, evidence update, and a fix commit.
3. Dispatch an independent scoped re-review of only the fix range.
4. Repeat up to five rounds; use a fresh stronger fixer for rounds four and five.
5. At the cap, record a reasoned ruling for non-load-bearing findings or stop on a load-bearing blocker.
Do not merge a branch with unresolved load-bearing findings.
## Prove the iteration exit gate
Integrate only reviewed immutable branch SHAs in the plan's order. Then verify from the integrated tree:
1. `git diff --check` and package/JPA architecture tests.
2. Flyway replay against fresh PostgreSQL and the required table/foreign-key catalogue checks.
3. Full Maven tests on the documented Java version and PostgreSQL engine.
4. Frontend asset build on the pinned Node version.
5. A local application process connected to the configured PostgreSQL service.
6. Health/readiness and the iteration's real role-correct web workflow.
7. No application containerization when explicitly deferred.
8. Root dirty-state preservation, clean reviewed worktrees, and no unauthorized push.
Keep environment authority explicit:
- real `.env` files are local and ignored;
- `.env.example` contains placeholders only;
- the development Spring profile maps every required runtime value from the environment;
- Admin-console SMTP and HolidayAPI secrets never move into `.env`;
- configuration-only work uses a shell/configuration RED and real application smoke test instead of an artificial Java unit test.
If SMTP participates in health, exercise both states deliberately: application startup with SMTP deferred, and aggregate health with a real temporary Mailpit connection. Report the distinction instead of calling one state universally healthy.
Store cross-module browser journeys in `docs/tests/e2e/`. Before completion, update every Iteration row and the durable progress ledger; stale `IN_PROGRESS` rows are an incomplete gate even when tests pass.
Review source Javadocs against behavior as part of the branch and integration diff; stale or content-free Javadoc does not satisfy the gate.
## Merge reviewed Iteration work to main
Only enter this phase with explicit user authority.
1. Add any final environment example, profile configuration, implementation-status README, development guide, and testing/TDD guide to the integrated candidate under RED/GREEN evidence.
2. Run the complete PostgreSQL suite and a real local-process smoke test on that exact candidate.
3. Fetch the remote base. Stop on unexpected divergence; never force-push to hide it.
4. Preserve unrelated dirty root files. Commit only separately authorized tracked root guidance before merging if the incoming branch also changes that file.
5. Merge the exact candidate into `main` without squashing or rewriting the reviewed branch history.
6. Rerun the full suite on merged `main`, inspect the diff, and verify `.env` is ignored and absent from the index.
7. Push `main` normally, verify the remote ref equals local `HEAD`, and keep host-managed worktrees unless cleanup was explicitly requested.
Record the integration SHA, commands, outputs, limitations, and deferred next-iteration scope. Mark the goal complete only after every stated exit condition has fresh evidence.
@@ -0,0 +1,4 @@
interface:
display_name: "Orchestrate Lab Timesheet Iteration"
short_description: "Run five-branch TDD and Javadoc delivery"
default_prompt: "Use $orchestrate-labtimesheet-iteration to execute the current iteration across the five work branches with TDD, Javadoc, and review gates."
+1 -1
View File
@@ -1,4 +1,4 @@
# Copy to .env, replace every placeholder, then load it into the IDE or shell.
# Copy to .env and replace every placeholder. The dev profile imports it from the repository root.
SPRING_PROFILES_ACTIVE=dev
LAB_SERVER_PORT=8080
LAB_FORWARD_HEADERS_STRATEGY=NONE
-10
View File
@@ -34,15 +34,5 @@ node_modules/
### VS Code ###
.vscode/
### Agentic ###
.agents/
.agent/
AGENTS.md
# Local requirements review artifacts
/labtimesheet-docs-hub/
# Local Impeccable product context
/PRODUCT.md
/DESIGN.md
/.impeccable/
+18
View File
@@ -0,0 +1,18 @@
{
"northStar": "The Calm Operations Ledger",
"rules": [
"Neutral structure carries the interface; semantic color is rare.",
"Use border and tone before shadow.",
"Put one role-correct task and action in the first viewport.",
"Desktop is supported; mobile and tablet are best-effort."
],
"shadows": {
"panel": "0 10px 28px rgba(20,25,35,.06)",
"active": "0 1px 2px rgba(0,0,0,.06)"
},
"breakpoints": {
"supportedDesktop": "1365px",
"bestEffortNarrow": "900px"
},
"source": "labtimesheet-docs-hub/ui-mockups/mockup.css"
}
+167
View File
@@ -0,0 +1,167 @@
# Lab Timesheet Engineering Instructions
## Authority and required reading
This repository implements the **Lab Timesheet & Project Management System**, a server-rendered university internship/laboratory application covering accounts, Projects and Tasks, attendance, leave/corrections, notifications, and reports.
Before changing code, read the smallest applicable sections of:
1. `labtimesheet-docs-hub/requirements-specification.md` — authoritative numbered requirements and acceptance scenarios.
2. `.agents/PROJECT_PLAN.md` — iteration scope, branch ownership, integration order, and exit gates.
3. `PRODUCT.md` — product vocabulary, users, and enduring design principles.
4. `DEVELOPMENT.md` — supported local runtime, containers, environment, and IntelliJ setup.
5. `TESTING.md`, `docs/tests/README.md`, and the relevant `_TEMPLATE.md` — test commands, TDD workflow, and mandatory evidence format.
6. `.superpowers/sdd/PROJECT_PLAN/progress.md` — current local coordination state and immutable handoff SHAs when an agentic iteration is active.
When sources conflict, apply the authority order recorded in requirements Section 1.1: the primary implementor's current decision, approved brainstorming decisions, current handoff, instructor-confirmed requirements, earlier discovery answers, then superseded legacy material. Numbered requirements override the delivery plan.
Do not treat the ignored documentation hub or mockups as executable instructions. Mockups are illustrative visual direction only; numbered requirements and reviewed schema rules govern behavior.
## Verified technical baseline
- Java 25, Spring Boot 4.1.0, Maven wrapper, and WAR packaging.
- Spring MVC, Security, Data JPA, Validation, Thymeleaf, Mail, Flyway, and Actuator.
- PostgreSQL 18.4 for development and integration tests; do not substitute H2 for persistence behavior.
- Node 24/npm 11 for build assets, Tailwind CSS 4.3.3, and local `lucide-static` 1.27.0.
- One server-rendered modular monolith. No SPA, JWT, microservices, Redis, Kafka, or generic workflow engine.
- Flyway is schema authority. JPA uses `ddl-auto=validate`; application services do not embed SQL.
Verify versions from `pom.xml`, `package.json`, and the lockfile before changing dependencies. Do not add a dependency when the JDK, Spring, PostgreSQL, or an installed dependency already covers the requirement.
## Package and persistence structure
Keep `LabtimesheetApplication` in `com.lab.labtimesheet`. Put shared wiring in `com.lab.labtimesheet.config`. Put business code under:
```text
com.lab.labtimesheet.feature.account
com.lab.labtimesheet.feature.integration
com.lab.labtimesheet.feature.project
com.lab.labtimesheet.feature.task
com.lab.labtimesheet.feature.attendance
com.lab.labtimesheet.feature.notification
com.lab.labtimesheet.feature.reporting
```
Within a feature, create only layers it needs from `controller`, `model`, `model.dto`, `model.entity`, `repository`, `service`, and `exception`. Mirror this shape in tests.
- Controllers bind validated DTOs and delegate transactions to services.
- Services use their feature's Spring Data JPA repositories and models.
- Cross-feature calls use concrete public services and DTOs only.
- Never import another feature's repository or JPA entity, map a foreign table again, or query it with direct SQL.
- Direct SQL is limited to Flyway and schema/catalog verification.
- Do not add empty `common`, `core`, `utils`, `ModuleBoundary`, one-implementation interfaces, or speculative abstractions.
- Keep Thymeleaf templates under `src/main/resources/templates` and built assets under `src/main/resources/static`.
Preserve the domain boundaries: attendance time never derives Task work time; historical policies, memberships, leadership, creator/assignee attribution, and decisions do not silently move when current configuration changes.
## Lombok is the default for Java boilerplate
Lombok is already installed and configured as an annotation processor. Use it by default when it removes mechanical Java without hiding a business rule.
- Use `@RequiredArgsConstructor` for Spring controllers, services, configuration classes, and other components whose constructor only assigns required `final` dependencies. Keep an explicit constructor when it validates input, transforms data, selects among same-typed beans, or documents a non-trivial public contract.
- Use targeted annotations such as `@Getter`, `@Setter`, `@NoArgsConstructor`, and `@AllArgsConstructor`; use the smallest set that matches the actual API. Do not use `@Data` as a blanket shortcut.
- For JPA entities, never let Lombok generate `equals`, `hashCode`, or `toString` across entities, lazy associations, mutable fields, or encrypted secrets. Prefer `@Getter` and `@NoArgsConstructor(access = AccessLevel.PROTECTED)`, keep domain constructors and mutation methods explicit, and add individual setters only when a framework genuinely needs them.
- Keep Java records for immutable DTOs and commands. Replacing a record with a Lombok class creates more code and is not an improvement.
- Use `@Slf4j` only when the class actually logs. Do not add builders, withers, or generated setters speculatively.
- Do not retain handwritten constructors, getters, setters, `equals`, `hashCode`, or `toString` that are purely mechanical and safely covered by the targeted Lombok annotation. Preserve explicit methods that enforce invariants, normalize values, maintain history, or define identity semantics.
- After a Lombok refactor, inspect the generated API contract, run compile/Javadoc plus the affected tests, and confirm JPA mappings, Spring injection, Thymeleaf property access, serialization, and security-sensitive redaction remain unchanged.
This rule applies during implementation, not as deferred cleanup. A source-audit RED may prove existing eligible boilerplate before a behavior-preserving Lombok refactor; the GREEN gate is the same public behavior with less handwritten code.
## Javadoc is part of implementation
Add meaningful Javadoc while implementing production Java code, in the same milestone and before its final GREEN/commit.
- Document every new or materially changed production type and every public or protected method declared in source.
- Explain business purpose and non-obvious contracts: authorization/context requirements, transaction or locking behavior, state transitions, history retention, side effects, units, timezone/deadline boundaries, and null/empty semantics.
- Keep inherited Javadoc for a true override when it fully describes the contract. Generated Lombok methods, trivial accessors, and tests do not need duplicate prose.
- Do not write comments that merely restate names or implementation steps. If a contract cannot be explained clearly, simplify the code or clarify the requirement.
- Update Javadoc whenever behavior changes; stale Javadoc is a defect.
Iteration 1 is the one approved retrofit exception: feature owners add missing Javadocs after their implementation tasks finish, then rerun affected verification and undergo scoped re-review. Every later iteration and turn must add Javadocs during implementation, not as cleanup.
## Mandatory TDD and evidence
Use strict RED → GREEN → affected-suite verification → refactor:
1. Select requirement and acceptance-scenario IDs.
2. Write the smallest production-shaped failing test.
3. Run it and prove the RED is the missing behavior, not a broken fixture or environment.
4. Record the exact RED command/result in the matching evidence file.
5. Implement the minimum behavior and its Javadoc.
6. Run focused GREEN, then the affected suite; refactor only while green.
7. Update evidence with exact commands/results and external boundaries.
8. Commit a medium-sized green milestone locally.
Evidence belongs under:
```text
docs/tests/unit/
docs/tests/integration/
docs/tests/web/
docs/tests/e2e/
```
Copy the directory's `_TEMPLATE.md`; do not invent a second format. PostgreSQL-specific behavior uses PostgreSQL 18.4 Testcontainers. Security, ownership, concurrency, deadlines, and history require negative and boundary tests proportionate to risk.
## Five-branch ownership and subagent workflow
The persistent implementation branches are:
| Branch | Primary ownership |
|---|---|
| `work/platform` | Maven/app baseline, Flyway, accounts/security/bootstrap, integrations/notifications, container and CI assets |
| `work/projects` | Projects, membership/leadership intervals, invitations/exits, lifecycle, Project authorization |
| `work/tasks` | Tasks, actor/assignee rules, comments, work logs, status, progress |
| `work/attendance` | Policy/calendar, attendance, corrections, leave, schedulers, metrics |
| `work/reports-ui` | Shared Thymeleaf UI, dashboards, reports/exports, UI/accessibility consistency |
For a multi-branch iteration:
- Use one worktree and one named owner/subagent per branch. Tell every owner that other agents share the repository and it must not revert others' work.
- Before starting assigned module work, every owner verifies its worktree is clean, fetches or uses the taskmaster-verified latest `main`, and fast-forwards its persistent branch to that exact main SHA. Do not build new work on a stale pre-integration branch, and do not use a merge that would rewrite or discard branch history.
- Establish and commit the platform foundation before dependent persistence work.
- Exchange only full immutable SHAs from clean worktrees; never merge a moving branch or ambiguous short SHA.
- Preserve branch ownership. Request a producer-owned service/DTO boundary instead of reading its tables from a consumer.
- Commit each medium green milestone locally. Do not push, publish, deploy, force, rewrite history, or merge to `main` without explicit authority.
- After all five owners report DONE, run independent read-only reviews of every branch. Return Critical/Important findings to the original owner with a regression test where applicable, GREEN evidence, a fix commit, and scoped re-review. Do not integrate unresolved load-bearing findings.
- Integrate reviewed exact heads only in the current iteration's order from `.agents/PROJECT_PLAN.md`, then run the full integrated exit gate.
Keep durable coordination under `.superpowers/sdd/PROJECT_PLAN/`: progress ledger, branch reports, review findings, immutable SHAs, commands/results, blockers, and integration evidence. Do not redispatch completed milestones after context compaction.
## Local commands and runtime
Default development expects PostgreSQL on port `55432`; override with `LAB_DB_URL`, `LAB_DB_USERNAME`, and `LAB_DB_PASSWORD`. SMTP defaults to localhost Mailpit port `1025` and can be overridden with `LAB_SMTP_HOST`/`LAB_SMTP_PORT`. Never commit real secrets.
```bash
export JAVA_HOME=/opt/homebrew/opt/openjdk@25
export PATH="$JAVA_HOME/bin:$PATH"
./mvnw test
npm ci
npm run build
./mvnw spring-boot:run
```
When using local OrbStack Testcontainers, set the actual Docker socket for that machine. Tests must not depend on the developer database or a real SMTP server.
Before completion, run focused tests, the affected suite, the full suite appropriate to the branch, frontend build when assets changed, `git diff --check`, and an adversarial diff review. The integrated iteration additionally requires Flyway/PostgreSQL validation and a real local Java process connected to PostgreSQL; an application container does not substitute for that gate when containerization is deferred.
## Post-iteration integration and push
- Use the final reviewed consumer branch as the integration candidate when it already contains every approved producer SHA in plan order; do not create an extra integration branch without a concrete need.
- Keep real `.env` files untracked. Commit only `.env.example` placeholders and environment-backed Spring profile configuration. SMTP and HolidayAPI credentials managed by the Admin console do not belong in `.env`.
- Keep `README.md`, `DEVELOPMENT.md`, and `TESTING.md` aligned with the merged application. Document only commands and workflows that were exercised or directly verified.
- Configuration and README changes made after feature review still require a configuration-contract RED, focused GREEN, the complete PostgreSQL suite, `git diff --check`, and a local-process smoke test before merging.
- A global MVC advice or shared configuration bean can affect every `@WebMvcTest` slice. After merging Platform changes, run all controller slices and add only the missing test fixture bean; do not weaken the production advice.
- Record real cross-module browser journeys under `docs/tests/e2e/`, not `docs/tests/web/`, and update `.agents/PROJECT_PLAN.md` plus the progress ledger before declaring the iteration complete.
- Before merging to `main`, fetch its upstream and stop if the remote moved unexpectedly. Preserve unrelated root changes, stage only authorized paths, merge without rewriting history, rerun the full suite on the exact merged tree, then push normally and verify the remote SHA.
- Worktrees under `/private/tmp` are host-managed. Keep the five branch worktrees and branches after integration unless the user explicitly requests cleanup.
## Safety and scope
- Inspect `git status` before editing and preserve unrelated dirty/untracked files.
- Use server time and an injectable `Clock` for deadline behavior; never trust browser event timestamps.
- Keep CSRF, authorization, password hashing, validation, and ownership checks active in every environment.
- Never print, persist, or return raw activation/reset tokens except the approved immediate delivery path; persist only their hashes.
- Desktop is the supported UI target. Mobile responsiveness is best-effort and has no mockup/parity gate.
- Iteration scope is exact. Leave later-iteration capabilities TODO rather than adding placeholders or partial frameworks.
+192
View File
@@ -0,0 +1,192 @@
---
name: Lab Timesheet
description: A quiet, high-density operations system for internship attendance and Project work.
colors:
ink: "#15171a"
canvas: "#f6f7f8"
sidebar: "#f0f1f2"
panel: "#ffffff"
panel-muted: "#f7f8f9"
border: "#dfe1e5"
border-strong: "#c9cdd3"
text-muted: "#626a75"
text-subtle: "#818894"
accent: "#3157e7"
success: "#087a48"
warning: "#996000"
danger: "#b42318"
typography:
headline:
fontFamily: "ui-sans-serif, -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif"
fontSize: "25px"
fontWeight: 700
lineHeight: 1.2
letterSpacing: "-0.025em"
body:
fontFamily: "ui-sans-serif, -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif"
fontSize: "14px"
fontWeight: 400
lineHeight: 1.45
label:
fontFamily: "ui-sans-serif, -apple-system, BlinkMacSystemFont, Segoe UI, sans-serif"
fontSize: "11px"
fontWeight: 650
lineHeight: 1.45
rounded:
control: "8px"
tab: "9px"
surface: "12px"
dialog: "14px"
spacing:
xs: "4px"
sm: "8px"
md: "16px"
lg: "24px"
components:
button-primary:
backgroundColor: "{colors.ink}"
textColor: "{colors.panel}"
rounded: "{rounded.control}"
padding: "8px 13px"
height: "37px"
input:
backgroundColor: "{colors.panel}"
textColor: "{colors.ink}"
rounded: "{rounded.control}"
padding: "9px 10px"
height: "39px"
panel:
backgroundColor: "{colors.panel}"
textColor: "{colors.ink}"
rounded: "{rounded.surface}"
---
# Design System: Lab Timesheet
## Overview
**Creative North Star: "The Calm Operations Ledger"**
Lab Timesheet is a permission-aware operations workspace. It favors legible state, compact controls, clear ownership, and reviewable records over decorative dashboard theater. The Vercel/shadcn-style reference is translated into server-rendered Thymeleaf surfaces with a stable shell and one role-correct task per page.
The visual system is quiet but not empty: thin structure, disciplined spacing, tabular data, and rare semantic color make consequential actions and deadlines easy to find. Example content must always be identified as illustrative.
**Key Characteristics:**
- Cool near-white surfaces with charcoal text.
- Fixed desktop sidebar and compact page header.
- Dense tables and direct forms as the main working surfaces.
- Black primary actions; color reserved for focus, status, warning, and error.
- Rounded corners and restrained ambient shadow, never floating card mosaics.
## Colors
The light palette uses cool neutral layers; dark mode must be designed from the supplied near-black references rather than mechanically inverted from these values.
### Primary
- **Operational Ink** (`#15171a`): primary text, brand mark, and primary actions.
- **Controlled Accent** (`#3157e7`): focus, selected data, and rare contextual emphasis.
### Neutral
- **Work Canvas** (`#f6f7f8`): page background.
- **Navigation Shell** (`#f0f1f2`): desktop sidebar.
- **Record Surface** (`#ffffff`): forms, tables, panels, and active navigation.
- **Muted Surface** (`#f7f8f9`): headers, tabs, and supporting rows.
- **Ledger Border** (`#dfe1e5`): default one-pixel structure.
- **Control Border** (`#c9cdd3`): inputs and action outlines.
- **Muted Text** (`#626a75`) and **Subtle Text** (`#818894`): secondary and tertiary copy.
### Semantic
- **Success** (`#087a48`), **Warning** (`#996000`), and **Danger** (`#b42318`) communicate state with text and shape, never color alone.
**The Rare Color Rule.** Neutral structure carries the interface. Semantic and accent colors appear only when they clarify state, focus, validation, or a consequential decision.
## Typography
**Display and Body Font:** the local system sans stack (`ui-sans-serif`, platform UI fonts, `Segoe UI`, sans-serif). No remote font is required.
**Character:** compact, familiar, and operational. Weight and spacing establish hierarchy without oversized marketing display type.
### Hierarchy
- **Page headline** (700, `25px`, 1.2): one per screen.
- **Panel title** (600700, `14px`): names the current dataset or decision surface.
- **Body** (400, `14px`, 1.45): instructions and explanatory copy, normally no wider than 72ch.
- **Data** (500650, `12px`): dense tables and facts; numeric summaries use tabular numerals.
- **Label** (650, `11px`): fields and supporting metadata.
- **Navigation group label** (750, `10px`, uppercase, `0.08em`): rare structural labels only.
**The One Headline Rule.** Each screen gets one page headline; hierarchy below it is compact and task-oriented.
## Layout
Desktop is the supported product target. The shell uses a 236px sidebar and a minimum-width content column, with a 60px header and 2426px content inset. The implementation target may round the sidebar to approximately 16rem and its collapsed rail to approximately 4rem.
Content uses a four-cell metric strip, full-width table/form panels, and an occasional two-column decision or form/detail layout. The primary record or decision remains in the first viewport at 1365×900. Tables may scroll horizontally inside their own region but must not create page-level overflow.
Mobile and tablet responsiveness is best-effort only. It may reflow or scroll to avoid preventable breakage, but it is not required to provide complete workflow parity and has no dedicated mockup set.
## Elevation & Depth
Structure comes primarily from surface contrast and one-pixel borders. The only recurring ambient shadow is a soft panel lift (`0 10px 28px rgba(20,25,35,.06)`); active navigation and tabs use a smaller `0 1px 2px` shadow. Deep stacks and card-within-card effects are not part of this world.
**The Flat-First Rule.** Use border and tone before shadow. Shadow confirms grouping; it does not turn every region into a floating card.
## Shapes
Controls use an 8px radius, segmented containers 9px, primary panels 12px, and centered dialogs 14px. Status badges may be fully rounded because their small silhouette communicates state. Larger containers are not pill-shaped. Borders are neutral and one pixel.
## Components
### Buttons
- **Primary:** Operational Ink background, white text, 8px radius, 37px minimum height.
- **Secondary:** white background, stronger neutral border, same geometry.
- **Danger:** pale danger surface with explicit consequence copy; destructive actions require confirmation.
- **Focus:** visible high-contrast focus treatment is mandatory in implementation.
### Tables and panels
- Panels use white surface, one-pixel border, 12px radius, and optional ambient shadow.
- Table headers use muted surface, compact uppercase labels, and stable desktop columns.
- Status is shown with a text badge plus a non-color cue.
- Empty, unavailable, stale, and access-denied states replace the table body with direct operational copy.
### Inputs and forms
- Fields use white surface, stronger neutral border, 8px radius, and 39px minimum height.
- Labels stay visible; placeholder text never replaces a label.
- Validation preserves safe input, associates field errors, and adds a form-level error summary.
- Form actions appear once, at the end of the form; list/detail actions live in the page header.
### Navigation
- The desktop sidebar shows only authorized destinations.
- Active navigation uses a white surface and ink text without a colored stripe.
- The lower account area exposes profile, theme, and logout.
- Icon-only collapsed navigation requires accessible names and tooltips.
### Metric strips and tabs
- Metric strips are one bounded row divided by one-pixel rules, not separate floating cards.
- Tabs are compact segmented controls; a tab labels a true view switch, not a decorative category badge.
## Do's and Don'ts
### Do:
- **Do** put the users current task, deadline, record state, and authorized action in the first viewport.
- **Do** use server-authoritative dates/times and honest illustrative-data labels.
- **Do** keep role, ownership, membership, leadership, and assignee distinctions visible in copy and action placement.
- **Do** supply accessible labels, keyboard focus, error summaries, and chart text/table alternatives.
### Don't:
- **Don't** use gradients, glass effects, remote fonts, decorative charts, or oversized marketing headings.
- **Don't** use cards as the default container for every piece of content.
- **Don't** expose an action merely because the current global role sounds powerful enough; contextual authorization wins.
- **Don't** treat the desktop mockups as mobile requirements or imply mobile workflow parity.
- **Don't** invent production endorsements, adoption metrics, or unlabeled example records.
+21 -11
View File
@@ -124,18 +124,21 @@ unless you intentionally want to discard your local development data.
## 4. Run from a terminal
Load the environment file in the same terminal that will run Spring Boot:
The `dev` profile imports the ignored root `.env` file automatically. From the
repository root, run:
```bash
set -a
source .env
set +a
./mvnw spring-boot:run
```
Shell environment variables still override values from `.env`, which is useful
for a one-off local override. If you run from another working directory, set
`LAB_DEV_ENV_FILE` to the absolute path of your `.env` file.
Open:
- First-Admin setup: `http://localhost:8080/bootstrap`
- First-Admin setup: open `http://localhost:8080` and follow the automatic
redirect to `/bootstrap`.
- Login: `http://localhost:8080/login`
- Mailpit inbox: `http://localhost:8025`
@@ -177,14 +180,14 @@ Stop the application with `Control+C`.
6. Set **JRE** to Java 25.
7. Set **Active profiles** to `dev`.
8. Set **Working directory** to the repository root.
9. Open the **Environment variables** editor and add every variable from your
local `.env` file.
9. Leave **Environment variables** empty. With the repository root as the
working directory, `application-dev.yaml` imports the ignored `.env` file.
10. Apply the configuration and run it.
Some IntelliJ editions can load variables from an environment file directly.
If that option is available, select the local `.env`; otherwise use the
environment-variable table. Do not store real secrets in a shared or committed
run configuration.
If company policy requires IntelliJ to inject the values instead, select the
local `.env` in the **Environment variables** field. Environment variables take
precedence over the imported file. Do not store real secrets in a shared or
committed run configuration.
Run `npm ci` and `npm run build` in IntelliJ's terminal before the first launch
and after changing Tailwind or icon sources.
@@ -220,6 +223,13 @@ does not by itself prove that SMTP is unavailable; use the Admin SMTP test.
Check both **Project SDK** and the run configuration's **JRE**. They should both
be Java 25.
### Spring reports an unresolved `LAB_*` placeholder
Confirm the run configuration uses the repository root as its working
directory and that `.env` exists there. If the working directory must differ,
set `LAB_DEV_ENV_FILE` to the absolute `.env` path in the run configuration's
environment variables.
### Styles or icons are missing
Run:
+89
View File
@@ -0,0 +1,89 @@
# Product
<!-- impeccable:product-schema 1 -->
## Platform
web
## Stack
- Java 25 and Spring Boot 4.1.0.
- Maven-built, server-rendered Spring MVC modular monolith organized by business feature.
- Spring Security, Spring Data JPA, Bean Validation, Thymeleaf, Spring Mail, and Flyway.
- Tailwind CSS 4 with Node 24 LTS used only for frontend build assets.
- PostgreSQL 18.4 across development, integration testing, and production.
- No SPA framework, JWT authentication, microservices, Redis, Kafka, or generic workflow engine in v1.
## Users
- **Admins** operate accounts, internship lifecycles, attendance policy, the global calendar, SMTP, HolidayAPI, and system configuration. They inspect Project and attendance progress but do not perform Mentor or Project Leader work.
- **Mentors** own Projects, directly manage membership and leadership, decide membership exits, monitor Project and Intern progress, comment on Tasks, inspect attendance, and decide leave and missed-checkout corrections.
- **Interns** check in and out, request leave and missed-checkout corrections, respond to their own Project invitations, request/cancel their own Project exit, participate in multiple Projects, create self-assigned Tasks, perform assigned Tasks, comment, update their own assigned Task status, and record Task work.
- A **Project Leader** is an Intern with a current leadership term for one Project. It is contextual authority, never a global account role. The Leader may invite eligible Interns, request a member's removal, and manage Task definitions/assignment inside that Project.
- The product is reviewed and maintained by a university project team and its instructor or appointed maintainer.
## Product Purpose
Lab Timesheet supports a university laboratory or internship program by bringing account administration, attendance, leave, missed-checkout correction, Project work, Task progress, notifications, and authorized reporting into one working system.
Success means each role can complete its permitted work without spreadsheets or informal message trails, while deadlines, decisions, historical attribution, and report totals remain explainable and auditable.
## Positioning
The product joins attendance oversight and Project delivery without pretending they are the same measurement. Check-in and checkout establish attendance; dated Task work logs establish Project effort. Effective-dated policy and frozen historical allocations prevent later configuration changes from rewriting past results.
## Operating Context
- The business timezone is `Asia/Ho_Chi_Minh`; business dates use the applicable attendance-policy timezone and persisted event instants are treated as UTC.
- The system is operated as one server-rendered web application with PostgreSQL. Desktop browsers are the supported interface target; mobile and tablet behavior is best-effort and is not guaranteed to expose every workflow optimally.
- Initial installation uses a one-time first-Admin bootstrap. Later account creation and password recovery depend on a tested SMTP configuration.
- Admins may preview and import Vietnamese holiday candidates from HolidayAPI, while the stored Admin decision remains authoritative. Manual calendar management remains available.
- Mentors review global leave and correction queues and separately oversee only the Projects they own.
- Reports cover attendance/compliance and Project/Task progress in HTML, Excel, and PDF from one shared dataset definition.
- The authoritative requirements are currently a review draft. Product-context initialization does not authorize application implementation or promote the review DDL into Flyway.
## Capabilities and Constraints
- Global account roles are exactly `ADMIN`, `MENTOR`, and `INTERN`, and are immutable after account creation.
- Project membership is many-to-many and interval-based. The owning Mentor may add/remove directly and makes every exit decision; the current Leader may invite; only the intended authenticated Intern may accept/decline; members may request but cannot unilaterally leave.
- Every `PLANNED` or `ACTIVE` Project has exactly one current Intern Leader. Any active member may create a Task assigned only to themselves; only the current Leader may create for another member or reassign broader Task work.
- Each Task has one current assignee. Only that assignee changes its status and records work.
- Attendance uses server-time check-in and checkout. Effective-dated policy stores separate check-in and checkout grace periods, both defaulting to 30 minutes; with the default 15:30 end, normal checkout closes immediately after the inclusive 16:00:00 cutoff. Task work is a separate dated-minute record and never proves attendance.
- Leave is full-day. Only frozen eligible workdays consume quota, and pending or approved requests reserve it.
- Corrections apply only to missing checkout after the attendance row's historical checkout cutoff. Submission remains open through scheduled end plus 24 hours, and the Mentor then receives a separate 24-hour decision window.
- Global attendance policy is effective-dated; historical attendance and leave allocations must not drift after later policy or calendar changes.
- SMTP and HolidayAPI secrets are Admin-managed and encrypted with a deployment-provided master key. Email-dependent account actions fail closed when SMTP is unavailable; other domain actions retain in-app delivery.
- HTML, Excel, and PDF reports must agree on the same hand-checkable totals and render undefined denominators as `N/A`.
- The product language is English in v1. Displayed business dates use `dd/MM/yyyy` and times use 24-hour local time.
- Features absent from the reviewed requirements are not silently in scope.
## Brand Commitments
- The working product name is **Lab Timesheet & Project Management System**, shortened to **Lab Timesheet** where space is constrained.
- The supplied Vercel/shadcn-style operations-shell images are illustrative references for a compact permission-aware application shell with supported light and dark modes. They do not define fields, workflows, authorization, or persistence and never override numbered requirements or reviewed DDL.
- Interface copy must be direct, operational, and honest about permissions, deadlines, destructive consequences, unavailable integrations, and illustrative data.
## Evidence on Hand
- `labtimesheet-docs-hub/requirements-specification.md` is the authoritative requirements review draft.
- `labtimesheet-docs-hub/database-schema.sql` is the companion PostgreSQL design baseline, not yet a production migration.
- `labtimesheet-docs-hub/assets/ui-reference-light.png`, `ui-reference-dark-shell.png`, and `ui-reference-dark-dashboard.png` are the supplied visual references.
- The repository contains an early Spring Boot scaffold matching the recorded Java/Spring/Maven direction but no implemented product interface yet.
- No production data, customer testimonials, adoption metrics, institutional endorsements, or performance claims are available. Future design work must not fabricate them.
## Product Principles
1. **Authorization follows stored context.** Global role alone is insufficient; ownership, membership, leadership, assignment, lifecycle, and record scope determine access.
2. **History does not move.** Later policy, calendar, membership, invitation, exit decision, leadership, assignment, or assignee changes must not silently rewrite past results, Task creator attribution, or provenance.
3. **Attendance and Project work stay distinct.** The product may report them together, but one never derives or proves the other.
4. **Deadlines are enforced at every path.** Scheduled workers improve timeliness, while request-time guards preserve correctness when scheduling is late.
5. **Prefer explicit, reviewable operations.** Feature-owned controller/service/repository flows, constrained state transitions, focused integrations, and shared report datasets serve clarity over speculative machinery.
## Accessibility & Inclusion
- The web interface must meet WCAG 2.2 AA contrast and interaction requirements in both light and dark themes.
- Controls require associated labels or accessible names, visible keyboard focus, keyboard operation, and adequate target sizes.
- Status and validation cannot depend on color alone. Forms retain safe input, identify field errors, and provide an error summary.
- Charts are supplemental: every canvas requires an accessible label and an adjacent textual or tabular alternative.
- Desktop navigation and data tables must remain fully operable without page-level horizontal overflow. Mobile and tablet layouts should avoid preventable breakage on a best-effort basis but are not a fully supported v1 target.
+5 -6
View File
@@ -75,9 +75,6 @@ console, not environment variables.
```bash
cp .env.example .env
# Edit .env. Generate LAB_SECURITY_MASTER_KEY with: openssl rand -base64 32
set -a
source .env
set +a
export JAVA_HOME=/opt/homebrew/opt/openjdk@25
export PATH="/opt/homebrew/opt/node@24/bin:$JAVA_HOME/bin:$PATH"
@@ -89,10 +86,12 @@ npm run build
Development defaults to the application on port `8080`, PostgreSQL on `55432`,
and Mailpit SMTP on `1025`. The exact Spring settings are in
[`application-dev.properties`](src/main/resources/application-dev.properties).
[`application-dev.yaml`](src/main/resources/application-dev.yaml), which imports
the ignored root `.env` file when the `dev` profile is active.
On first launch, open `http://localhost:8080/bootstrap`, create the first Admin,
then configure and test SMTP or complete all five explicit deferral warnings.
On first launch, open `http://localhost:8080`; the application redirects to
`/bootstrap`, where you create the first Admin. Then configure and test SMTP or
complete all five explicit deferral warnings.
## Verification status
+2 -1
View File
@@ -225,7 +225,8 @@ Run `java -version` and `./mvnw -version`. Both should report Java 25. Set
### The application cannot start for a manual browser check
Confirm `.env` was loaded, PostgreSQL is reachable, and
Confirm the process working directory is the repository root so
`application-dev.yaml` can import `.env`, PostgreSQL is reachable, and
`LAB_SECURITY_MASTER_KEY` decodes from Base64 to 32 bytes. Automated tests do
not need this local file.
@@ -3,36 +3,47 @@
- **Test type:** Integration
- **Requirement IDs:** `OPS-001`, `OPS-004`, `SEC-013`
- **Scenario IDs:** `AC-OPS-001`, `AC-SEC-005`
- **Test class/method:** Shell configuration contract plus the full Spring Boot Maven suite
- **Implementation commit:** `4212e9cbc2791e0c733929af62503df26097431e`
- **Test class/method:** Shell configuration contract, an unsourced dev-profile startup probe, and the full Spring Boot Maven suite
- **Implementation commit:** `531c6078521341b156d69cb1013e54f65c092311`
## Protected behavior
Development starts from environment-backed datasource, encryption, public-origin, server, proxy, and local Mailpit settings without committing a real `.env` or weakening application security controls.
Development starts from datasource, encryption, public-origin, server, proxy,
and local Mailpit values in the ignored root `.env` file without requiring an
IDE-specific environment-variable copy, committing secrets, or weakening
application security controls.
## Test method
A shell contract verifies that the committed placeholder and development properties exist, the superseded YAML is absent, the real `.env` is ignored, every required environment key is represented, and every application placeholder resolves after loading the local file. The full Maven suite then exercises Spring configuration binding, Flyway, JPA validation, security, and PostgreSQL behavior.
A shell contract verifies that the committed placeholder and development YAML
exist, the superseded properties file is absent, the YAML explicitly imports
the ignored root `.env`, and every required placeholder remains represented. A
real dev-profile process is launched without sourcing `.env` to prove Spring
loads it. The full Maven suite then exercises Spring configuration binding,
Flyway, JPA validation, security, and PostgreSQL behavior.
## Hand-derived expected result
The committed tree contains `.env.example` and `application-dev.properties`, never tracks `.env`, and exposes exactly the environment inputs needed by the current application. Loading the local file gives Spring a `dev` profile, PostgreSQL connection, 32-byte Base64 encryption key, public origin, local Mailpit endpoint, server port, and explicit no-forwarded-header policy.
The committed tree contains `.env.example` and `application-dev.yaml`, never
tracks `.env`, and exposes exactly the inputs needed by the current
application. Starting the `dev` profile from the repository root, without
exporting the file, gives Spring the PostgreSQL connection, 32-byte Base64
encryption key, public origin, local Mailpit endpoint, server port, and explicit
forwarded-header policy.
## RED
**Command**
```text
required_files=(.env.example src/main/resources/application-dev.properties); failed=0; for file in $required_files; do if [ ! -f "$file" ]; then echo "MISSING $file"; failed=1; fi; done; if [ -f src/main/resources/application-dev.yaml ]; then echo 'STALE src/main/resources/application-dev.yaml'; failed=1; fi; if ! grep -qx '/.env' .gitignore; then echo 'MISSING /.env ignore rule'; failed=1; fi; exit "$failed"
/bin/zsh -lc 'config_check_failed=0; if test -e src/main/resources/application-dev.properties; then echo "STALE application-dev.properties"; config_check_failed=1; fi; if ! test -f src/main/resources/application-dev.yaml; then echo "MISSING application-dev.yaml"; config_check_failed=1; fi; if test -f src/main/resources/application-dev.yaml && ! grep -Fq "optional:file:\${LAB_DEV_ENV_FILE:.env}[.properties]" src/main/resources/application-dev.yaml; then echo "MISSING .env import"; config_check_failed=1; fi; exit "$config_check_failed"'
```
**Observed result**
```text
MISSING .env.example
MISSING src/main/resources/application-dev.properties
STALE src/main/resources/application-dev.yaml
MISSING /.env ignore rule
STALE application-dev.properties
MISSING application-dev.yaml
exit 1
```
@@ -41,15 +52,28 @@ exit 1
**Command**
```text
required_files=(.env.example src/main/resources/application-dev.properties); required_env=(SPRING_PROFILES_ACTIVE LAB_SERVER_PORT LAB_FORWARD_HEADERS_STRATEGY LAB_DB_URL LAB_DB_USERNAME LAB_DB_PASSWORD LAB_SMTP_HOST LAB_SMTP_PORT LAB_PUBLIC_ORIGIN LAB_SECURITY_MASTER_KEY); required_props=(server.port server.forward-headers-strategy spring.datasource.url spring.datasource.username spring.datasource.password spring.jpa.hibernate.ddl-auto spring.jpa.open-in-view spring.flyway.enabled spring.mail.host spring.mail.port lab.public-origin lab.security.master-key); failed=0; for file in $required_files; do if [ ! -f "$file" ]; then echo "MISSING $file"; failed=1; fi; done; if [ -f src/main/resources/application-dev.yaml ]; then echo 'STALE src/main/resources/application-dev.yaml'; failed=1; fi; if ! grep -qx '/.env' .gitignore; then echo 'MISSING /.env ignore rule'; failed=1; fi; for key in $required_env; do if ! grep -q "^${key}=" .env.example; then echo "MISSING example $key"; failed=1; fi; if ! grep -q "^${key}=" .env; then echo "MISSING local $key"; failed=1; fi; done; for property in $required_props; do if ! grep -q "^${property}=" src/main/resources/application-dev.properties; then echo "MISSING property $property"; failed=1; fi; done; set -a; source .env; set +a; decoded_bytes=$(printf '%s' "$LAB_SECURITY_MASTER_KEY" | base64 -d | wc -c | tr -d ' '); if [ "$decoded_bytes" != 32 ]; then echo "INVALID master key bytes=$decoded_bytes"; failed=1; fi; if ! git check-ignore -q .env; then echo 'LOCAL .env is not ignored'; failed=1; fi; if git ls-files --error-unmatch .env >/dev/null 2>&1; then echo 'LOCAL .env is tracked'; failed=1; fi; if [ "$failed" -eq 0 ]; then echo 'development configuration contract: PASS'; fi; exit "$failed"
/bin/zsh -lc 'dev_contract_failed=0; dev_required_files=(.env.example src/main/resources/application-dev.yaml); dev_required_env=(SPRING_PROFILES_ACTIVE LAB_SERVER_PORT LAB_FORWARD_HEADERS_STRATEGY LAB_DB_URL LAB_DB_USERNAME LAB_DB_PASSWORD LAB_SMTP_HOST LAB_SMTP_PORT LAB_PUBLIC_ORIGIN LAB_SECURITY_MASTER_KEY); dev_required_placeholders=(LAB_SERVER_PORT LAB_FORWARD_HEADERS_STRATEGY LAB_DB_URL LAB_DB_USERNAME LAB_DB_PASSWORD LAB_SMTP_HOST LAB_SMTP_PORT LAB_PUBLIC_ORIGIN LAB_SECURITY_MASTER_KEY); for dev_file in $dev_required_files; do if ! test -f "$dev_file"; then echo "MISSING $dev_file"; dev_contract_failed=1; fi; done; if test -e src/main/resources/application-dev.properties; then echo "STALE application-dev.properties"; dev_contract_failed=1; fi; if ! grep -Fq "optional:file:\${LAB_DEV_ENV_FILE:.env}[.properties]" src/main/resources/application-dev.yaml; then echo "MISSING .env import"; dev_contract_failed=1; fi; if ! grep -qx "/.env" .gitignore; then echo "MISSING /.env ignore rule"; dev_contract_failed=1; fi; for dev_key in $dev_required_env; do if ! grep -q "^${dev_key}=" .env.example; then echo "MISSING example $dev_key"; dev_contract_failed=1; fi; if ! grep -q "^${dev_key}=" .env; then echo "MISSING local $dev_key"; dev_contract_failed=1; fi; done; for dev_key in $dev_required_placeholders; do dev_placeholder="\${${dev_key}}"; if ! grep -Fq "$dev_placeholder" src/main/resources/application-dev.yaml; then echo "MISSING YAML placeholder $dev_key"; dev_contract_failed=1; fi; done; set -a; source .env; set +a; dev_decoded_key_bytes=$(printf "%s" "$LAB_SECURITY_MASTER_KEY" | base64 -d | wc -c | tr -d " "); if test "$dev_decoded_key_bytes" != 32; then echo "INVALID master key bytes=$dev_decoded_key_bytes"; dev_contract_failed=1; fi; if ! git check-ignore -q .env; then echo "LOCAL .env is not ignored"; dev_contract_failed=1; fi; if git ls-files --error-unmatch .env >/dev/null 2>&1; then echo "LOCAL .env is tracked"; dev_contract_failed=1; fi; if test "$dev_contract_failed" -eq 0; then echo "development configuration contract: PASS"; fi; exit "$dev_contract_failed"'
```
**Observed result**
```text
development configuration contract: PASS
```
A real Java 25 process loaded `.env` and `application-dev.properties`, connected to PostgreSQL 18.4, validated Flyway/JPA, and started on the environment-overridden port 18081. With temporary Mailpit on the configured SMTP port, `/actuator/health` returned HTTP 200 with `UP`, and `/login` returned HTTP 200. The process shut down and the temporary Mailpit container was removed.
An additional Java 25 process was started with all `LAB_*` and
`SPRING_PROFILES_ACTIVE` environment variables removed. It loaded the root
`.env` through `application-dev.yaml`, connected to PostgreSQL 18.4, validated
Flyway/JPA, and started successfully. The process was then stopped cleanly.
```text
env -u SPRING_PROFILES_ACTIVE -u LAB_SERVER_PORT -u LAB_FORWARD_HEADERS_STRATEGY -u LAB_DB_URL -u LAB_DB_USERNAME -u LAB_DB_PASSWORD -u LAB_SMTP_HOST -u LAB_SMTP_PORT -u LAB_PUBLIC_ORIGIN -u LAB_SECURITY_MASTER_KEY -u LAB_DEV_ENV_FILE /bin/zsh -lc 'export JAVA_HOME=/opt/homebrew/opt/openjdk@25; export PATH="$JAVA_HOME/bin:$PATH"; ./mvnw -DskipTests spring-boot:run'
No active profile set, falling back to 1 default profile: "dev"
Database: jdbc:postgresql://localhost:55432/labtimesheet (PostgreSQL 18.4)
Started LabtimesheetApplication in 4.068 seconds
Graceful shutdown complete
BUILD SUCCESS
```
## Affected suite
@@ -57,12 +81,14 @@ A real Java 25 process loaded `.env` and `application-dev.properties`, connected
**Command and result**
```text
env -u SPRING_PROFILES_ACTIVE -u LAB_SERVER_PORT -u LAB_FORWARD_HEADERS_STRATEGY -u LAB_DB_URL -u LAB_DB_USERNAME -u LAB_DB_PASSWORD -u LAB_SMTP_HOST -u LAB_SMTP_PORT -u LAB_PUBLIC_ORIGIN -u LAB_SECURITY_MASTER_KEY /bin/zsh -lc 'export JAVA_HOME=/opt/homebrew/opt/openjdk@25; export PATH=/opt/homebrew/opt/node@24/bin:$JAVA_HOME/bin:$PATH; export DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock; ./mvnw test'
env -u SPRING_PROFILES_ACTIVE -u LAB_SERVER_PORT -u LAB_FORWARD_HEADERS_STRATEGY -u LAB_DB_URL -u LAB_DB_USERNAME -u LAB_DB_PASSWORD -u LAB_SMTP_HOST -u LAB_SMTP_PORT -u LAB_PUBLIC_ORIGIN -u LAB_SECURITY_MASTER_KEY -u LAB_DEV_ENV_FILE /bin/zsh -lc 'export JAVA_HOME=/opt/homebrew/opt/openjdk@25; export PATH=/opt/homebrew/opt/node@24/bin:$JAVA_HOME/bin:$PATH; export DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock; ./mvnw test'
Tests run: 197, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS in 01:33 using PostgreSQL 18.4 Testcontainers. No development environment value was present.
Tests run: 201, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS in 01:29 using PostgreSQL 18.4 Testcontainers.
```
## External-test boundaries
The committed example cannot prove another developer's local credentials. Product SMTP and HolidayAPI revisions remain Admin-console configuration and are intentionally absent from `.env`.
The committed example cannot prove another developer's local credentials or
an IDE working directory. Product SMTP and HolidayAPI revisions remain
Admin-console configuration and are intentionally absent from `.env`.
@@ -0,0 +1,161 @@
# Test Evidence: Eligible Intern picker query
- **Test type:** Integration
- **Requirement IDs:** ACC-014, ACC-019ACC-021, AUTH-001, PRJ-017, TST-001TST-010
- **Scenario IDs:** AC-ACC-009, AC-ACC-010, AC-PRJ-010 (selection-eligibility support)
- **Test class/method:** com.lab.labtimesheet.feature.account.service.EligibleInternOptionIntegrationTest#listsOnlyActiveInternsWithActiveInclusiveInternshipsInPickerOrder; #rejectsMissingBusinessDate
- **Implementation commit:** e70159a81b6445825f6d5f912ecf3c4aa3c1aa85
## Protected behavior
Pending, locked, deactivated, non-Intern, not-started, completed, and date-expired records must not appear in the
Account-owned Intern picker. An option is selectable only when both account and internship are ACTIVE and the
explicit business date lies within the inclusive internship range. The returned numeric user ID is the internal
submission identity, and options sort by display name then student code.
The public query rejects a missing business date with the documented actionable message instead of issuing an
ambiguous null-bound database query.
## Test method
The PostgreSQL 18.4 integration test persists valid account/profile combinations through the account feature's JPA
entities and repositories. It uses SQL only as a test fixture for future lock, deactivation, and completion states
whose production transitions are outside this change. It calls the public Account service query and compares the
complete immutable DTO sequence, including both inclusive date boundaries and unique user IDs.
Its separate null-date regression calls the same public service method and asserts the exact
<code>IllegalArgumentException</code> message documented by that method.
## Hand-derived expected result
For business date 2026-08-14, profiles starting on that date and ending on that date remain eligible. The only
expected options are Alpha / STU-100, Alpha / STU-200, and Zeta / STU-300, in that order. Every other seeded
row fails at least one account role/state, internship state, or inclusive date condition.
For a missing business date, the service must immediately throw
<code>IllegalArgumentException("Business date is required")</code>.
## RED
**Command**
~~~text
export JAVA_HOME=/opt/homebrew/opt/openjdk@25
export PATH="$JAVA_HOME/bin:$PATH"
export DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock
./mvnw -Dtest=EligibleInternOptionIntegrationTest test
~~~
**Observed result**
~~~text
[ERROR] EligibleInternOptionIntegrationTest.java:[11,54] cannot find symbol
symbol: class EligibleInternOption
location: package com.lab.labtimesheet.feature.account.model.dto
BUILD FAILURE
~~~
## GREEN
**Command**
~~~text
export JAVA_HOME=/opt/homebrew/opt/openjdk@25
export PATH="$JAVA_HOME/bin:$PATH"
export DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock
./mvnw -Dtest=EligibleInternOptionIntegrationTest test
~~~
**Observed result**
~~~text
PostgreSQL 18.4 Testcontainers started and Flyway applied V1 baseline.
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS
~~~
## Review follow-up: missing business date
The public guard was temporarily removed solely to prove the new regression fails for the intended reason, then
restored exactly before the GREEN checks. The follow-up commit contains only the regression test and evidence.
### RED
**Command**
~~~text
export JAVA_HOME=/opt/homebrew/opt/openjdk@25
export PATH="$JAVA_HOME/bin:$PATH"
export DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock
./mvnw '-Dtest=EligibleInternOptionIntegrationTest#rejectsMissingBusinessDate' test
~~~
**Observed result**
~~~text
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
java.lang.AssertionError: Expecting code to raise a throwable.
BUILD FAILURE
~~~
### GREEN
**Command**
~~~text
export JAVA_HOME=/opt/homebrew/opt/openjdk@25
export PATH="$JAVA_HOME/bin:$PATH"
export DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock
./mvnw '-Dtest=EligibleInternOptionIntegrationTest#rejectsMissingBusinessDate' test
~~~
**Observed result**
~~~text
PostgreSQL 18.4 Testcontainers started and Flyway applied V1 baseline.
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS
~~~
## Affected suite
**Command and result**
~~~text
export JAVA_HOME=/opt/homebrew/opt/openjdk@25
export PATH="$JAVA_HOME/bin:$PATH"
export DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock
./mvnw -Dtest=EligibleInternOptionIntegrationTest,AccountActivationIntegrationTest,BootstrapIntegrationTest,AccountWebIntegrationTest,AuthenticationWebIntegrationTest,BootstrapOnboardingWebIntegrationTest test
Selected account reports: 13 tests, 0 failures, 0 errors, 0 skipped.
./mvnw -Dtest=AccountActivationIntegrationTest test
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS
./mvnw -Dtest=LayerStructureTest test
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS
./mvnw test
Tests run: 105, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS
~~~
### Review follow-up affected account-service checks
~~~text
export JAVA_HOME=/opt/homebrew/opt/openjdk@25
export PATH="$JAVA_HOME/bin:$PATH"
export DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock
./mvnw '-Dtest=EligibleInternOptionIntegrationTest,AccountActivationIntegrationTest,BootstrapIntegrationTest' test
EligibleInternOptionIntegrationTest: 2 tests, 0 failures, 0 errors, 0 skipped
BootstrapIntegrationTest: 4 tests, 0 failures, 0 errors, 0 skipped
AccountActivationIntegrationTest: 2 tests, 0 failures, 0 errors, 0 skipped
Selected account-service reports: 8 tests, 0 failures, 0 errors, 0 skipped.
BUILD SUCCESS
~~~
## External-test boundaries
This query does not authorize Project membership itself; the consuming Project transaction must still recheck
membership and ownership invariants. It does not test the later lifecycle mutation workflows that produce locked,
deactivated, or completed rows.
+81
View File
@@ -0,0 +1,81 @@
# Test Evidence: Fresh-install root navigation
- **Test type:** Web
- **Requirement IDs:** `ACC-001`
- **Scenario IDs:** `N/A — user-reported fresh-install navigation regression`
- **Test class/method:** `com.lab.labtimesheet.feature.account.service.BootstrapIntegrationTest.rootGuidesFreshInstallToBootstrapWhileOtherRoutesRemainHidden`
- **Implementation commit:** `531c6078521341b156d69cb1013e54f65c092311`
## Protected behavior
Before the first Admin exists, opening `/` redirects to the public one-time
bootstrap workflow instead of rendering a Whitelabel 404 page. Other protected
application routes remain concealed with HTTP 404 until bootstrap completes.
## Test method
The production Spring Security and bootstrap filter chain runs against a fresh
PostgreSQL 18.4 Testcontainer. MockMvc requests `/bootstrap`, health, `/`, and
`/dashboard`, then verifies that only the root receives the new navigation
redirect while the protected dashboard remains hidden.
## Hand-derived expected result
On an uninitialized installation, GET `/` returns a 3xx response with Location
`/bootstrap`. GET `/dashboard` still returns 404. The bootstrap form and health
endpoint remain available.
## RED
**Command**
```text
export JAVA_HOME=/Users/sechmachine/Library/Java/JavaVirtualMachines/corretto-26.0.2/Contents/Home
export PATH="$JAVA_HOME/bin:$PATH"
export DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock
./mvnw -Dtest=BootstrapIntegrationTest#rootGuidesFreshInstallToBootstrapWhileOtherRoutesRemainHidden test
```
**Observed result**
```text
GET / returned 404.
Expected a 3xx redirect to /bootstrap.
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
BUILD FAILURE
```
## GREEN
**Command**
```text
./mvnw -Dtest=BootstrapIntegrationTest#rootGuidesFreshInstallToBootstrapWhileOtherRoutesRemainHidden test
```
**Observed result**
```text
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS
PostgreSQL: 18.4
```
## Affected suite
**Command and result**
```text
./mvnw -Dtest=BootstrapIntegrationTest,AuthenticationWebIntegrationTest,BootstrapOnboardingWebIntegrationTest,SecurityResponseIntegrationTest test
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS
PostgreSQL: 18.4
```
## External-test boundaries
MockMvc verifies server routing, security, and persistence-backed initialization
state. It does not prove browser rendering or exercise the user's IntelliJ-run
process. The existing browser screenshot independently established the original
Whitelabel 404 symptom.
@@ -19,7 +19,7 @@ public class BootstrapAccessFilter extends OncePerRequestFilter {
private final BootstrapService bootstrap;
/**
* Returns HTTP 404 for hidden routes before bootstrap so no authentication surface is exposed prematurely.
* Redirects the installation root to bootstrap and returns HTTP 404 for every other hidden route.
*
* @param request current HTTP request
* @param response current HTTP response
@@ -31,6 +31,10 @@ public class BootstrapAccessFilter extends OncePerRequestFilter {
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
throws ServletException, IOException {
String path = request.getRequestURI();
if (!bootstrap.isInitialized() && path.equals(request.getContextPath() + "/")) {
response.sendRedirect(request.getContextPath() + "/bootstrap");
return;
}
if (!bootstrap.isInitialized() && !allowedBeforeBootstrap(path)) {
response.sendError(HttpServletResponse.SC_NOT_FOUND);
return;
@@ -0,0 +1,21 @@
package com.lab.labtimesheet.feature.account.model.dto;
import java.time.LocalDate;
/**
* Immutable non-secret selection data for an eligible Intern.
* The numeric user ID is the internal form submission identity; displayed fields are not authorization identifiers.
*
* @param userId persistent account identifier submitted by a consuming form
* @param displayName user-facing Intern name
* @param studentCode university student code shown to distinguish Interns
* @param internshipStart inclusive internship eligibility start date
* @param internshipEnd inclusive internship eligibility end date
*/
public record EligibleInternOption(
long userId,
String displayName,
String studentCode,
LocalDate internshipStart,
LocalDate internshipEnd) {
}
@@ -1,8 +1,12 @@
package com.lab.labtimesheet.feature.account.repository;
import java.time.LocalDate;
import java.util.List;
import com.lab.labtimesheet.feature.account.model.AccountStatus;
import com.lab.labtimesheet.feature.account.model.GlobalRole;
import com.lab.labtimesheet.feature.account.model.InternshipStatus;
import com.lab.labtimesheet.feature.account.model.dto.EligibleInternOption;
import com.lab.labtimesheet.feature.account.model.entity.InternProfile;
import jakarta.persistence.LockModeType;
import org.springframework.data.jpa.repository.JpaRepository;
@@ -19,6 +23,34 @@ public interface InternProfileRepository extends JpaRepository<InternProfile, Lo
boolean existsByUserIdAndInternshipStatusAndInternshipStartDateLessThanEqualAndInternshipEndDateGreaterThanEqual(
Long userId, InternshipStatus status, LocalDate latestStartDate, LocalDate earliestEndDate);
/**
* Projects account-owned non-secret selection data for Interns eligible on one inclusive business date.
* Results are ordered by display name, student code, then user ID for deterministic form rendering.
*
* @param globalRole required immutable Intern role
* @param accountStatus required active account state
* @param internshipStatus required active internship state
* @param businessDate date that must fall within the inclusive internship range
* @return eligible Intern selection projections without duplicate profile rows
*/
@Query("""
select new com.lab.labtimesheet.feature.account.model.dto.EligibleInternOption(
u.id, u.displayName, p.studentCode, p.internshipStartDate, p.internshipEndDate)
from InternProfile p
join AppUser u on u.id = p.userId
where u.globalRole = :globalRole
and u.accountStatus = :accountStatus
and p.internshipStatus = :internshipStatus
and p.internshipStartDate <= :businessDate
and p.internshipEndDate >= :businessDate
order by u.displayName asc, p.studentCode asc, u.id asc
""")
List<EligibleInternOption> findEligibleInternOptions(
@Param("globalRole") GlobalRole globalRole,
@Param("accountStatus") AccountStatus accountStatus,
@Param("internshipStatus") InternshipStatus internshipStatus,
@Param("businessDate") LocalDate businessDate);
/** Counts Intern profiles in a lifecycle state. */
long countByInternshipStatus(InternshipStatus status);
@@ -8,6 +8,7 @@ import java.time.Clock;
import java.time.Duration;
import java.time.LocalDate;
import java.util.Base64;
import java.util.List;
import com.lab.labtimesheet.feature.account.model.AccountStatus;
import com.lab.labtimesheet.feature.account.model.GlobalRole;
@@ -17,6 +18,7 @@ import com.lab.labtimesheet.feature.account.model.dto.AccountCreation;
import com.lab.labtimesheet.feature.account.model.dto.AccountIdentity;
import com.lab.labtimesheet.feature.account.model.dto.AccountSummary;
import com.lab.labtimesheet.feature.account.model.dto.CreateAccountCommand;
import com.lab.labtimesheet.feature.account.model.dto.EligibleInternOption;
import com.lab.labtimesheet.feature.account.model.entity.AppUser;
import com.lab.labtimesheet.feature.account.model.entity.InternProfile;
import com.lab.labtimesheet.feature.account.model.entity.UserActionToken;
@@ -238,6 +240,24 @@ public class AccountService {
.isPresent();
}
/**
* Lists non-secret Intern selection options eligible on an explicit business date.
* The result requires active account and internship states plus inclusive internship dates, but it does not
* authorize a consuming Project operation; that operation must recheck its own ownership and membership rules.
*
* @param businessDate server-derived business date to evaluate inclusively
* @return deterministic options ordered by display name, student code, then account ID
* @throws IllegalArgumentException when {@code businessDate} is {@code null}
*/
@Transactional(readOnly = true)
public List<EligibleInternOption> eligibleInternOptions(LocalDate businessDate) {
if (businessDate == null) {
throw new IllegalArgumentException("Business date is required");
}
return internProfiles.findEligibleInternOptions(
GlobalRole.INTERN, AccountStatus.ACTIVE, InternshipStatus.ACTIVE, businessDate);
}
/**
* Resolves the cross-feature identity of a currently eligible Intern.
*
@@ -1,35 +0,0 @@
# Development profile. Values that differ between machines come from an untracked .env file.
server.port=${LAB_SERVER_PORT}
server.forward-headers-strategy=${LAB_FORWARD_HEADERS_STRATEGY}
server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.secure=false
server.servlet.session.cookie.same-site=lax
server.error.include-message=never
server.error.include-stacktrace=never
spring.datasource.url=${LAB_DB_URL}
spring.datasource.username=${LAB_DB_USERNAME}
spring.datasource.password=${LAB_DB_PASSWORD}
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.open-in-view=false
spring.jpa.properties.hibernate.jdbc.time_zone=UTC
spring.flyway.enabled=true
spring.flyway.locations=classpath:db/migration
spring.docker.compose.enabled=false
# Mailpit keeps Spring's mail health check local. User-facing SMTP credentials remain Admin-console data.
spring.mail.host=${LAB_SMTP_HOST}
spring.mail.port=${LAB_SMTP_PORT}
spring.mail.protocol=smtp
spring.mail.test-connection=false
spring.mail.properties.mail.smtp.auth=false
spring.mail.properties.mail.smtp.starttls.enable=false
spring.mail.properties.mail.smtp.connectiontimeout=5000
spring.mail.properties.mail.smtp.timeout=5000
spring.mail.properties.mail.smtp.writetimeout=5000
management.endpoints.web.exposure.include=health,info
management.endpoint.health.show-details=when_authorized
lab.public-origin=${LAB_PUBLIC_ORIGIN}
lab.security.master-key=${LAB_SECURITY_MASTER_KEY}
+64
View File
@@ -0,0 +1,64 @@
# Development profile. Machine-specific values come from the ignored root .env file.
spring:
config:
import: "optional:file:${LAB_DEV_ENV_FILE:.env}[.properties]"
datasource:
url: "${LAB_DB_URL}"
username: "${LAB_DB_USERNAME}"
password: "${LAB_DB_PASSWORD}"
jpa:
hibernate:
ddl-auto: validate
open-in-view: false
properties:
hibernate:
jdbc:
time_zone: UTC
flyway:
enabled: true
locations: classpath:db/migration
docker:
compose:
enabled: false
# Mailpit keeps Spring's mail health check local. User-facing SMTP credentials remain Admin-console data.
mail:
host: "${LAB_SMTP_HOST}"
port: "${LAB_SMTP_PORT}"
protocol: smtp
test-connection: false
properties:
mail:
smtp:
auth: false
starttls:
enable: false
connectiontimeout: 5000
timeout: 5000
writetimeout: 5000
server:
port: "${LAB_SERVER_PORT}"
forward-headers-strategy: "${LAB_FORWARD_HEADERS_STRATEGY}"
servlet:
session:
cookie:
http-only: true
secure: false
same-site: lax
error:
include-message: never
include-stacktrace: never
management:
endpoints:
web:
exposure:
include: "health,info"
endpoint:
health:
show-details: when_authorized
lab:
public-origin: "${LAB_PUBLIC_ORIGIN}"
security:
master-key: "${LAB_SECURITY_MASTER_KEY}"
@@ -2,6 +2,7 @@ package com.lab.labtimesheet.feature.account.service;
import static org.assertj.core.api.Assertions.assertThat;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.redirectedUrl;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
import java.time.LocalDate;
@@ -57,10 +58,13 @@ class BootstrapIntegrationTest {
private DataSource dataSource;
@Test
void onlyBootstrapAndHealthAreAvailableBeforeInitialization() throws Exception {
void rootGuidesFreshInstallToBootstrapWhileOtherRoutesRemainHidden() throws Exception {
mockMvc.perform(get("/bootstrap")).andExpect(status().isOk());
mockMvc.perform(get("/actuator/health")).andExpect(status().isOk());
mockMvc.perform(get("/")).andExpect(status().isNotFound());
mockMvc.perform(get("/"))
.andExpect(status().is3xxRedirection())
.andExpect(redirectedUrl("/bootstrap"));
mockMvc.perform(get("/dashboard")).andExpect(status().isNotFound());
bootstrapService.bootstrap("admin@example.com", "Admin", "correct horse battery staple");
mockMvc.perform(get("/bootstrap")).andExpect(status().isNotFound());
@@ -0,0 +1,165 @@
package com.lab.labtimesheet.feature.account.service;
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;
import java.sql.Timestamp;
import java.time.Instant;
import java.time.LocalDate;
import java.util.List;
import com.lab.labtimesheet.config.TestcontainersConfiguration;
import com.lab.labtimesheet.feature.account.model.GlobalRole;
import com.lab.labtimesheet.feature.account.model.dto.EligibleInternOption;
import com.lab.labtimesheet.feature.account.model.entity.AppUser;
import com.lab.labtimesheet.feature.account.model.entity.InternProfile;
import com.lab.labtimesheet.feature.account.repository.AppUserRepository;
import com.lab.labtimesheet.feature.account.repository.InternProfileRepository;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.context.annotation.Import;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.test.annotation.DirtiesContext;
import org.springframework.test.context.ActiveProfiles;
@Import(TestcontainersConfiguration.class)
@SpringBootTest
@ActiveProfiles("test")
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
class EligibleInternOptionIntegrationTest {
private static final Instant NOW = Instant.parse("2026-08-14T00:00:00Z");
private static final LocalDate BUSINESS_DATE = LocalDate.of(2026, 8, 14);
@Autowired
private AccountService accounts;
@Autowired
private AppUserRepository users;
@Autowired
private InternProfileRepository internProfiles;
@Autowired
private JdbcTemplate jdbc;
private AppUser admin;
private int userSequence;
@BeforeEach
void setUp() {
admin = users.saveAndFlush(AppUser.bootstrapAdmin(
"picker-admin@example.com", "Picker Admin", "encoded-password", NOW));
}
@Test
void listsOnlyActiveInternsWithActiveInclusiveInternshipsInPickerOrder() {
long lowerBoundary = activeIntern("Alpha", "STU-100", BUSINESS_DATE, BUSINESS_DATE.plusDays(10));
long upperBoundary = activeIntern("Alpha", "STU-200", BUSINESS_DATE.minusDays(10), BUSINESS_DATE);
long laterName = activeIntern("Zeta", "STU-300", BUSINESS_DATE.minusDays(1), BUSINESS_DATE.plusDays(1));
pendingInternWithActiveProfile("Ignored Pending", "STU-400");
long locked = activeIntern("Ignored Locked", "STU-500", BUSINESS_DATE.minusDays(1), BUSINESS_DATE.plusDays(1));
lock(locked);
long deactivated = activeIntern(
"Ignored Deactivated", "STU-600", BUSINESS_DATE.minusDays(1), BUSINESS_DATE.plusDays(1));
deactivate(deactivated);
activeMentorWithActiveProfile("Ignored Mentor", "STU-700");
activeInternWithNotStartedProfile("Ignored Not Started", "STU-800");
activeIntern("Ignored Ended", "STU-900", BUSINESS_DATE.minusDays(10), BUSINESS_DATE.minusDays(1));
long completed = activeIntern(
"Ignored Completed", "STU-1000", BUSINESS_DATE.minusDays(1), BUSINESS_DATE.plusDays(1));
completeInternship(completed);
List<EligibleInternOption> options = accounts.eligibleInternOptions(BUSINESS_DATE);
assertThat(options).containsExactly(
new EligibleInternOption(
lowerBoundary, "Alpha", "STU-100", BUSINESS_DATE, BUSINESS_DATE.plusDays(10)),
new EligibleInternOption(
upperBoundary, "Alpha", "STU-200", BUSINESS_DATE.minusDays(10), BUSINESS_DATE),
new EligibleInternOption(
laterName, "Zeta", "STU-300", BUSINESS_DATE.minusDays(1), BUSINESS_DATE.plusDays(1)));
assertThat(options).extracting(EligibleInternOption::userId).doesNotHaveDuplicates();
}
@Test
void rejectsMissingBusinessDate() {
assertThatThrownBy(() -> accounts.eligibleInternOptions(null))
.isInstanceOf(IllegalArgumentException.class)
.hasMessage("Business date is required");
}
private long activeIntern(String displayName, String studentCode, LocalDate startDate, LocalDate endDate) {
long userId = activeUser(GlobalRole.INTERN, displayName);
activeProfile(userId, studentCode, startDate, endDate);
return userId;
}
private void pendingInternWithActiveProfile(String displayName, String studentCode) {
long userId = pendingUser(GlobalRole.INTERN, displayName);
activeProfile(userId, studentCode, BUSINESS_DATE.minusDays(1), BUSINESS_DATE.plusDays(1));
}
private void activeMentorWithActiveProfile(String displayName, String studentCode) {
long userId = activeUser(GlobalRole.MENTOR, displayName);
activeProfile(userId, studentCode, BUSINESS_DATE.minusDays(1), BUSINESS_DATE.plusDays(1));
}
private void activeInternWithNotStartedProfile(String displayName, String studentCode) {
long userId = activeUser(GlobalRole.INTERN, displayName);
internProfiles.saveAndFlush(InternProfile.notStarted(
userId, studentCode, BUSINESS_DATE.minusDays(1), BUSINESS_DATE.plusDays(1), NOW));
}
private long activeUser(GlobalRole role, String displayName) {
AppUser user = AppUser.pending(nextEmail(), displayName, role, admin, NOW);
user.activate("encoded-password", NOW);
return users.saveAndFlush(user).getId();
}
private long pendingUser(GlobalRole role, String displayName) {
return users.saveAndFlush(AppUser.pending(nextEmail(), displayName, role, admin, NOW)).getId();
}
private void activeProfile(long userId, String studentCode, LocalDate startDate, LocalDate endDate) {
InternProfile profile = InternProfile.notStarted(userId, studentCode, startDate, endDate, NOW);
profile.activate(NOW);
internProfiles.saveAndFlush(profile);
}
private void lock(long userId) {
assertThat(jdbc.update(
"""
update app_users
set account_status = 'LOCKED', locked_at = ?, updated_at = ?
where id = ?
""",
Timestamp.from(NOW), Timestamp.from(NOW), userId)).isOne();
}
private void deactivate(long userId) {
assertThat(jdbc.update(
"""
update app_users
set account_status = 'DEACTIVATED', deactivated_at = ?, updated_at = ?
where id = ?
""",
Timestamp.from(NOW), Timestamp.from(NOW), userId)).isOne();
}
private void completeInternship(long userId) {
assertThat(jdbc.update(
"""
update intern_profiles
set internship_status = 'COMPLETED', completed_at = ?, updated_at = ?
where user_id = ?
""",
Timestamp.from(NOW), Timestamp.from(NOW), userId)).isOne();
}
private String nextEmail() {
return "picker-" + ++userSequence + "@example.com";
}
}