Compare commits
2
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 sechmachine
|
159e634ffc | ||
|
sechmachine
|
8be1b754e1 |
@@ -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 0–720; 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 1–1440-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
-11
@@ -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/
|
||||
/labtimesheet-docs-hub/
|
||||
@@ -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"
|
||||
}
|
||||
@@ -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.
|
||||
@@ -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** (600–700, `14px`): names the current dataset or decision surface.
|
||||
- **Body** (400, `14px`, 1.45): instructions and explanatory copy, normally no wider than 72ch.
|
||||
- **Data** (500–650, `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 24–26px 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 user’s 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.
|
||||
+89
@@ -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.
|
||||
@@ -0,0 +1,70 @@
|
||||
# Test Evidence: dark icon sprite presentation
|
||||
|
||||
- **Test type:** Web
|
||||
- **Requirement IDs:** `UI-006`, `UI-009`, `UI-010`, `UI-018`
|
||||
- **Scenario IDs:** `AC-UI-003`, `AC-UI-005`
|
||||
- **Test class/method:** `com.lab.labtimesheet.ui.UiContractWebTest#generatedLucideSymbolsRetainCurrentColorStrokePresentation`
|
||||
- **Implementation commit:** `pending`
|
||||
|
||||
## Protected behavior
|
||||
|
||||
Every local Lucide sprite symbol retains the source presentation attributes so icons referenced with `<use>` inherit `currentColor` rather than rendering with the SVG default black fill on dark surfaces.
|
||||
|
||||
## Test method
|
||||
|
||||
The focused web contract reads the generated classpath sprite, scans every emitted `<symbol>`, and checks the five presentation attributes on each symbol. It checks the deployable generated artifact rather than generator source text.
|
||||
|
||||
## Hand-derived expected result
|
||||
|
||||
Lucide 1.27.0 line icons use `fill="none"`, `stroke="currentColor"`, `stroke-width="2"`, `stroke-linecap="round"`, and `stroke-linejoin="round"` on their SVG root. Each selected generated symbol must preserve those values.
|
||||
|
||||
## RED
|
||||
|
||||
**Command**
|
||||
|
||||
```text
|
||||
env JAVA_HOME=/opt/homebrew/opt/openjdk@25 PATH=/opt/homebrew/opt/openjdk@25/bin:$PATH ./mvnw '-Dtest=UiContractWebTest#generatedLucideSymbolsRetainCurrentColorStrokePresentation' test
|
||||
```
|
||||
|
||||
**Observed result**
|
||||
|
||||
```text
|
||||
UiContractWebTest.generatedLucideSymbolsRetainCurrentColorStrokePresentation
|
||||
Missing fill on id="bell" viewBox="0 0 24 24" ==> expected: <true> but was: <false>
|
||||
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
|
||||
BUILD FAILURE
|
||||
```
|
||||
|
||||
## GREEN
|
||||
|
||||
**Command**
|
||||
|
||||
```text
|
||||
env PATH=/opt/homebrew/opt/node@24/bin:$PATH npm ci
|
||||
env PATH=/opt/homebrew/opt/node@24/bin:$PATH npm run build
|
||||
env JAVA_HOME=/opt/homebrew/opt/openjdk@25 PATH=/opt/homebrew/opt/openjdk@25/bin:$PATH ./mvnw '-Dtest=UiContractWebTest#generatedLucideSymbolsRetainCurrentColorStrokePresentation' test
|
||||
```
|
||||
|
||||
**Observed result**
|
||||
|
||||
```text
|
||||
Node v24.19.0 and npm 11.17.0 installed the locked dependencies.
|
||||
Tailwind CSS v4.3.3 rebuilt app.css and build-icons regenerated icons.svg.
|
||||
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
|
||||
BUILD SUCCESS
|
||||
```
|
||||
|
||||
## Affected suite
|
||||
|
||||
**Command and result**
|
||||
|
||||
```text
|
||||
env JAVA_HOME=/opt/homebrew/opt/openjdk@25 PATH=/opt/homebrew/opt/openjdk@25/bin:$PATH ./mvnw '-Dtest=UiContractWebTest' test
|
||||
|
||||
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0
|
||||
BUILD SUCCESS
|
||||
```
|
||||
|
||||
## External-test boundaries
|
||||
|
||||
The deterministic asset contract proves the generated sprite carries theme-aware Lucide presentation attributes. It does not replace the taskmaster-owned integrated browser/detector pass for rendered layout and interactive states.
|
||||
@@ -10,10 +10,14 @@ const names = [
|
||||
const output = resolve('src/main/resources/static/assets/icons.svg');
|
||||
const symbols = await Promise.all(names.map(async (name) => {
|
||||
const svg = await readFile(resolve(`node_modules/lucide-static/icons/${name}.svg`), 'utf8');
|
||||
const viewBox = svg.match(/viewBox="([^"]+)"/)?.[1] ?? '0 0 24 24';
|
||||
const root = svg.match(/<svg\b([^>]*)>/)?.[1];
|
||||
const viewBox = root?.match(/viewBox="([^"]+)"/)?.[1] ?? '0 0 24 24';
|
||||
const presentation = ['fill', 'stroke', 'stroke-width', 'stroke-linecap', 'stroke-linejoin']
|
||||
.map((attribute) => root?.match(new RegExp(`${attribute}="[^"]+"`))?.[0])
|
||||
.join(' ');
|
||||
const body = svg.match(/<svg[\s\S]*?>([\s\S]*?)<\/svg>/)?.[1];
|
||||
if (!body) throw new Error(`Invalid Lucide SVG: ${name}`);
|
||||
return `<symbol id="${name}" viewBox="${viewBox}">${body.trim()}</symbol>`;
|
||||
return `<symbol id="${name}" viewBox="${viewBox}" ${presentation}>${body.trim()}</symbol>`;
|
||||
}));
|
||||
|
||||
await mkdir(dirname(output), { recursive: true });
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" style="display:none"><symbol id="bell" viewBox="0 0 24 24"><path d="M10.268 21a2 2 0 0 0 3.464 0" />
|
||||
<path d="M3.262 15.326A1 1 0 0 0 4 17h16a1 1 0 0 0 .74-1.673C19.41 13.956 18 12.499 18 8A6 6 0 0 0 6 8c0 4.499-1.411 5.956-2.738 7.326" /></symbol><symbol id="calendar-days" viewBox="0 0 24 24"><path d="M8 2v4" />
|
||||
<svg xmlns="http://www.w3.org/2000/svg" style="display:none"><symbol id="bell" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M10.268 21a2 2 0 0 0 3.464 0" />
|
||||
<path d="M3.262 15.326A1 1 0 0 0 4 17h16a1 1 0 0 0 .74-1.673C19.41 13.956 18 12.499 18 8A6 6 0 0 0 6 8c0 4.499-1.411 5.956-2.738 7.326" /></symbol><symbol id="calendar-days" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M8 2v4" />
|
||||
<path d="M16 2v4" />
|
||||
<rect width="18" height="18" x="3" y="4" rx="2" />
|
||||
<path d="M3 10h18" />
|
||||
@@ -8,27 +8,27 @@
|
||||
<path d="M16 14h.01" />
|
||||
<path d="M8 18h.01" />
|
||||
<path d="M12 18h.01" />
|
||||
<path d="M16 18h.01" /></symbol><symbol id="check-circle-2" viewBox="0 0 24 24"><circle cx="12" cy="12" r="10" />
|
||||
<path d="m9 12 2 2 4-4" /></symbol><symbol id="chevron-left" viewBox="0 0 24 24"><path d="m15 18-6-6 6-6" /></symbol><symbol id="chevron-right" viewBox="0 0 24 24"><path d="m9 18 6-6-6-6" /></symbol><symbol id="circle-user-round" viewBox="0 0 24 24"><path d="M17.925 20.056a6 6 0 0 0-11.851.001" />
|
||||
<path d="M16 18h.01" /></symbol><symbol id="check-circle-2" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="10" />
|
||||
<path d="m9 12 2 2 4-4" /></symbol><symbol id="chevron-left" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="m15 18-6-6 6-6" /></symbol><symbol id="chevron-right" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="m9 18 6-6-6-6" /></symbol><symbol id="circle-user-round" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M17.925 20.056a6 6 0 0 0-11.851.001" />
|
||||
<circle cx="12" cy="11" r="4" />
|
||||
<circle cx="12" cy="12" r="10" /></symbol><symbol id="clock" viewBox="0 0 24 24"><circle cx="12" cy="12" r="10" />
|
||||
<path d="M12 6v6l4 2" /></symbol><symbol id="folder-kanban" viewBox="0 0 24 24"><path d="M4 20h16a2 2 0 0 0 2-2V8a2 2 0 0 0-2-2h-7.93a2 2 0 0 1-1.66-.9l-.82-1.2A2 2 0 0 0 7.93 3H4a2 2 0 0 0-2 2v13c0 1.1.9 2 2 2Z" />
|
||||
<circle cx="12" cy="12" r="10" /></symbol><symbol id="clock" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="10" />
|
||||
<path d="M12 6v6l4 2" /></symbol><symbol id="folder-kanban" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M4 20h16a2 2 0 0 0 2-2V8a2 2 0 0 0-2-2h-7.93a2 2 0 0 1-1.66-.9l-.82-1.2A2 2 0 0 0 7.93 3H4a2 2 0 0 0-2 2v13c0 1.1.9 2 2 2Z" />
|
||||
<path d="M8 10v4" />
|
||||
<path d="M12 10v2" />
|
||||
<path d="M16 10v6" /></symbol><symbol id="folder-open" viewBox="0 0 24 24"><path d="m6 14 1.5-2.9A2 2 0 0 1 9.24 10H20a2 2 0 0 1 1.94 2.5l-1.54 6a2 2 0 0 1-1.95 1.5H4a2 2 0 0 1-2-2V5a2 2 0 0 1 2-2h3.9a2 2 0 0 1 1.69.9l.81 1.2a2 2 0 0 0 1.67.9H18a2 2 0 0 1 2 2v2" /></symbol><symbol id="inbox" viewBox="0 0 24 24"><polyline points="22 12 16 12 14 15 10 15 8 12 2 12" />
|
||||
<path d="M5.45 5.11 2 12v6a2 2 0 0 0 2 2h16a2 2 0 0 0 2-2v-6l-3.45-6.89A2 2 0 0 0 16.76 4H7.24a2 2 0 0 0-1.79 1.11z" /></symbol><symbol id="layout-dashboard" viewBox="0 0 24 24"><rect width="7" height="9" x="3" y="3" rx="1" />
|
||||
<path d="M16 10v6" /></symbol><symbol id="folder-open" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="m6 14 1.5-2.9A2 2 0 0 1 9.24 10H20a2 2 0 0 1 1.94 2.5l-1.54 6a2 2 0 0 1-1.95 1.5H4a2 2 0 0 1-2-2V5a2 2 0 0 1 2-2h3.9a2 2 0 0 1 1.69.9l.81 1.2a2 2 0 0 0 1.67.9H18a2 2 0 0 1 2 2v2" /></symbol><symbol id="inbox" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><polyline points="22 12 16 12 14 15 10 15 8 12 2 12" />
|
||||
<path d="M5.45 5.11 2 12v6a2 2 0 0 0 2 2h16a2 2 0 0 0 2-2v-6l-3.45-6.89A2 2 0 0 0 16.76 4H7.24a2 2 0 0 0-1.79 1.11z" /></symbol><symbol id="layout-dashboard" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><rect width="7" height="9" x="3" y="3" rx="1" />
|
||||
<rect width="7" height="5" x="14" y="3" rx="1" />
|
||||
<rect width="7" height="9" x="14" y="12" rx="1" />
|
||||
<rect width="7" height="5" x="3" y="16" rx="1" /></symbol><symbol id="list-check" viewBox="0 0 24 24"><path d="M16 5H3" />
|
||||
<rect width="7" height="5" x="3" y="16" rx="1" /></symbol><symbol id="list-check" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M16 5H3" />
|
||||
<path d="M16 12H3" />
|
||||
<path d="M11 19H3" />
|
||||
<path d="m15 18 2 2 4-4" /></symbol><symbol id="log-out" viewBox="0 0 24 24"><path d="m16 17 5-5-5-5" />
|
||||
<path d="m15 18 2 2 4-4" /></symbol><symbol id="log-out" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="m16 17 5-5-5-5" />
|
||||
<path d="M21 12H9" />
|
||||
<path d="M9 21H5a2 2 0 0 1-2-2V5a2 2 0 0 1 2-2h4" /></symbol><symbol id="monitor" viewBox="0 0 24 24"><rect width="20" height="14" x="2" y="3" rx="2" />
|
||||
<path d="M9 21H5a2 2 0 0 1-2-2V5a2 2 0 0 1 2-2h4" /></symbol><symbol id="monitor" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><rect width="20" height="14" x="2" y="3" rx="2" />
|
||||
<line x1="8" x2="16" y1="21" y2="21" />
|
||||
<line x1="12" x2="12" y1="17" y2="21" /></symbol><symbol id="moon" viewBox="0 0 24 24"><path d="M20.985 12.486a9 9 0 1 1-9.473-9.472c.405-.022.617.46.402.803a6 6 0 0 0 8.268 8.268c.344-.215.825-.004.803.401" /></symbol><symbol id="panel-left" viewBox="0 0 24 24"><rect width="18" height="18" x="3" y="3" rx="2" />
|
||||
<path d="M9 3v18" /></symbol><symbol id="settings" viewBox="0 0 24 24"><path d="M9.671 4.136a2.34 2.34 0 0 1 4.659 0 2.34 2.34 0 0 0 3.319 1.915 2.34 2.34 0 0 1 2.33 4.033 2.34 2.34 0 0 0 0 3.831 2.34 2.34 0 0 1-2.33 4.033 2.34 2.34 0 0 0-3.319 1.915 2.34 2.34 0 0 1-4.659 0 2.34 2.34 0 0 0-3.32-1.915 2.34 2.34 0 0 1-2.33-4.033 2.34 2.34 0 0 0 0-3.831A2.34 2.34 0 0 1 6.35 6.051a2.34 2.34 0 0 0 3.319-1.915" />
|
||||
<circle cx="12" cy="12" r="3" /></symbol><symbol id="sun" viewBox="0 0 24 24"><circle cx="12" cy="12" r="4" />
|
||||
<line x1="12" x2="12" y1="17" y2="21" /></symbol><symbol id="moon" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M20.985 12.486a9 9 0 1 1-9.473-9.472c.405-.022.617.46.402.803a6 6 0 0 0 8.268 8.268c.344-.215.825-.004.803.401" /></symbol><symbol id="panel-left" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><rect width="18" height="18" x="3" y="3" rx="2" />
|
||||
<path d="M9 3v18" /></symbol><symbol id="settings" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M9.671 4.136a2.34 2.34 0 0 1 4.659 0 2.34 2.34 0 0 0 3.319 1.915 2.34 2.34 0 0 1 2.33 4.033 2.34 2.34 0 0 0 0 3.831 2.34 2.34 0 0 1-2.33 4.033 2.34 2.34 0 0 0-3.319 1.915 2.34 2.34 0 0 1-4.659 0 2.34 2.34 0 0 0-3.32-1.915 2.34 2.34 0 0 1-2.33-4.033 2.34 2.34 0 0 0 0-3.831A2.34 2.34 0 0 1 6.35 6.051a2.34 2.34 0 0 0 3.319-1.915" />
|
||||
<circle cx="12" cy="12" r="3" /></symbol><symbol id="sun" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="12" cy="12" r="4" />
|
||||
<path d="M12 2v2" />
|
||||
<path d="M12 20v2" />
|
||||
<path d="m4.93 4.93 1.41 1.41" />
|
||||
@@ -36,10 +36,10 @@
|
||||
<path d="M2 12h2" />
|
||||
<path d="M20 12h2" />
|
||||
<path d="m6.34 17.66-1.41 1.41" />
|
||||
<path d="m19.07 4.93-1.41 1.41" /></symbol><symbol id="triangle-alert" viewBox="0 0 24 24"><path d="m21.73 18-8-14a2 2 0 0 0-3.48 0l-8 14A2 2 0 0 0 4 21h16a2 2 0 0 0 1.73-3" />
|
||||
<path d="m19.07 4.93-1.41 1.41" /></symbol><symbol id="triangle-alert" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="m21.73 18-8-14a2 2 0 0 0-3.48 0l-8 14A2 2 0 0 0 4 21h16a2 2 0 0 0 1.73-3" />
|
||||
<path d="M12 9v4" />
|
||||
<path d="M12 17h.01" /></symbol><symbol id="users" viewBox="0 0 24 24"><path d="M16 21v-2a4 4 0 0 0-4-4H6a4 4 0 0 0-4 4v2" />
|
||||
<path d="M12 17h.01" /></symbol><symbol id="users" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M16 21v-2a4 4 0 0 0-4-4H6a4 4 0 0 0-4 4v2" />
|
||||
<path d="M16 3.128a4 4 0 0 1 0 7.744" />
|
||||
<path d="M22 21v-2a4 4 0 0 0-3-3.87" />
|
||||
<circle cx="9" cy="7" r="4" /></symbol><symbol id="x" viewBox="0 0 24 24"><path d="M18 6 6 18" />
|
||||
<circle cx="9" cy="7" r="4" /></symbol><symbol id="x" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 6 6 18" />
|
||||
<path d="m6 6 12 12" /></symbol></svg>
|
||||
|
||||
|
Before Width: | Height: | Size: 4.1 KiB After Width: | Height: | Size: 6.1 KiB |
@@ -97,6 +97,26 @@ class UiContractWebTest {
|
||||
assertTrue(themeBootstrap.contains("matchMedia('(prefers-color-scheme: dark)')"));
|
||||
}
|
||||
|
||||
@Test
|
||||
void generatedLucideSymbolsRetainCurrentColorStrokePresentation() throws Exception {
|
||||
String icons = new ClassPathResource("static/assets/icons.svg")
|
||||
.getContentAsString(StandardCharsets.UTF_8);
|
||||
Matcher symbols = Pattern.compile("<symbol\\b([^>]*)>").matcher(icons);
|
||||
int symbolCount = 0;
|
||||
|
||||
while (symbols.find()) {
|
||||
String attributes = symbols.group(1);
|
||||
assertTrue(attributes.contains("fill=\"none\""), () -> "Missing fill on " + attributes);
|
||||
assertTrue(attributes.contains("stroke=\"currentColor\""), () -> "Missing stroke on " + attributes);
|
||||
assertTrue(attributes.contains("stroke-width=\"2\""), () -> "Missing stroke width on " + attributes);
|
||||
assertTrue(attributes.contains("stroke-linecap=\"round\""), () -> "Missing stroke linecap on " + attributes);
|
||||
assertTrue(attributes.contains("stroke-linejoin=\"round\""), () -> "Missing stroke linejoin on " + attributes);
|
||||
symbolCount++;
|
||||
}
|
||||
|
||||
assertTrue(symbolCount > 0, "The generated sprite must contain symbols");
|
||||
}
|
||||
|
||||
@Test
|
||||
@WithMockUser(username = "admin@example.test", roles = "ADMIN")
|
||||
void collapsedSidebarExposesStateAndKeyboardVisibleControlNames() throws Exception {
|
||||
|
||||
Reference in New Issue
Block a user