docs: add assisted exit transfer and history design documents

docs: add comprehensive technology stack reference
docs(test): pin registry workflow evidence
2026-08-20 17:22:28 +07:00 · 2026-08-16 00:33:55 +07:00 · 2026-08-16 00:28:46 +07:00 · 2026-08-16 00:28:15 +07:00 · 2026-08-15 23:55:52 +07:00 · 2026-08-15 23:21:23 +07:00
26 changed files with 1224 additions and 38 deletions
@@ -42,10 +42,10 @@ No item becomes `DONE` based only on compilation, an isolated happy path, screen
 | 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/projects` | Projects, membership intervals, invitations, membership-exit requests/readiness, leadership terms, Project lifecycle, Project-history authorization, transfer 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/tasks` | Tasks, generic creator/assignment actors, pending-exit assignment exclusion, member self-Task rules, comments, work logs, fixed status transitions, batch reassignment/direct-removal transfer operations, Task soft deletion, and Project Task-progress/history queries. |
-| `work/attendance` | Attendance-policy versions, configured workdays, global calendar, HolidayAPI import interpretation, attendance, corrections, leave, deadline schedulers, and attendance/compliance metrics. |
+| `work/attendance` | Attendance-policy versions/history, configured workdays, global calendar/history, 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. |
+| `work/reports-ui` | Shared Thymeleaf shell/fragments, Tailwind tokens/assets, dashboards, invitation/exit/transfer screens, Project and Admin-setting History tabs, shared report datasets, Chart.js presentation, XLSX/PDF exports, and cross-product UI/accessibility consistency. |
 Conflict-prevention rules:
@@ -56,7 +56,7 @@ Conflict-prevention rules:
 - `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.
 - A targeted repair shall use a clean, isolated `work/fix/<feature>/<what-fix>` branch and worktree from the taskmaster-verified current `main`. Do not use `work/<feature>/fix/<what-fix>`: the persistent `work/<feature>` ref already occupies that Git ref prefix.
- `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/tasks` exposes focused Task eligibility, batch-transfer, unfinished-count, and retained-history operations required by Project workflows. `work/projects` owns pending-exit readiness/approval, direct-removal orchestration, and Project completion transactions.
 - `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.
@@ -167,9 +167,9 @@ Iteration 2 starts only after every continuing branch incorporates the integrate
 |---|---|---|---|---|---|
 | 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-03 | Reassign unfinished Tasks while preserving creator, state, comments, work logs, lifecycle timestamps, and assignment actor/time; exclude pending exit targets from new/self-assignment. | DONE requires assignee reopen; prior attribution remains; pending target keeps existing assignee rights but receives no new work. | `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-04 | Implement Task edit/soft deletion and authorized historical inspection for Leader/self-Task creator plus Project History projection. | Eligible creator controls only while current assignee; deleted/completed Tasks expose retained attribution without invented previous-assignee or edit/status timelines. | `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-05 | Provide repeatable multi-Task/one-recipient transfer batches, unfinished-count, direct-removal transfer, and completion-query operations to Projects. | Each batch is atomic; recipient/pending state rechecked; direct removal transfers all unfinished Tasks atomically; non-deleted/DONE counts remain correct. | `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`
@@ -178,17 +178,17 @@ Iteration 2 starts only after every continuing branch incorporates the integrate
 |---|---|---|---|---|---|
 | 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-03 | Create/cancel Leader-removal and member-leave requests, expose persistent readiness warnings, and keep existing rights while excluding the target from new/self-assignment. | Nonblank reason, same-Project/type shape, one pending request per target, requester-only cancellation, replacement/remaining/ready state for every authorized viewer. | `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-04 | Let only the owning Mentor approve/reject exits after Leader-managed redistribution; preserve the direct-removal automatic-transfer shortcut. | Leader exit requires replacement first; repeated batches persist; cancel/reject keeps them and restores eligibility; approval waits for non-Leader/zero unfinished Tasks; closure/request resolution commit together. | `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` | — | — |
+| I2-PRJ-06 | Provide one authorized Project History view for membership, leadership, invitation, exit decision, completed/soft-deleted Task, comment, work-log, and retained attribution data. | Admin all read-only; owning Mentor/current member on open Project; removed member denied until completion; no fabricated previous-assignee/status/edit timeline. | `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-01 | Schedule future-month attendance-policy versions, including separate grace values, preserve effective history, and expose Admin-only Policy History. | First-of-future-month rule; effective immutability; old cutoff/report stability; safe version/actor/effective metadata only. | `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-02 | Preview/import VN HolidayAPI candidates with Admin selection, override, provenance, deduplication, and Admin-only Calendar History. | Public suggestion not authority; manual fallback; repeated import safety; past/current event metadata remains read-only and non-secret. | `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` | — | — |
@@ -200,7 +200,7 @@ Iteration 2 starts only after every continuing branch incorporates the integrate
 | 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-02 | Complete account, integration, Project, invitation, membership-exit/transfer, Task, policy/calendar, attendance, correction, leave, and History desktop workflows using shared fragments. | Persistent warning; Leader-only multi-Task/one-recipient drawer; Mentor readiness decision; Project History; Admin-only Policy/Calendar/SMTP/HolidayAPI History; keyboard operation, redaction, and clear conflicts. | `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` | — | — |
@@ -221,10 +221,13 @@ Exit demonstration:
 - 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 reassigns an unfinished Task while preserving creator, comments, work logs, and current assignment attribution.
 - 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.
+- Member requests to leave and Leader requests removal; all authorized viewers see readiness, replacement is appointed first when needed, Leader redistributes unfinished Tasks in repeated batches, cancellation/rejection keeps completed batches, and approval waits for zero unfinished Tasks.
 - Mentor directly removes an ordinary member and a Leader in separate cases; automatic transfer remains atomic and completed Tasks keep the removed Intern's displayed name.
 - Admin, owning Mentor, current member, and removed member before/after completion receive the exact Project History visibility defined by AUTH-006.
 - Admin opens read-only Attendance Policy, Calendar, SMTP, and HolidayAPI History tabs; non-Admins are denied and no secret/internal retry data appears.
 - 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.
@@ -0,0 +1,16 @@
 .git
 .gitea
 .idea
 .agents
 .superpowers
 .env
 .env.*
 !.env.compose.example
 labtimesheet-docs-hub
 node_modules
 target
 docs
 src/test
 *.log
 *.7z
 .DS_Store
@@ -0,0 +1,20 @@
 # Production Compose example only. Store the real file outside the repository with mode 0600.
 # Use an immutable sha-<full-commit> tag. The moving main tag is for convenience, not rollback.
 LAB_IMAGE=git.sechmachine.io.vn/sechmachine/labtimesheet:sha-replace-with-full-commit
 # The app is intended to sit behind an HTTPS reverse proxy on the same host.
 LAB_HTTP_BIND=127.0.0.1
 LAB_HTTP_PORT=8080
 LAB_PUBLIC_ORIGIN=https://timesheet.example.edu
 LAB_FORWARD_HEADERS_STRATEGY=framework
 LAB_SECURITY_MASTER_KEY=replace-with-base64-encoded-32-byte-key
 # Bundled mode uses the Compose service name. For external mode, replace this URL and credentials.
 LAB_DB_URL=jdbc:postgresql://postgres:5432/labtimesheet
 LAB_DB_USERNAME=labtimesheet
 LAB_DB_PASSWORD=replace-with-database-password
 # Used only when the bundled-db profile is enabled.
 POSTGRES_DB=labtimesheet
 POSTGRES_USER=labtimesheet
 POSTGRES_PASSWORD=replace-with-the-same-database-password
@@ -0,0 +1,207 @@
 name: Container
 'on':
  workflow_dispatch:
  push:
    branches:
      - main
 permissions:
  contents: read
 concurrency:
  group: container-${{ gitea.workflow }}-${{ gitea.ref }}
  cancel-in-progress: true
 env:
  REGISTRY: git.sechmachine.io.vn
  IMAGE_NAME: sechmachine/labtimesheet
 jobs:
  verify:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    env:
      TESTCONTAINERS_HOST_OVERRIDE: host.docker.internal
    steps:
      - name: Check out source
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - name: Set up Java 25
        uses: actions/setup-java@b6effb05e454b25005698d916606bdc6ffcbf961 # v5.7.0
        with:
          distribution: temurin
          java-version: '25'
          cache: maven
      - name: Set up Node 24
        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
        with:
          node-version: '24'
          cache: npm
      - name: Verify Docker for PostgreSQL tests
        run: docker info
      - name: Install frontend dependencies
        run: npm ci
      - name: Run frontend tests
        run: npm run test:ui
      - name: Build frontend assets
        run: npm run build
      - name: Verify generated assets are committed
        run: git diff --exit-code -- src/main/resources/static/assets/app.css src/main/resources/static/assets/icons.svg
      - name: Run Maven tests
        run: ./mvnw -B test
      - name: Verify Javadoc
        run: ./mvnw -B -DskipTests -Ddoclint=all javadoc:javadoc
      - name: Verify whitespace
        run: git diff --check
  amd64:
    needs: verify
    runs-on: ubuntu-latest
    timeout-minutes: 30
    permissions:
      contents: read
      packages: write
    steps:
      - name: Check out source
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - name: Set up Buildx
        uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c # v4.2.0
      - name: Select image tags
        id: image
        env:
          EVENT_NAME: ${{ gitea.event_name }}
          GITEA_REF: ${{ gitea.ref }}
          GITEA_SHA: ${{ gitea.sha }}
        run: |
          publish=false
          image="$REGISTRY/$IMAGE_NAME"
          if [ "$EVENT_NAME" = "push" ] && [ "$GITEA_REF" = "refs/heads/main" ]; then
            publish=true
          fi
          {
            echo "publish=$publish"
            echo "image=$image"
            echo "tags<<EOF"
            echo "$image:sha-${GITEA_SHA}-amd64"
            if [ "$publish" = "true" ]; then
              echo "$image:sha-${GITEA_SHA}"
              echo "$image:main"
            fi
            echo "EOF"
          } >> "$GITHUB_OUTPUT"
      - name: Log in to registry
        if: steps.image.outputs.publish == 'true'
        uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ gitea.actor }}
          password: ${{ secrets.REGISTRY_TOKEN }}
      - name: Build AMD64 image and publish main
        uses: docker/build-push-action@53b7df96c91f9c12dcc8a07bcb9ccacbed38856a # v7.3.0
        with:
          context: .
          platforms: linux/amd64
          push: ${{ steps.image.outputs.publish }}
          tags: ${{ steps.image.outputs.tags }}
          build-args: |
            VCS_REF=${{ gitea.sha }}
  arm64:
    # Gitea cannot schedule a probe on a missing label. Enable this repository variable only
    # while a trusted ubuntu-latest-arm runner is registered and online.
    if: vars.ARM64_RUNNER_AVAILABLE == 'true'
    needs: verify
    runs-on: ubuntu-latest-arm
    timeout-minutes: 30
    permissions:
      contents: read
      packages: write
    steps:
      - name: Check out source
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - name: Set up Buildx
        uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c # v4.2.0
      - name: Select image tag
        id: image
        env:
          EVENT_NAME: ${{ gitea.event_name }}
          GITEA_REF: ${{ gitea.ref }}
          GITEA_SHA: ${{ gitea.sha }}
        run: |
          publish=false
          image="$REGISTRY/$IMAGE_NAME"
          if [ "$EVENT_NAME" = "push" ] && [ "$GITEA_REF" = "refs/heads/main" ]; then
            publish=true
          fi
          echo "publish=$publish" >> "$GITHUB_OUTPUT"
          echo "tag=$image:sha-${GITEA_SHA}-arm64" >> "$GITHUB_OUTPUT"
      - name: Log in to registry
        if: steps.image.outputs.publish == 'true'
        uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ gitea.actor }}
          password: ${{ secrets.REGISTRY_TOKEN }}
      - name: Build native ARM64 image
        uses: docker/build-push-action@53b7df96c91f9c12dcc8a07bcb9ccacbed38856a # v7.3.0
        with:
          context: .
          platforms: linux/arm64
          push: ${{ steps.image.outputs.publish }}
          tags: ${{ steps.image.outputs.tag }}
          build-args: |
            VCS_REF=${{ gitea.sha }}
  manifest:
    if: gitea.event_name == 'push' && gitea.ref == 'refs/heads/main' && vars.ARM64_RUNNER_AVAILABLE == 'true'
    needs: [amd64, arm64]
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      contents: read
      packages: write
    steps:
      - name: Set up Buildx
        uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c # v4.2.0
      - name: Log in to registry
        uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ gitea.actor }}
          password: ${{ secrets.REGISTRY_TOKEN }}
      - name: Publish combined manifest
        env:
          IMAGE: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          GITEA_SHA: ${{ gitea.sha }}
        run: |
          docker buildx imagetools create \
            --tag "$IMAGE:sha-${GITEA_SHA}" \
            --tag "$IMAGE:main" \
            "$IMAGE:sha-${GITEA_SHA}-amd64" \
            "$IMAGE:sha-${GITEA_SHA}-arm64"
@@ -0,0 +1,61 @@
 name: Verify
 'on':
  pull_request:
  push:
 permissions:
  contents: read
 concurrency:
  group: verify-${{ gitea.workflow }}-${{ gitea.ref }}
  cancel-in-progress: true
 jobs:
  verify:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    env:
      TESTCONTAINERS_HOST_OVERRIDE: host.docker.internal
    steps:
      - name: Check out source
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - name: Set up Java 25
        uses: actions/setup-java@b6effb05e454b25005698d916606bdc6ffcbf961 # v5.7.0
        with:
          distribution: temurin
          java-version: '25'
          cache: maven
      - name: Set up Node 24
        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
        with:
          node-version: '24'
          cache: npm
      - name: Verify Docker for PostgreSQL tests
        run: docker info
      - name: Install frontend dependencies
        run: npm ci
      - name: Run frontend tests
        run: npm run test:ui
      - name: Build frontend assets
        run: npm run build
      - name: Verify generated assets are committed
        run: git diff --exit-code -- src/main/resources/static/assets/app.css src/main/resources/static/assets/icons.svg
      - name: Run Maven tests
        run: ./mvnw -B test
      - name: Verify Javadoc
        run: ./mvnw -B -DskipTests -Ddoclint=all javadoc:javadoc
      - name: Verify whitespace
        run: git diff --check
@@ -3,6 +3,7 @@ target/
 .mvn/wrapper/maven-wrapper.jar
 !**/src/main/**/target/
 !**/src/test/**/target/
 .DS_Store
 ### STS ###
 .apt_generated
@@ -54,6 +54,10 @@ Within a feature, create only layers it needs from `controller`, `model`, `model
 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.
 Membership-exit implementation must preserve two distinct paths. A pending exit keeps membership and existing Task rights active but excludes the target from new/self-assignment; the current/new Leader performs repeatable atomic multi-Task/one-recipient transfer batches before Mentor approval, and cancellation/rejection does not undo completed batches. Direct Mentor removal remains the atomic shortcut that transfers all unfinished Tasks to the current or replacement Leader. Completed Tasks keep the removed member's historical assignee name.
 History UI must read the retained feature-owned rows already present. Project History covers memberships, leadership, invitations, exit decisions, completed/soft-deleted Tasks, comments, work logs, and stored attribution under AUTH-006 visibility. Admin-only Policy, Calendar, SMTP, and HolidayAPI History exposes non-secret domain metadata only. Do not add a generic audit/event-sourcing layer, Task-assignment-history table, or fabricated previous-assignee/status/edit timeline.
 ## 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.
@@ -146,7 +150,9 @@ npm run build
 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.
+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. Production container checks supplement those gates; they do not substitute for them.
 The root `Dockerfile`, `compose.yaml`, and `.env.compose.example` are production-only. Development runs Java from the IDE or Maven as documented in `DEVELOPMENT.md`. Only `main` may publish container images. Native ARM64 publication is gated by the repository variable `ARM64_RUNNER_AVAILABLE`; leave it absent or false unless a trusted `ubuntu-latest-arm` runner is online.
 ## Post-iteration integration and push
@@ -0,0 +1,68 @@
 # Production Container Deployment
 These files deploy Lab Timesheet in production. They are not the development workflow; continue using [DEVELOPMENT.md](DEVELOPMENT.md) for IDE work.
 ## 1. Prepare the host
 Install Docker Engine and Docker Compose v2.20 or newer. Put an HTTPS reverse proxy in front of the application. By default, Compose binds the application only to `127.0.0.1:8080`.
 Copy [`.env.compose.example`](.env.compose.example) to a protected path outside the repository:
 ```bash
 sudo install -d -m 0700 /etc/labtimesheet
 sudo install -m 0600 .env.compose.example /etc/labtimesheet/compose.env
 sudo editor /etc/labtimesheet/compose.env
 ```
 Generate `LAB_SECURITY_MASTER_KEY` with `openssl rand -base64 32`. Use an immutable `sha-<full-commit>` application image tag. Never place Admin-managed SMTP or HolidayAPI credentials in this file.
 ## 2. Choose the database topology
 ### Bundled PostgreSQL 18.4
 Keep the example JDBC host `postgres`, then run:
 ```bash
 docker compose --env-file /etc/labtimesheet/compose.env --profile bundled-db up -d
 docker compose --env-file /etc/labtimesheet/compose.env ps
 ```
 The application waits for PostgreSQL health and stores database files in the `postgres_data` named volume.
 ### External PostgreSQL
 Set `LAB_DB_URL`, `LAB_DB_USERNAME`, and `LAB_DB_PASSWORD` for the external database. Do not enable the `bundled-db` profile:
 ```bash
 docker compose --env-file /etc/labtimesheet/compose.env up -d app
 docker compose --env-file /etc/labtimesheet/compose.env ps
 ```
 The same application image is used in both modes.
 ## 3. Health and operation
 - Liveness: `GET /actuator/health/liveness`
 - Readiness: `GET /actuator/health/readiness` (includes PostgreSQL)
 - Logs: `docker compose --env-file /etc/labtimesheet/compose.env logs -f app`
 The container runs as UID/GID `10001`, with a read-only root filesystem, no Linux capabilities, and only `/tmp` writable. TLS termination is intentionally outside this Compose example.
 Back up PostgreSQL with database-aware tooling such as `pg_dump`. The named volume survives container replacement, but it is not a backup. Test restore procedures before upgrades.
 To update or roll back, change `LAB_IMAGE` to the required immutable SHA tag and run `docker compose ... up -d` again. Keep the previous SHA recorded until the new image is healthy.
 ## 4. Gitea Actions setup
 Configure these repository settings:
 | Kind | Name | Value |
 |---|---|---|
 | Variable | `ARM64_RUNNER_AVAILABLE` | `true` only while a trusted `ubuntu-latest-arm` runner is registered and online; otherwise omit it or set `false` |
 | Secret | `REGISTRY_TOKEN` | Token for the triggering Gitea account with package read/write access |
 The workflow publishes `git.sechmachine.io.vn/sechmachine/labtimesheet` and authenticates as the triggering Gitea account. `verify.yml` runs for every pull request and push. `container.yml` runs only when manually dispatched or when `main` is pushed, and it repeats verification before either architecture build. Manual runs build without publishing. A push to `main` publishes immutable `sha-<commit>` and convenience `main` tags.
 When ARM64 is disabled, those canonical tags remain valid AMD64 images and the workflow succeeds. When it is enabled, the native ARM runner publishes an architecture tag and the final job replaces the canonical tags with a combined AMD64/ARM64 manifest. Gitea cannot discover an unavailable runner from inside an unscheduled job, so the repository variable is the deliberate availability gate.
 The workflows stop at verification and image publication. They do not contain SSH deployment or receive host deployment secrets.
@@ -4,8 +4,9 @@ This guide explains how to prepare and run Lab Timesheet on a developer
 computer. The application runs from Java. PostgreSQL and Mailpit run in Docker
 containers.
-Application containerization and Docker Compose are planned for a later
+The root Dockerfile and Compose file are production-only. They are not part of
-iteration, so they are not required for Iteration 1 development.
+the development loop. Development still runs Java from the IDE or Maven while
 PostgreSQL and Mailpit run as separate local containers.
 ## 1. Install the required tools
@@ -251,3 +252,7 @@ npm run build
 For test setup, commands, TDD, and test evidence rules, read
 [TESTING.md](TESTING.md).
 For production image and Compose operation, read [DEPLOYMENT.md](DEPLOYMENT.md).
 Do not use the production Compose file as a replacement for this development
 setup.
@@ -0,0 +1,38 @@
 # Multi-stage production build. Base images are pinned multi-architecture indexes.
 FROM node:24-alpine@sha256:d32cdf619f63fe0471182d08996dd516c6275bb5fd31ae06e55a570bd9e1ad43 AS frontend
 WORKDIR /workspace
 COPY package.json package-lock.json ./
 RUN npm ci
 COPY src/main ./src/main
 RUN npm run build
 FROM eclipse-temurin:25-jdk-alpine@sha256:5ecfde8e5ecde5954ea3721155b345ef56c1d579b940c761318ad4c05959a151 AS builder
 WORKDIR /workspace
 RUN apk add --no-cache curl
 COPY .mvn .mvn
 COPY mvnw pom.xml ./
 RUN ./mvnw -B -Dmaven.test.skip=true dependency:go-offline
 COPY src/main ./src/main
 COPY --from=frontend /workspace/src/main/resources/static/assets/app.css ./src/main/resources/static/assets/app.css
 COPY --from=frontend /workspace/src/main/resources/static/assets/icons.svg ./src/main/resources/static/assets/icons.svg
 RUN ./mvnw -B -Dmaven.test.skip=true package
 FROM eclipse-temurin:25-jre-alpine@sha256:28db6fdf60e38945e43d840c0333aeaec66c15943070104f7586fd3c9d1665b0
 ARG VCS_REF=unknown
 ARG SOURCE_URL=https://git.sechmachine.io.vn/sechmachine/labtimesheet
 LABEL org.opencontainers.image.title="Lab Timesheet" \
      org.opencontainers.image.source="${SOURCE_URL}" \
      org.opencontainers.image.revision="${VCS_REF}"
 RUN addgroup -S -g 10001 app && adduser -S -D -H -u 10001 -G app app
 WORKDIR /app
 COPY --from=builder --chown=10001:10001 /workspace/target/*.war /app/app.war
 ENV SPRING_PROFILES_ACTIVE=prod \
    JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75.0"
 EXPOSE 8080
 USER 10001:10001
 HEALTHCHECK --interval=30s --timeout=5s --start-period=45s --retries=3 CMD wget -q -O /dev/null http://127.0.0.1:8080/actuator/health/readiness || exit 1
 ENTRYPOINT ["java", "-jar", "/app/app.war"]
@@ -17,10 +17,10 @@ web
 ## 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.
+- **Admins** operate accounts, internship lifecycles, attendance policy, the global calendar, SMTP, HolidayAPI, and system configuration. They inspect all Project and attendance progress/history read-only 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.
+- **Mentors** own Projects, directly manage membership and leadership, decide membership exits, monitor Project and Intern progress/history, 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.
+- **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 when eligible, perform assigned Tasks, comment, update their own assigned Task status, record Task work, and inspect authorized Project history.
- 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.
+- 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, manage Task definitions/assignment, and redistribute unfinished Tasks away from a pending exit target in confirmed batches.
 - The product is reviewed and maintained by a university project team and its instructor or appointed maintainer.
 ## Product Purpose
@@ -46,13 +46,13 @@ The product joins attendance oversight and Project delivery without pretending t
 ## 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.
+- 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. Pending exit keeps existing rights but blocks new/self-assignment to the target; the Leader redistributes unfinished Tasks before approval, while direct Mentor removal retains its atomic automatic-transfer shortcut.
 - 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.
+- Global attendance policy is effective-dated; historical attendance and leave allocations must not drift after later policy or calendar changes. Admin-only setting History tabs and authorized Project History read the retained domain rows already present; they never expose secrets or invent previous-assignee/status/edit timelines that are not stored.
 - 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.
@@ -75,7 +75,7 @@ The product joins attendance oversight and Project delivery without pretending t
 ## 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.
+2. **History does not move or pretend.** Later policy, calendar, membership, invitation, exit decision, leadership, assignment, or assignee changes must not silently rewrite past results, completed-Task assignee names, creator attribution, or provenance. History views expose only retained domain facts and non-secret metadata; they do not fabricate event timelines the schema never stored.
 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.
@@ -49,8 +49,8 @@ Projects, Tasks, and attendance. Iteration 1 is complete and was verified on
 The baseline schema includes later-workflow tables; table presence does not mean
 the corresponding feature is complete.
- Iteration 2: Project invitations and approved membership exits, broader Project lifecycle transfers, Task edit/delete/reassignment and work logs, leave, missed-checkout corrections, notifications, schedulers, and complete metrics.
+- Iteration 2: Project invitations; assisted membership exits with persistent readiness warnings and Leader-managed transfer batches before approval; the existing direct-removal automatic-transfer shortcut; Task edit/delete/reassignment and work logs; authorized Project History; Admin-only non-secret Policy/Calendar/SMTP/HolidayAPI History; leave, missed-checkout corrections, notifications, schedulers, and complete metrics.
- Iteration 3: HTML/XLSX/PDF report parity, Chart.js trends, production security hardening, application containers, Compose, Gitea CI publication, and deployment scaffolding.
+- Iteration 3: HTML/XLSX/PDF report parity, Chart.js trends, remaining production security hardening, and operational backup/restore qualification.
 - Mobile layouts are best-effort. Desktop is the supported interface target.
 ## Architecture and versions
@@ -116,6 +116,21 @@ See [TESTING.md](TESTING.md) for setup, test commands, the required TDD cycle,
 evidence records, best practices, and common fixes. Every behavior test has a
 companion record under [`docs/tests`](docs/tests/README.md).
 ## Continuous integration and production containers
 Gitea Actions verifies every pull request and push. The separate container
 workflow runs only for a manual dispatch or a push to `main`, and its verification
 job must pass before either image build starts. Manual runs build without publishing;
 `main` pushes publish Linux AMD64 and add native Linux ARM64 only when the repository
 explicitly declares that its ARM runner is online. Every published revision has an
 immutable `sha-<full-commit>` tag, with `main` as a convenience alias.
 The production image is a non-root Java 25 image. The root [compose.yaml](compose.yaml)
 supports either a persistent PostgreSQL 18.4 sidecar or an external PostgreSQL
 database. It is not used for development. Follow [DEPLOYMENT.md](DEPLOYMENT.md)
 and start from [`.env.compose.example`](.env.compose.example); keep the real
 production environment file outside the repository.
 ## Branch ownership
 | Branch | Primary area |
@@ -0,0 +1,178 @@
 # Lab Timesheet Technology Stack
 This document is the team reference for the technologies and development tools
 used by Lab Timesheet. The five-person development team uses Windows 11 and
 IntelliJ IDEA. Versions controlled by the repository must not be changed in one
 developer's environment without a reviewed project-wide update.
 ## 1. Architecture
 | Choice | Use | Rationale |
 |---|---|---|
 | Server-rendered modular monolith | One Spring Boot application organized by account, integration, Project, Task, attendance, notification, and reporting features | A single deployable application keeps transactions, authorization, testing, and deployment manageable for a small team while feature packages preserve clear ownership. |
 | Spring MVC with Thymeleaf | Controllers return HTML pages rendered on the server | The product is a form- and workflow-heavy desktop web application. Server rendering avoids the extra API, SPA state, and authentication complexity of a separate frontend application. |
 | Feature-first Java packages | Each feature owns its controllers, DTOs, entities, repositories, services, and exceptions | Related code stays together, while cross-feature access is limited to public services and DTOs. This supports the five-branch team workflow without duplicating database models. |
 | Executable WAR | Maven packages the application as a WAR that can still run with `java -jar` | It works with the current Spring Boot deployment while keeping conventional servlet-container compatibility. |
 | HTML sessions and CSRF protection | Spring Security manages authenticated browser sessions | The application is server-rendered. Session cookies and CSRF protection are simpler and safer here than introducing JWTs. |
 The project deliberately does not use a SPA framework, JWT authentication,
 microservices, Redis, Kafka, or a generic workflow engine. Those technologies
 would add operational and development cost without solving a current need.
 ## 2. Team workstations
 | Tool | Team baseline | Use | Rationale |
 |---|---|---|---|
 | Windows | Windows 11 | Team development operating system | One shared OS baseline makes IDE, Docker, path, and command guidance reproducible for the student team. |
 | IntelliJ IDEA | Current supported release | Main IDE for Java, Maven, Spring Boot, Thymeleaf, debugging, and test execution | IntelliJ has strong Spring and Java support and provides one consistent run/debug workflow for the team. |
 | Eclipse Temurin JDK | Java 25 | Compile, test, and run the application | Java 25 is the project language baseline, and Temurin matches the JDK distribution used by CI and container builds. |
 | IntelliJ annotation processing | Enabled for the project | Makes Lombok-generated constructors and accessors visible to the IDE | Maven already runs Lombok as an annotation processor. Enabling the same behavior in IntelliJ prevents false editor errors. |
 | Git | Current supported release | Version control and the branch/worktree workflow | Git supports the five persistent feature branches, isolated fix branches, review, and traceable milestone commits. |
 | PowerShell | Included with Windows 11 | Run Windows commands and `mvnw.cmd` | It is available on every team workstation and avoids requiring a separate shell for normal development. |
 | OpenSSL | Current supported release | Generates the Base64 256-bit application master key | A standard cryptographic tool avoids inventing or manually typing security keys. Git for Windows or another trusted Windows package may provide it. |
 | Microsoft Edge or Google Chrome | Current stable release | Manual desktop-browser checks and debugging | The product targets desktop browsers, and both provide standards-based developer tools for HTML, CSS, accessibility, storage, and network inspection. |
 ## 3. Java and build platform
 | Technology | Version | Use | Rationale |
 |---|---:|---|---|
 | Java | 25 | Application language and runtime | Provides a modern supported Java baseline while keeping one version across local development, CI, and production. |
 | Spring Boot | 4.1.0 | Application framework and dependency management | Supplies compatible Spring modules, production conventions, testing support, and a managed dependency set. |
 | Maven Wrapper | Wrapper 3.3.4; Maven 3.9.16 | Java dependency resolution, compilation, tests, Javadoc, and packaging | The checked-in wrapper gives every Windows workstation and CI runner the same Maven version without a separate Maven installation. Use `mvnw.cmd` on Windows. |
 | Javadoc with doclint | Java 25 toolchain | Validates generated API documentation | Documentation errors are caught during development and CI with the same JDK that compiles the application. |
 | Lombok | Spring Boot-managed version | Removes mechanical constructors and accessors | Targeted Lombok annotations reduce boilerplate while explicit domain constructors, validation, state changes, and entity identity methods remain visible. |
 | Spring Boot configuration processor | Spring Boot-managed version | Generates typed Spring configuration metadata during compilation | It improves configuration accuracy and IntelliJ assistance without adding runtime code. |
 | Embedded/provided Tomcat | Spring Boot-managed version | Servlet runtime for the executable WAR | It is the standard Spring MVC runtime and requires no separate application server for development or the production image. |
 Unless a row gives an explicit version, Java dependency versions are managed by
 the Spring Boot 4.1.0 dependency set. This prevents individual libraries from
 being upgraded into incompatible combinations.
 ## 4. Spring and Java dependencies
 | Dependency | Use | Rationale |
 |---|---|---|
 | Spring Web MVC | Controllers, request binding, validation errors, and server-rendered routes | It matches the Thymeleaf form workflow and keeps browser navigation on the server. |
 | Spring Security | Login, password hashing, sessions, CSRF, role checks, and security headers | Security rules stay in the established Spring filter and authorization model rather than custom code. |
 | Spring Data JPA and Hibernate | Entity mapping, repositories, transactions, optimistic locking, and pessimistic locks | JPA removes routine persistence code while PostgreSQL and Flyway remain the schema authority. |
 | Spring Validation / Jakarta Validation | Request DTO and configuration validation | Validation annotations provide consistent trust-boundary checks and actionable form errors. |
 | Thymeleaf | HTML page and email-template rendering | Templates integrate directly with Spring MVC and work without a client-side framework. |
 | Thymeleaf Spring Security extras | Role- and authentication-aware template rendering | Navigation and controls can reflect server authorization without duplicating role parsing. |
 | Spring Mail | SMTP connectivity and email delivery | Uses the standard Jakarta Mail integration while SMTP settings remain Admin-managed application data. |
 | Spring Boot Actuator | Liveness, readiness, and application health | Standard health endpoints support Docker health checks and production operations. |
 | Spring Boot Flyway integration | Runs reviewed database migrations at startup | Database changes are ordered, repeatable, and validated before Hibernate mappings are used. |
 | Flyway PostgreSQL support | PostgreSQL-specific migration support | The schema uses PostgreSQL features such as `btree_gist`, checks, partial indexes, and exclusion constraints. |
 | PostgreSQL JDBC driver | Runtime database connection | It is the official Java driver for the selected database. |
 | Spring Boot DevTools | Development-only restart support | Shortens the local feedback loop without becoming a production dependency. |
 | Spring Boot Docker Compose support | Optional runtime integration | It is available for Spring tooling, although the documented development loop currently starts PostgreSQL and Mailpit explicitly. |
 ## 5. Database and persistence
 | Technology | Version | Use | Rationale |
 |---|---:|---|---|
 | PostgreSQL | 18.4 | Development, test, and production database | The domain requires reliable transactions, constraints, date/time types, partial indexes, exclusion constraints, and strong concurrency behavior. Using the same engine everywhere avoids H2-specific surprises. |
 | Flyway | Spring Boot-managed version | Versioned schema migrations | Flyway makes the reviewed SQL schema reproducible on an empty database and safe to validate in CI. |
 | Hibernate schema validation | `ddl-auto=validate` | Confirms entity mappings match the migrated schema | Hibernate must not silently create or alter production tables; Flyway remains authoritative. |
 | PostgreSQL `btree_gist` | Database extension | Supports exclusion constraints such as overlapping leave prevention | The database can reject invalid concurrent data even when two application requests race. |
 ## 6. Frontend stack
 | Technology | Version | Use | Rationale |
 |---|---:|---|---|
 | Thymeleaf | Spring Boot-managed version | Page layouts, fragments, forms, validation messages, and role-aware navigation | It keeps rendering and authorization close to the Spring MVC application. |
 | HTML5 | Browser standard | Semantic forms, tables, native dialogs, and accessible page structure | Native elements reduce custom JavaScript and provide built-in keyboard and form behavior. |
 | Tailwind CSS | 4.3.3 | Compiled design tokens and utility-based styling | It supports the shared light/dark desktop design without shipping a runtime CSS framework. |
 | Tailwind CLI | 4.3.3 | Builds the committed production CSS asset | The small CLI is sufficient; no frontend bundler or SPA toolchain is needed. |
 | Lucide Static | 1.27.0 | Local SVG icon sprite | Icons are available offline, inherit theme color, and do not require React or an icon CDN. |
 | Native JavaScript modules | Browser standard | Small interactions such as theme selection, sidebar state, dialogs, and local search | The current interactions do not justify a client-side application framework. |
 | Node.js | 24.x | Frontend build scripts and JavaScript tests | Node 24 is the pinned LTS toolchain used consistently by developers, CI, and the Docker build. |
 | npm | 11.x | Reproducible frontend dependency installation | `npm ci` and the committed lockfile install exactly the reviewed dependency graph. |
 ## 7. External services and integrations
 | Service or standard | Use | Rationale |
 |---|---|---|
 | SMTP | Activation, password recovery, and ordinary workflow email | SMTP is widely supported and allows the application to work with university or other approved mail providers. Configuration is tested and activated through the Admin console. |
 | Mailpit | Development SMTP server and web inbox | Mailpit captures messages locally so developers never send test activation or recovery email to real users. The development image is pinned to `axllent/mailpit:v1.27.4`. |
 | HolidayAPI | Optional Vietnam holiday preview/import | It reduces manual holiday entry while imported dates remain a preview and the Admin's local day-off decision remains authoritative. |
 | AES-256-GCM from the JDK | Encrypts stored SMTP and HolidayAPI secrets | Authenticated encryption protects confidentiality and detects modification without adding another cryptography dependency. |
 | HTTPS reverse proxy | Production TLS termination and forwarding | The application image stays focused on Java while an operator-managed proxy handles certificates and the public HTTPS endpoint. |
 ## 8. Testing tools
 | Tool | Use | Rationale |
 |---|---|---|
 | JUnit Jupiter | Unit and integration test framework | It is the standard JUnit 5 programming model supplied by Spring Boot and works with Maven Surefire and IntelliJ. |
 | Maven Surefire | Maven/Spring Boot-managed version | Discovers and runs the Java test suite | The same Maven command behaves consistently in IntelliJ terminals, PowerShell, and CI. |
 | Spring Boot Test | Application-context and integration testing | It verifies real Spring configuration, dependency injection, transactions, and profile behavior. |
 | Focused Spring Boot test starters | Data JPA, Flyway, Mail, Security, Thymeleaf, Validation, and Web MVC test support | Each test slice receives the framework support it actually exercises instead of one unrelated test environment. |
 | Spring MVC Test / MockMvc | Controller, security, validation, and Thymeleaf route tests | HTTP behavior can be tested quickly without launching a separate browser process. |
 | Spring Security Test | Authenticated role and CSRF test support | Tests can prove allowed and denied behavior using the same security filter chain. |
 | Mockito | Test doubles for external or out-of-scope collaborators | It isolates a focused unit or MVC slice without replacing the database behavior being tested. |
 | Testcontainers | Spring Boot-managed version | Starts disposable infrastructure for integration tests | Tests use real PostgreSQL 18.4 without depending on a developer's database or leaving shared state behind. |
 | Testcontainers PostgreSQL | PostgreSQL 18.4 test container integration | It validates Flyway SQL, JPA mappings, constraints, locking, and concurrency against the production database engine. |
 | Node built-in test runner | Frontend asset and workflow contract tests | The required JavaScript checks run without adding another test framework. |
 | Playwright | Automated desktop-browser end-to-end journeys | Playwright provides repeatable Chromium-based tests for bootstrap, login, role navigation, Projects, Tasks, attendance, and accessibility-sensitive workflows required by the instructor. |
 | Manual Edge/Chrome journeys | Exploratory and final visual checks | Manual checks still catch layout, focus, contrast, and real-browser integration issues that focused automated tests may not explain clearly. |
 | Markdown evidence records | RED/GREEN and affected-suite evidence under `docs/tests/` | Each feature change remains traceable to requirements, commands, expected results, and test boundaries. |
 ## 9. Reporting technologies
 These tools are approved for the reporting iteration. They must be added with
 reviewed, pinned versions when their corresponding feature is implemented.
 | Technology | Approved baseline | Use | Rationale |
 |---|---:|---|---|
 | Chart.js | 4.5.1 | Meaningful attendance and Project trend charts | It provides accessible, lightweight charts without changing the server-rendered architecture; every chart also requires a text or table alternative. |
 | Apache POI XSSF | Compatible 5.5.x | Excel `.xlsx` exports | POI is the established Java library for native Excel workbooks and supports typed cells and formatting. |
 | OpenPDF `openpdf-html` | Compatible 3.0.x | PDF generation from a dedicated print-safe template | It keeps PDF generation inside Java and supports an embedded Unicode font for Vietnamese content. |
 ## 10. Containers and production delivery
 | Technology | Version or baseline | Use | Rationale |
 |---|---:|---|---|
 | Docker Desktop | Current supported Windows release using Linux containers | Development infrastructure, Testcontainers, and local production-image checks | It provides the Docker Engine expected by PostgreSQL, Mailpit, Testcontainers, and multi-stage builds on Windows 11. |
 | Docker Compose | v2.20 or newer | Production example with bundled or external PostgreSQL | One documented file supports both deployment topologies while retaining persistent database storage. |
 | Docker BuildKit / Buildx | Current workflow-pinned release | Multi-stage and multi-architecture image builds | Buildx produces native Linux AMD64 and optional ARM64 images with reproducible build stages. |
 | Node Alpine image | Node 24, digest-pinned | Builds Tailwind and Lucide assets | Frontend tools do not remain in the final Java runtime image. |
 | Eclipse Temurin images | Java 25 JDK and JRE, digest-pinned | Builds the WAR and runs the production application | Separate build and runtime images reduce the final image size and match the Java baseline. |
 | PostgreSQL image | 18.4, digest-pinned | Optional bundled production database | Digest pinning prevents an image tag from silently changing during deployment. |
 | OCI image registry | Gitea package registry | Stores immutable application images | Commit-SHA tags make a deployed version identifiable and allow a controlled rollback. |
 The final application container runs as non-root UID/GID `10001`, uses a
 read-only root filesystem in Compose, drops Linux capabilities, and exposes
 Actuator readiness and liveness checks.
 ## 11. Source control and CI/CD
 | Tool | Use | Rationale |
 |---|---|---|
 | Gitea | Git hosting, review, Actions, and OCI package registry | One project-owned platform stores source, reviews changes, runs checks, and publishes production images. |
 | Gitea Actions | Verification on every pull request and push | CI repeats frontend, Java, PostgreSQL, Javadoc, generated-asset, and whitespace checks outside a developer workstation. |
 | Container workflow | Manual dispatch or `main` push only | Image builds are expensive and potentially publish artifacts, so they run only after an internal verification job and never for ordinary feature branches or pull requests. |
 | `actions/checkout` | 7.0.1, immutable SHA pin | Checks out source without retaining push credentials | An immutable pin prevents a moving action tag from changing CI behavior unexpectedly. |
 | `actions/setup-java` | 5.7.0, immutable SHA pin | Installs Temurin Java 25 and manages the Maven cache | CI uses the same Java baseline as the team and production build. |
 | `actions/setup-node` | 7.0.0, immutable SHA pin | Installs Node 24 and manages the npm cache | CI uses the same frontend toolchain as the lockfile and Docker build. |
 | Docker Buildx action | 4.2.0, immutable SHA pin | Prepares multi-architecture image building | It supports native AMD64 and optional native ARM64 production builds. |
 | Docker Login action | 4.6.0, immutable SHA pin | Authenticates only publication jobs to the registry | Registry credentials stay out of scripts and are used only when publishing is authorized. |
 | Docker Build Push action | 7.3.0, immutable SHA pin | Builds and publishes OCI images | It provides one reviewed image-build path for both supported Linux architectures. |
 ## 12. Configuration and source-of-truth files
 | File | Controls |
 |---|---|
 | `pom.xml` | Java version, Spring Boot version, Java dependencies, packaging, and annotation processors |
 | `.mvn/wrapper/maven-wrapper.properties` | Maven Wrapper and Maven distribution |
 | `package.json` and `package-lock.json` | Node/npm baseline and exact frontend dependencies |
 | `src/main/resources/application*.yaml` | Shared, development, and production Spring configuration |
 | `src/main/resources/db/migration/` | Flyway database schema history |
 | `Dockerfile` | Production multi-stage application image |
 | `compose.yaml` | Production application and optional PostgreSQL deployment example |
 | `.gitea/workflows/` | Verification and container publication workflows |
 | `DEVELOPMENT.md` | Windows/IDE-oriented local setup and run instructions |
 | `TESTING.md` | Test commands, TDD rules, and evidence format |
 | `DEPLOYMENT.md` | Production container configuration and operation |
 When documentation and a build file disagree about an installed version, the
 build file and lockfile are authoritative. Update this document in the same
 reviewed change whenever the selected stack changes.
@@ -219,6 +219,17 @@ claim never replaces a test command and result.
 - Give tests names that describe the rule and expected result.
 - Clean up temporary browser data, application processes, and manually started containers after end-to-end work.
 ### What CI runs
 Gitea runs the frontend tests/build, complete Maven/PostgreSQL suite, Javadoc,
 generated-asset check, and whitespace check for every pull request and push.
 The separate container workflow runs only when manually dispatched or when
 `main` is pushed. It repeats the verification job before building either image.
 Manual runs do not publish; only a push to `main` publishes.
 Run focused and affected tests locally before pushing. CI is the shared
 confirmation, not a substitute for local RED and GREEN evidence.
 ## 8. Common problems
 ### Testcontainers cannot find Docker
@@ -226,6 +237,10 @@ claim never replaces a test command and result.
 Start Docker Desktop or OrbStack. Run `docker version`. OrbStack users should
 also check the `DOCKER_HOST` command shown in Section 1.
 The Gitea Docker runner exposes the daemon through Docker Desktop, so its jobs
 set `TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal`. Keep that override if
 the runner stays containerized; otherwise Ryuk may try an unreachable bridge IP.
 ### The wrong Java version is used
 Run `java -version` and `./mvnw -version`. Both should report Java 25. Set
@@ -1,9 +1,63 @@
 # Production deployment example. Development continues to run Java from the IDE.
 name: labtimesheet-prod
 services:
-  postgres:
+  app:
-    image: 'postgres:latest'
+    image: "${LAB_IMAGE:?Set LAB_IMAGE to an immutable sha-* image tag}"
    restart: unless-stopped
    environment:
-      - 'POSTGRES_DB=mydatabase'
+      SPRING_PROFILES_ACTIVE: prod
-      - 'POSTGRES_PASSWORD=secret'
+      LAB_DB_URL: "${LAB_DB_URL:?Set the JDBC PostgreSQL URL}"
-      - 'POSTGRES_USER=myuser'
+      LAB_DB_USERNAME: "${LAB_DB_USERNAME:?Set the database username}"
      LAB_DB_PASSWORD: "${LAB_DB_PASSWORD:?Set the database password}"
      LAB_PUBLIC_ORIGIN: "${LAB_PUBLIC_ORIGIN:?Set the public HTTPS origin}"
      LAB_SECURITY_MASTER_KEY: "${LAB_SECURITY_MASTER_KEY:?Set a Base64 256-bit key}"
      LAB_FORWARD_HEADERS_STRATEGY: "${LAB_FORWARD_HEADERS_STRATEGY:?Set the explicit proxy strategy}"
    ports:
-      - '5432'
+      # Bind locally by default; terminate HTTPS in a reverse proxy on the same host.
      - "${LAB_HTTP_BIND:-127.0.0.1}:${LAB_HTTP_PORT:-8080}:8080"
    depends_on:
      postgres:
        condition: service_healthy
        # External-database mode leaves the bundled-db profile disabled.
        required: false
    read_only: true
    tmpfs:
      - /tmp:size=64m,mode=1777
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    stop_grace_period: 40s
    healthcheck:
      test: ["CMD", "wget", "-q", "-O", "/dev/null", "http://127.0.0.1:8080/actuator/health/readiness"]
      interval: 30s
      timeout: 5s
      start_period: 45s
      retries: 3
  postgres:
    # Pinned PostgreSQL 18.4 multi-architecture image.
    image: postgres:18.4@sha256:a02db8cac496f15b094798a38254f14d6e00741f709360e5e00bb6668ea31636
    profiles: ["bundled-db"]
    restart: unless-stopped
    environment:
      POSTGRES_DB: "${POSTGRES_DB:-labtimesheet}"
      POSTGRES_USER: "${POSTGRES_USER:-labtimesheet}"
      POSTGRES_PASSWORD: "${POSTGRES_PASSWORD:?Set the bundled PostgreSQL password}"
    volumes:
      # PostgreSQL 18 stores versioned data beneath this parent directory.
      - postgres_data:/var/lib/postgresql
    shm_size: 256mb
    security_opt:
      - no-new-privileges:true
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U \"$$POSTGRES_USER\" -d \"$$POSTGRES_DB\""]
      interval: 10s
      timeout: 5s
      retries: 10
      start_period: 10s
 volumes:
  # Container replacement keeps this volume. It is not a substitute for backups.
  postgres_data:
@@ -0,0 +1,27 @@
 # Assisted Exit Transfer and History Documentation Plan
 **Status:** Documentation update only. No application or schema implementation is authorized by this record.  
 **Date:** 20 August 2026
 ## Deliverables
 1. Amend the existing `AUTH`, `PRJ`, `TSK`, `ATT`, `CAL`, `INT`, `UI`, and `DB` rows without adding requirement IDs.
 2. Synchronize the explained and very-simple teaching copies.
 3. Update `UC-04`, `UC-05`, `UC-06`, and `UC-14`, required workflow pages, and regenerate the SRS from its generator.
 4. Update `PRODUCT.md`, `.agents/PROJECT_PLAN.md`, `AGENTS.md`, and `README.md` with the locked boundary and Iteration 2 ownership.
 5. Add the append-only requirements update manifest.
 6. Preserve both DDL files, both Mermaid structures, all mockup/reference assets, and `.DS_Store` byte-for-byte.
 ## Validation gates
 - Exactly 260 unique requirement rows in authoritative, explained, simple, and generated SRS catalogues.
 - Exactly 14 SRS use cases.
 - Exactly 23 documented tables and 56 named foreign-key relationships; no DDL byte change.
 - Generated SRS agrees with the canonical requirement rows and updated use cases/workflow pages.
 - All local Markdown links resolve.
 - Protected DDL/mockup/reference hashes and `.DS_Store` hash match the pre-update snapshot.
 - `git diff --check` passes.
 ## Non-goals
 No Java, Flyway, SQL, Mermaid structure, mockup, frontend asset, branch, commit, push, or deployment change is part of this task.
@@ -0,0 +1,45 @@
 # Assisted Exit Transfer and History Design
 **Status:** Approved documentation baseline; application implementation remains Iteration 2 work.  
 **Date:** 20 August 2026  
 **Authority:** Current primary-implementor decision, applied through existing requirement IDs.
 ## Purpose
 Define a safe, understandable way to prepare a member's requested Project exit and expose useful retained history without changing the approved database structure.
 ## Assisted pending exit
 A pending request keeps membership, existing assignments, and existing Task rights active. The target cannot receive a newly created/reassigned Task or create a self-Task. Every authorized Project viewer sees one readiness state: replacement Leader required, unfinished Task count, or ready for Mentor decision.
 When the target is Leader, the owning Mentor appoints the replacement first. The current/new Leader then uses a right-side drawer to select multiple unfinished `TODO`, `IN_PROGRESS`, or `BLOCKED` Tasks and one eligible active current member. One confirmation commits one immediate all-or-none batch. The Leader repeats until no unfinished Tasks remain.
 Cancellation or rejection restores the target's new-assignment eligibility but does not undo completed transfer batches. Approval is allowed only when the target is no longer Leader and owns zero unfinished Tasks; request approval and membership closure then commit atomically.
 ## Direct Mentor removal
 Direct removal remains the existing atomic shortcut. An ordinary member's unfinished Tasks transfer to the current Leader. Removing the current Leader requires a replacement and transfers unfinished Tasks to that replacement. Completed Tasks never move and continue to display the removed Intern's retained name.
 ## History views
 One Project History tab reads retained feature-owned records for memberships, leadership, invitations, exit decisions, completed and soft-deleted Tasks, comments, work logs, and stored attribution. Admin sees all Projects read-only; the owning Mentor and current members see authorized open Projects; removed members regain read-only Project history only after completion.
 Task history shows creator, current/final assignee, status/dates, comment/work-log authors, and deletion attribution. It does not claim previous-assignee or edit/status-event timelines that the schema does not store.
 Admin-only read-only History tabs cover Attendance Policy, Calendar, SMTP, and HolidayAPI. They show user-meaningful non-secret metadata and never expose tokens, ciphertext/nonces, passwords, API keys, master-key material, bootstrap state, or internal retry records.
 ## Persistence boundary
 No table, foreign key, DDL statement, or Mermaid entity changes. The existing 23 tables and 56 foreign keys already retain the required domain records. `GOV-009` remains authoritative: no generic audit/event-sourcing or Task-assignment-history table.
 ## Iteration ownership
 - `work/tasks`: pending-target assignment exclusion, atomic batch transfer, direct-removal transfer helper, unfinished count, and retained Task projection.
 - `work/projects`: exit readiness, Leader replacement order, approval guard/closure, direct-removal orchestration, and Project-history authorization.
 - `work/attendance`: policy/calendar retained-history queries.
 - `work/platform`: non-secret SMTP/HolidayAPI revision-history queries.
 - `work/reports-ui`: persistent warning, transfer drawer, Project History, and Admin-setting History tabs.
 ## Acceptance focus
 Tests must cover replacement-before-transfer, a newly joined eligible recipient, pending-target exclusion, repeatable batches, cancel/reject without rollback, zero-unfinished approval guard, direct-removal atomic transfer, completed-name retention, every history role boundary, and secret redaction.
@@ -0,0 +1,106 @@
 # Test Evidence: Gitea Testcontainers and container workflow gates
 - **Test type:** Integration
 - **Requirement IDs:** `OPS-011`, `OPS-012`, `TST-001`, `TST-005`, `TST-009`
 - **Scenario IDs:** `AC-OPS-002`, `AC-OPS-004`
 - **Test class/method:** `src/test/js/delivery-contract.test.mjs`
 - **Implementation commit:** `d13443e338770dec0ca9822600f9a9d8405dfdbb`
 ## Protected behavior
 Gitea verification must reach Docker Desktop-published Testcontainers ports from
 inside its job container. Container builds may start only after an equivalent
 verification job succeeds, and the container workflow may run only by manual
 dispatch or by a push to `main`. Every third-party workflow action is pinned to
 the reviewed latest release commit rather than a moving tag.
 ## Test method
 The dependency-free delivery contract reads both workflow files and checks the
 Testcontainers host override, event filters, verify-to-build dependencies, and
 the complete allowlist of immutable action SHAs. The remote failure log supplies
 the production-shaped network reproduction because it ran inside the real Gitea
 Docker runner.
 ## Hand-derived expected result
 The runner already resolves `host.docker.internal` to its Docker host. Therefore
 Testcontainers must use that host instead of the job-network gateway
 `172.17.0.1`. Pull requests and non-main branch pushes must never schedule the
 container workflow. Manual dispatches build but do not publish, while main pushes
 publish only after verification succeeds.
 ## RED
 **Command**
 ```text
 env PATH=/opt/homebrew/opt/node@24/bin:/usr/bin:/bin \
  node --test src/test/js/delivery-contract.test.mjs
 tea actions runs logs 174 --repo sechmachine/labtimesheet \
  --login sechmachine-git
 ```
 **Observed result**
 ```text
 Delivery contract: 4 tests, 1 passed, 3 failed. The workflows lacked the
 Testcontainers host override, container event/dependency gates, and current
 action pins.
 Gitea run 174 found Docker at unix:///var/run/docker.sock but selected host
 172.17.0.1. Ryuk started, then repeated connections to 172.17.0.1:57499 were
 refused. Maven ended with 217 tests, 64 errors.
 ```
 ## GREEN
 **Command**
 ```text
 env PATH=/opt/homebrew/opt/node@24/bin:/usr/bin:/bin \
  node --test src/test/js/delivery-contract.test.mjs
 ```
 **Observed result**
 ```text
 Delivery contract: 4 tests, 4 passed.
 ```
 ## Affected suite
 **Command and result**
 ```text
 env PATH=/opt/homebrew/opt/node@24/bin:/usr/bin:/bin npm run test:ui
 Result: 5 tests passed.
 env JAVA_HOME=/opt/homebrew/opt/openjdk@25 \
  PATH=/opt/homebrew/opt/openjdk@25/bin:/opt/homebrew/bin:/usr/bin:/bin \
  DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock \
  ./mvnw -B test
 Result: 205 tests passed across 44 suites; 0 failures, errors, or skips.
 npm ci && npm run build
 Result: Tailwind and Lucide assets built successfully; tracked assets remained unchanged.
 ./mvnw -B -DskipTests -Ddoclint=all javadoc:javadoc
 Result: BUILD SUCCESS with 83 existing missing-comment warnings and no production Java change.
 Ruby YAML parsing and git diff --check
 Result: both workflow files parsed and the diff check passed.
 Gitea Actions run 177 on `work/fix/platform/ci-testcontainers-actions`
 Result: Verify completed successfully in 8 minutes on the real Docker-mode runner.
 The non-main branch push scheduled `verify.yml` only; `container.yml` did not run.
 ```
 ## External-test boundaries
 The local contract cannot prove action-runner compatibility, registry credentials,
 or availability of the optional ARM runner. Those are checked by the actual Gitea
 branch verification and main container runs. Release freshness was checked against
 the official upstream release APIs on 2026-08-15; the immutable pins remain stable,
 but a later release requires an intentional reviewed update.
@@ -0,0 +1,63 @@
 # Test Evidence: Gitea container registry authentication
 - **Test type:** Integration
 - **Requirement IDs:** `OPS-012`, `OPS-016`, `OPS-017`
 - **Scenario IDs:** `AC-OPS-004`
 - **Test class/method:** `src/test/js/delivery-contract.test.mjs` — `container workflow runs only manually or on main and verifies before either image build`
 - **Implementation commit:** `4dd9f96a231316ce2c14755157a380a2123c2f0b`
 ## Protected behavior
 A push to `main` publishes `git.sechmachine.io.vn/sechmachine/labtimesheet` by authenticating the triggering Gitea account with the repository `REGISTRY_TOKEN`. Publication does not depend on separately configured image-name or username settings.
 ## Test method
 The dependency-free Node contract reads the committed workflow and checks its fixed registry/image coordinates, actor-based username, token secret, and absence of the obsolete `CONTAINER_IMAGE` and `REGISTRY_USERNAME` settings. Ruby's YAML parser separately checks workflow syntax.
 ## Hand-derived expected result
 The repository and package location are stable project facts. Therefore the workflow needs one credential only: a token belonging to the triggering actor with package read/write permission. Manual dispatch still builds without publishing; only a `main` push logs in and publishes.
 ## RED
 **Command**
 ```text
 env PATH=/opt/homebrew/opt/node@24/bin:/usr/bin:/bin node --test src/test/js/delivery-contract.test.mjs
 ```
 **Observed result**
 ```text
 4 tests ran: 3 passed, 1 failed. The container contract could not find the fixed registry/image or actor-based login. Real Gitea Container run 179 independently failed before registry login with "Repository variable CONTAINER_IMAGE is required", so REGISTRY_TOKEN was never used.
 ```
 ## GREEN
 **Command**
 ```text
 env PATH=/opt/homebrew/opt/node@24/bin:/usr/bin:/bin node --test src/test/js/delivery-contract.test.mjs
 ruby -e 'require "yaml"; YAML.safe_load(File.read(".gitea/workflows/container.yml"), aliases: true); puts "container workflow YAML: OK"'
 ```
 **Observed result**
 ```text
 Delivery contract: 4 tests, 4 passed. Container workflow YAML: OK.
 ```
 ## Affected suite
 **Command and result**
 ```text
 git diff --check
 ! rg -n 'CONTAINER_IMAGE|REGISTRY_USERNAME' .gitea/workflows/container.yml DEPLOYMENT.md
 Both checks passed. Application tests were deliberately not repeated because the change is limited to workflow metadata, its contract test, and deployment guidance; the container workflow retains its mandatory verify job before building.
 ```
 ## External-test boundaries
 Local checks do not authenticate to the private registry. The first `main` push containing this change is the production-shaped check of `REGISTRY_TOKEN`, package permissions, and registry publication.
@@ -0,0 +1,107 @@
 # Test Evidence: Production delivery baseline
 - **Test type:** Integration
 - **Requirement IDs:** `OPS-005`–`OPS-013`, `OPS-017`, `TST-001`, `TST-005`, `TST-009`
 - **Scenario IDs:** `AC-OPS-002`, `AC-OPS-003`, `AC-OPS-004`
 - **Test class/method:** `com.lab.labtimesheet.feature.account.service.BootstrapIntegrationTest.rootGuidesFreshInstallToBootstrapWhileOtherRoutesRemainHidden`, `src/test/js/delivery-contract.test.mjs`
 - **Implementation commit:** `cea4378f5699de4919c283b12371941d6742ca4b`
 ## Protected behavior
 The production image runs as a non-root Java 25 process, exposes health probes, and accepts the same environment-backed datasource configuration with either the optional PostgreSQL 18.4 Compose sidecar or an external database. Gitea verifies every pull request and push, publishes immutable SHA plus `main` image tags only from `main`, and skips native ARM64 work unless the matching runner is explicitly available.
 ## Test method
 The existing PostgreSQL-backed bootstrap integration test requests the liveness and readiness endpoints before initialization. A dependency-free Node contract checks the deployment files for the required runtime, Compose, trigger, permission, publication, and optional-runner boundaries. Docker and Compose validation then exercise the real build and both database topologies.
 ## Hand-derived expected result
 An absent ARM runner must skip the ARM job without blocking AMD64 publication. Enabling the runner creates an ARM64 architecture tag and a combined manifest, while the canonical SHA and `main` tags remain valid AMD64 images when ARM is disabled. Compose must preserve PostgreSQL data in a named volume and must not require the bundled database when an external JDBC URL is supplied.
 ## RED
 **Command**
 ```text
 env PATH=/opt/homebrew/opt/node@24/bin:/usr/bin:/bin node --test src/test/js/delivery-contract.test.mjs
 env JAVA_HOME=/opt/homebrew/opt/openjdk@25 \
  PATH=/opt/homebrew/opt/openjdk@25/bin:/opt/homebrew/bin:/usr/bin:/bin \
  DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock \
  ./mvnw '-Dtest=BootstrapIntegrationTest#rootGuidesFreshInstallToBootstrapWhileOtherRoutesRemainHidden' test
 ```
 **Observed result**
 ```text
 The delivery contract ran 3 tests and failed all 3 because Dockerfile,
 .gitea/workflows/verify.yml, and .gitea/workflows/container.yml did not exist.
 The PostgreSQL-backed bootstrap test ran 1 test and failed because
 /actuator/health/liveness returned 404 instead of 200.
 ```
 ## GREEN
 **Command**
 ```text
 env PATH=/opt/homebrew/opt/node@24/bin:/usr/bin:/bin node --test src/test/js/delivery-contract.test.mjs
 env JAVA_HOME=/opt/homebrew/opt/openjdk@25 \
  PATH=/opt/homebrew/opt/openjdk@25/bin:/opt/homebrew/bin:/usr/bin:/bin \
  DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock \
  ./mvnw '-Dtest=BootstrapIntegrationTest#rootGuidesFreshInstallToBootstrapWhileOtherRoutesRemainHidden' test
 ```
 **Observed result**
 ```text
 Delivery contract: 3 tests, 3 passed.
 Bootstrap health regression: 1 test, 1 passed against PostgreSQL 18.4.
 ```
 ## Affected suite
 **Command and result**
 ```text
 npm ci
 npm run test:ui
 npm run build
 git diff --exit-code -- src/main/resources/static/assets/app.css src/main/resources/static/assets/icons.svg
 env JAVA_HOME=/opt/homebrew/opt/openjdk@25 \
  PATH=/opt/homebrew/opt/openjdk@25/bin:/opt/homebrew/bin:/usr/bin:/bin \
  DOCKER_HOST=unix:///Users/sechmachine/.orbstack/run/docker.sock \
  ./mvnw test
 env JAVA_HOME=/opt/homebrew/opt/openjdk@25 \
  PATH=/opt/homebrew/opt/openjdk@25/bin:/opt/homebrew/bin:/usr/bin:/bin \
  ./mvnw -DskipTests -Ddoclint=all javadoc:javadoc
 docker build --check .
 docker build --platform linux/amd64 --build-arg VCS_REF=validation -t labtimesheet:ci-amd64 .
 docker build --platform linux/arm64 --build-arg VCS_REF=validation -t labtimesheet:ci-arm64 .
 docker compose --env-file .env.compose.example config
 docker compose --env-file .env.compose.example --profile bundled-db config
 Frontend tests: 4 passed; generated assets remained byte-clean.
 Maven: 217 tests across 49 suites, 0 failures, 0 errors, 0 skipped.
 Javadoc: BUILD SUCCESS; 83 pre-existing repository-wide warnings.
 Dockerfile check: passed without warnings. Both Linux architecture images built
 and reported the requested platform, UID/GID 10001, and readiness HEALTHCHECK.
 Both Compose configurations parsed successfully.
 Real smoke tests used the AMD64 image with disposable resources. Bundled mode
 started PostgreSQL 18.4 with the named volume and returned UP from liveness and
 readiness on 127.0.0.1:28080. External mode used a separately started
 PostgreSQL 18.4 service and returned UP from readiness on 127.0.0.1:28081.
 All disposable containers, networks, and the bundled test volume were removed.
 git diff --check: passed.
 ```
 ## External-test boundaries
 Local validation cannot prove that the private Gitea registry credentials are configured or that an `ubuntu-latest-arm` runner is online. Repository variable `ARM64_RUNNER_AVAILABLE` is the scheduler-safe availability signal because an unavailable runner label cannot be discovered from inside a job that has not yet been scheduled.
@@ -12,8 +12,9 @@ import org.springframework.security.web.access.intercept.AuthorizationFilter;
 import org.springframework.security.web.header.writers.ReferrerPolicyHeaderWriter.ReferrerPolicy;
 /**
- * Defines form authentication, role-based Admin routes, CSRF protection, and response security headers.
+ * Defines form authentication, role-based Admin routes, public health probes, CSRF protection, and response
- * Bootstrap access is further constrained by {@link BootstrapAccessFilter} until initialization completes.
+ * security headers. Bootstrap access is further constrained by {@link BootstrapAccessFilter} until initialization
 * completes.
 */
@Configuration(proxyBeanMethods = false)
 class SecurityConfiguration {
@@ -34,7 +35,7 @@ class SecurityConfiguration {
                .authorizeHttpRequests(authorize -> authorize
                        .requestMatchers(
                                "/bootstrap/**", "/activate/**", "/login", "/error", "/assets/**",
-                                "/actuator/health")
+                                "/actuator/health", "/actuator/health/**")
                        .permitAll()
                        .requestMatchers("/admin/**").hasRole("ADMIN")
                        .anyRequest().authenticated())
@@ -44,7 +44,8 @@ public class BootstrapAccessFilter extends OncePerRequestFilter {
    private static boolean allowedBeforeBootstrap(String path) {
        return path.equals("/bootstrap") || path.startsWith("/bootstrap/")
-                || path.equals("/actuator/health") || path.startsWith("/assets/")
+                || path.equals("/actuator/health") || path.startsWith("/actuator/health/")
                || path.startsWith("/assets/")
                || path.equals("/error");
    }
 }
@@ -0,0 +1,53 @@
 # Production profile. Supply every LAB_* value from the deployment environment.
 spring:
  datasource:
    url: "${LAB_DB_URL}"
    username: "${LAB_DB_USERNAME}"
    password: "${LAB_DB_PASSWORD}"
  flyway:
    enabled: true
    locations: classpath:db/migration
  jpa:
    hibernate:
      ddl-auto: validate
    open-in-view: false
  docker:
    compose:
      enabled: false
  lifecycle:
    timeout-per-shutdown-phase: 30s
 server:
  port: 8080
  shutdown: graceful
  forward-headers-strategy: "${LAB_FORWARD_HEADERS_STRATEGY}"
  servlet:
    session:
      cookie:
        http-only: true
        secure: true
        same-site: strict
  error:
    include-message: never
    include-stacktrace: never
 management:
  endpoints:
    web:
      exposure:
        include: "health,info"
  endpoint:
    health:
      show-details: never
      probes:
        enabled: true
      group:
        liveness:
          include: "livenessState"
        readiness:
          include: "readinessState,db"
 lab:
  public-origin: "${LAB_PUBLIC_ORIGIN}"
  security:
    master-key: "${LAB_SECURITY_MASTER_KEY}"
@@ -10,3 +10,9 @@ spring:
    hibernate:
      ddl-auto: validate
    open-in-view: false
 management:
  endpoint:
    health:
      probes:
        enabled: true
@@ -61,6 +61,8 @@ class BootstrapIntegrationTest {
    void rootGuidesFreshInstallToBootstrapWhileOtherRoutesRemainHidden() throws Exception {
        mockMvc.perform(get("/bootstrap")).andExpect(status().isOk());
        mockMvc.perform(get("/actuator/health")).andExpect(status().isOk());
        mockMvc.perform(get("/actuator/health/liveness")).andExpect(status().isOk());
        mockMvc.perform(get("/actuator/health/readiness")).andExpect(status().isOk());
        mockMvc.perform(get("/"))
                .andExpect(status().is3xxRedirection())
                .andExpect(redirectedUrl("/bootstrap"));
@@ -0,0 +1,88 @@
 import assert from "node:assert/strict";
 import { readFileSync } from "node:fs";
 import { dirname, resolve } from "node:path";
 import { fileURLToPath } from "node:url";
 import test from "node:test";
 const root = resolve(dirname(fileURLToPath(import.meta.url)), "../../..");
 const read = (path) => readFileSync(resolve(root, path), "utf8");
 const expectedActionPins = new Map([
  ["actions/checkout", "3d3c42e5aac5ba805825da76410c181273ba90b1"],
  ["actions/setup-java", "b6effb05e454b25005698d916606bdc6ffcbf961"],
  ["actions/setup-node", "820762786026740c76f36085b0efc47a31fe5020"],
  ["docker/setup-buildx-action", "bb05f3f5519dd87d3ba754cc423b652a5edd6d2c"],
  ["docker/login-action", "dbcb813823bdd20940b903addbd779551569679f"],
  ["docker/build-push-action", "53b7df96c91f9c12dcc8a07bcb9ccacbed38856a"],
 ]);
 test("production image and Compose keep one image usable with bundled or external PostgreSQL", () => {
  const dockerfile = read("Dockerfile");
  const compose = read("compose.yaml");
  const environment = read(".env.compose.example");
  const production = read("src/main/resources/application-prod.yaml");
  assert.match(dockerfile, /FROM node:24-alpine@sha256:/);
  assert.match(dockerfile, /FROM eclipse-temurin:25-jre-alpine@sha256:/);
  assert.match(dockerfile, /USER 10001:10001/);
  assert.match(dockerfile, /HEALTHCHECK .*health\/readiness/);
  assert.match(compose, /profiles: \["bundled-db"\]/);
  assert.match(compose, /condition: service_healthy/);
  assert.match(compose, /required: false/);
  assert.match(compose, /postgres_data:\s*$/m);
  assert.match(environment, /^LAB_DB_URL=/m);
  assert.match(environment, /^LAB_IMAGE=/m);
  assert.match(production, /same-site: strict/);
  assert.match(production, /include: "readinessState,db"/);
 });
 test("verification workflow checks every pull request and pushed branch without write permission", () => {
  const workflow = read(".gitea/workflows/verify.yml");
  assert.match(workflow, /pull_request:/);
  assert.match(workflow, /push:/);
  assert.match(workflow, /contents: read/);
  assert.match(workflow, /npm ci/);
  assert.match(workflow, /npm run test:ui/);
  assert.match(workflow, /npm run build/);
  assert.match(workflow, /\.\/mvnw -B test/);
  assert.match(workflow, /TESTCONTAINERS_HOST_OVERRIDE: host\.docker\.internal/);
  assert.doesNotMatch(workflow, /permissions:\s*write-all/);
 });
 test("container workflow runs only manually or on main and verifies before either image build", () => {
  const workflow = read(".gitea/workflows/container.yml");
  assert.match(workflow, /'on':\n  workflow_dispatch:\n  push:\n    branches:\n      - main/);
  assert.doesNotMatch(workflow, /^  pull_request:/m);
  assert.match(workflow, /jobs:\n  verify:/);
  assert.match(workflow, /amd64:\n    needs: verify/);
  assert.match(workflow, /arm64:[\s\S]*?needs: verify/);
  assert.match(workflow, /TESTCONTAINERS_HOST_OVERRIDE: host\.docker\.internal/);
  assert.match(workflow, /runs-on: ubuntu-latest-arm/);
  assert.match(workflow, /vars\.ARM64_RUNNER_AVAILABLE == 'true'/);
  assert.match(workflow, /gitea\.ref == 'refs\/heads\/main'/);
  assert.match(workflow, /sha-\$\{GITEA_SHA\}-amd64/);
  assert.match(workflow, /sha-\$\{GITEA_SHA\}-arm64/);
  assert.match(workflow, /imagetools create/);
  assert.match(workflow, /REGISTRY: git\.sechmachine\.io\.vn/);
  assert.match(workflow, /IMAGE_NAME: sechmachine\/labtimesheet/);
  assert.match(workflow, /username: \$\{\{ gitea\.actor \}\}/);
  assert.match(workflow, /password: \$\{\{ secrets\.REGISTRY_TOKEN \}\}/);
  assert.doesNotMatch(workflow, /CONTAINER_IMAGE|REGISTRY_USERNAME/);
  assert.doesNotMatch(workflow, /ssh|DEPLOY_HOST|DEPLOY_KEY/i);
 });
 test("workflows pin every action to the latest reviewed immutable release", () => {
  const workflows = [
    read(".gitea/workflows/verify.yml"),
    read(".gitea/workflows/container.yml"),
  ].join("\n");
  const uses = [...workflows.matchAll(/uses:\s+([^@\s]+)@([0-9a-f]{40})/g)];
  assert.ok(uses.length > 0);
  for (const [, action, pin] of uses) {
    assert.equal(pin, expectedActionPins.get(action), `unexpected pin for ${action}`);
  }
  assert.deepEqual(new Set(uses.map(([, action]) => action)), new Set(expectedActionPins.keys()));
  assert.doesNotMatch(workflows, /uses:\s+[^\s]+@v\d/);
 });
Author	SHA1	Message	Date
sechmachine	58a087b118	docs: add assisted exit transfer and history design documents Verify / verify (push) Successful in 2m57s Details Container / verify (push) Successful in 3m0s Details Container / arm64 (push) Skipped Details Container / amd64 (push) Successful in 1m52s Details Container / manifest (push) Skipped Details	2026-08-20 17:22:28 +07:00
sechmachine	8878326839	docs: add comprehensive technology stack reference Verify / verify (push) Successful in 4m5s Details Container / verify (push) Successful in 4m14s Details Container / arm64 (push) Skipped Details Container / amd64 (push) Successful in 1m37s Details Container / manifest (push) Skipped Details	2026-08-16 00:33:55 +07:00
sechmachine	200a17e5bd	docs(test): pin registry workflow evidence Container / verify (push) Canceled after 4m34s Details Container / amd64 (push) Canceled after 0s Details Container / arm64 (push) Canceled after 0s Details Container / manifest (push) Canceled after 0s Details Verify / verify (push) Successful in 8m31s Details	2026-08-16 00:28:46 +07:00
sechmachine	4dd9f96a23	fix(ci): use Gitea actor for registry publishing	2026-08-16 00:28:15 +07:00
sechmachine	d044277194	docs(test): record Gitea runner verification Container / amd64 (push) Failing after 6m24s Details Container / manifest (push) Skipped Details Container / verify (push) Successful in 3m12s Details Container / arm64 (push) Skipped Details Verify / verify (push) Successful in 8m59s Details	2026-08-15 23:55:52 +07:00
sechmachine	d13443e338	fix(ci): gate images behind verified Testcontainers Verify / verify (push) Successful in 8m52s Details	2026-08-15 23:21:23 +07:00
sechmachine	7a6139017f	docs(test): record production delivery evidence Container / amd64 (push) Failing after 19m25s Details Container / arm64 (push) Skipped Details Container / manifest (push) Skipped Details Verify / verify (push) Failing after 12m3s Details	2026-08-15 22:46:19 +07:00
sechmachine	cea4378f56	feat(platform): add production CI and containers	2026-08-15 22:45:35 +07:00