From fb2959e35cbf88b253521227ecdb9f18540c9482 Mon Sep 17 00:00:00 2001
From: Pieter de Villiers <pieter.devilliers@gmail.com>
Date: Thu, 13 Aug 2026 13:38:07 +0200
Subject: [PATCH 1/4] ci: add dependency review gate

---
 .github/workflows/dependency-review.yml | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 .github/workflows/dependency-review.yml

diff --git a/.github/workflows/dependency-review.yml b/.github/workflows/dependency-review.yml
new file mode 100644
index 0000000..18b59a8
--- /dev/null
+++ b/.github/workflows/dependency-review.yml
@@ -0,0 +1,25 @@
+name: Dependency review
+
+on:
+  pull_request:
+    branches:
+      - main
+
+permissions:
+  contents: read
+
+jobs:
+  dependency-review:
+    runs-on: ubuntu-24.04
+    timeout-minutes: 10
+    steps:
+      - name: Check out source
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          persist-credentials: false
+
+      - name: Review dependency changes
+        uses: actions/dependency-review-action@a1d282b36b6f3519aa1f3fc636f609c47dddb294 # v5.0.0
+        with:
+          fail-on-severity: low
+          fail-on-scopes: runtime, development, unknown

From 868009bb569ef47b6bde0900cb78b104d62d10e5 Mon Sep 17 00:00:00 2001
From: Pieter de Villiers <pieter.devilliers@gmail.com>
Date: Thu, 13 Aug 2026 13:44:01 +0200
Subject: [PATCH 2/4] fix: address CodeQL security findings

---
 tests/test_auth.py      | 25 +++++++++++++++++++++++++
 tests/test_security.py  | 39 +++++++++++++++++++++++++++++++++++++++
 timemanager/auth.py     | 22 ++++++++++++++++------
 timemanager/security.py | 21 +++++++++++++++++++++
 timemanager/tasks.py    | 15 ++++++++-------
 5 files changed, 109 insertions(+), 13 deletions(-)
 create mode 100644 tests/test_security.py

diff --git a/tests/test_auth.py b/tests/test_auth.py
index 25f42a1..2d90093 100644
--- a/tests/test_auth.py
+++ b/tests/test_auth.py
@@ -68,6 +68,31 @@ def test_registration_validates_fields_and_duplicate_email(client):
     assert b"An account with that email already exists." in response.data
 
 
+def test_registration_rejects_malformed_or_oversized_email_addresses(client):
+    for email in (
+        "missing-at.example.com",
+        "missing-domain@",
+        "missing-suffix@example",
+        "two@@example.com",
+        "space @example.com",
+        f"{'a' * 243}@example.com",
+    ):
+        token = csrf_token(client, "/register")
+        response = client.post(
+            "/register",
+            data={
+                "_csrf_token": token,
+                "display_name": "Alex",
+                "email": email,
+                "password": "a secure local password",
+                "confirm_password": "a secure local password",
+            },
+            follow_redirects=True,
+        )
+
+        assert b"Enter a valid email address." in response.data
+
+
 def test_login_and_logout(client):
     register(client, password="a secure local password")
     token = csrf_token(client, "/today")
diff --git a/tests/test_security.py b/tests/test_security.py
new file mode 100644
index 0000000..fb47acc
--- /dev/null
+++ b/tests/test_security.py
@@ -0,0 +1,39 @@
+from __future__ import annotations
+
+import pytest
+
+from timemanager.security import local_return_path, redirect_to_local_path
+
+
+@pytest.mark.parametrize(
+    "candidate",
+    (
+        None,
+        "",
+        "relative/path",
+        "https://example.net/collect",
+        "//example.net/collect",
+        "/\\example.net/collect",
+        "/safe\r\nLocation: https://example.net/collect",
+    ),
+)
+def test_local_redirect_helpers_reject_non_local_paths(app, candidate):
+    fallback = "/today"
+
+    assert local_return_path(candidate, fallback) == fallback
+    with app.test_request_context():
+        response = redirect_to_local_path(candidate, fallback)
+
+    assert response.status_code == 302
+    assert response.headers["Location"] == fallback
+
+
+def test_local_redirect_helpers_retain_paths_queries_and_fragments(app):
+    candidate = "/projects?page=2#active"
+
+    assert local_return_path(candidate, "/today") == candidate
+    with app.test_request_context():
+        response = redirect_to_local_path(candidate, "/today")
+
+    assert response.status_code == 302
+    assert response.headers["Location"] == candidate
diff --git a/timemanager/auth.py b/timemanager/auth.py
index b6ab0e8..5f93987 100644
--- a/timemanager/auth.py
+++ b/timemanager/auth.py
@@ -1,6 +1,5 @@
 from __future__ import annotations
 
-import re
 from functools import wraps
 from typing import Any, Callable, TypeVar, cast
 
@@ -20,10 +19,9 @@
 
 from .db import get_db, local_installation_id, new_public_id
 from .models import users
-from .security import local_return_path
+from .security import redirect_to_local_path
 
 blueprint = Blueprint("auth", __name__)
-EMAIL_PATTERN = re.compile(r"^[^@\s]+@[^@\s]+\.[^@\s]+$")
 View = TypeVar("View", bound=Callable[..., Any])
 
 
@@ -114,7 +112,7 @@ def _registration_error(
 ) -> str | None:
     if len(display_name) < 2 or len(display_name) > 40:
         return "Use a name between 2 and 40 characters."
-    if len(email) > 254 or not EMAIL_PATTERN.match(email):
+    if not _valid_email_address(email):
         return "Enter a valid email address."
     if len(password) < 10:
         return "Use at least 10 characters for your password."
@@ -123,6 +121,19 @@ def _registration_error(
     return None
 
 
+def _valid_email_address(value: str) -> bool:
+    has_whitespace = any(character.isspace() for character in value)
+    if not value or len(value) > 254 or has_whitespace:
+        return False
+
+    local_part, separator, domain = value.partition("@")
+    if not separator or not local_part or "@" in domain:
+        return False
+
+    domain_name, dot, suffix = domain.rpartition(".")
+    return bool(domain_name and dot and suffix)
+
+
 @blueprint.route("/login", methods=("GET", "POST"))
 def login():
     if g.user is not None:
@@ -144,11 +155,10 @@ def login():
         else:
             session.clear()
             session["user_id"] = user["id"]
-            destination = local_return_path(
+            return redirect_to_local_path(
                 request.args.get("next"),
                 url_for("tasks.today"),
             )
-            return redirect(destination)
 
     return render_template("auth/login.html", email=email)
 
diff --git a/timemanager/security.py b/timemanager/security.py
index 89c43f9..f503c6a 100644
--- a/timemanager/security.py
+++ b/timemanager/security.py
@@ -2,6 +2,8 @@
 
 from urllib.parse import urlsplit
 
+from flask import redirect
+
 
 def local_return_path(value: str | None, fallback: str) -> str:
     """Return only an origin-local absolute path suitable for redirects."""
@@ -14,3 +16,22 @@ def local_return_path(value: str | None, fallback: str) -> str:
     if parsed.scheme or parsed.netloc:
         return fallback
     return value
+
+
+def redirect_to_local_path(value: str | None, fallback: str):
+    """Redirect to an explicitly validated origin-local absolute path."""
+    if not value:
+        return redirect(fallback)
+
+    normalized = value.replace("\\", "/")
+    if normalized != value:
+        return redirect(fallback)
+    if not normalized.startswith("/") or normalized.startswith("//"):
+        return redirect(fallback)
+    if any(character in normalized for character in ("\r", "\n")):
+        return redirect(fallback)
+
+    parsed = urlsplit(normalized)
+    if parsed.scheme or parsed.netloc:
+        return redirect(fallback)
+    return redirect(normalized)
diff --git a/timemanager/tasks.py b/timemanager/tasks.py
index 2af596f..ff55702 100644
--- a/timemanager/tasks.py
+++ b/timemanager/tasks.py
@@ -26,7 +26,7 @@
     tasks as task_table,
 )
 from .planning import TODAY_OPTION_LIMIT
-from .security import local_return_path
+from .security import local_return_path, redirect_to_local_path
 
 blueprint = Blueprint("tasks", __name__)
 
@@ -1816,16 +1816,17 @@ def move_project_task(project_id: int, task_id: int):
 def set_project_state(project_id: int):
     project = _owned_project(project_id)
     _require_current_revision(project)
-    destination = _safe_return_path(
-        request.form.get("redirect_to"),
-        _project_detail_path(project_id, request.form.get("return_to")),
+    redirect_target = request.form.get("redirect_to")
+    redirect_fallback = _project_detail_path(
+        project_id,
+        request.form.get("return_to"),
     )
     state = request.form.get("state")
     if state not in ("active", "completed", "dropped"):
         abort(400)
     if state == project["state"]:
         flash("Project unchanged.", "success")
-        return redirect(destination)
+        return redirect_to_local_path(redirect_target, redirect_fallback)
     if state == "completed":
         remaining = get_db().execute(
             sa.select(sa.func.count())
@@ -1838,7 +1839,7 @@ def set_project_state(project_id: int):
         ).scalar_one()
         if remaining:
             flash("The project still has open tasks.", "error")
-            return redirect(destination)
+            return redirect_to_local_path(redirect_target, redirect_fallback)
         if request.form.get("confirm") != "1":
             abort(400)
     database = get_db()
@@ -1864,4 +1865,4 @@ def set_project_state(project_id: int):
         flash("Project restored.", "success")
     else:
         flash("Project updated.", "success")
-    return redirect(destination)
+    return redirect_to_local_path(redirect_target, redirect_fallback)

From d14b89729ac97e2f0183be9463d2b7dffbc496ed Mon Sep 17 00:00:00 2001
From: Pieter de Villiers <pieter.devilliers@gmail.com>
Date: Thu, 13 Aug 2026 13:47:06 +0200
Subject: [PATCH 3/4] docs: record repository security controls

---
 docs/publication-readiness.md | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/docs/publication-readiness.md b/docs/publication-readiness.md
index 212de2c..66d78d3 100644
--- a/docs/publication-readiness.md
+++ b/docs/publication-readiness.md
@@ -203,6 +203,28 @@ resolved, and branch deletion and non-fast-forward pushes are blocked. Private
 vulnerability reporting, secret scanning, and secret-scanning push protection
 were also enabled.
 
+The ruleset was subsequently hardened for the solo-maintainer workflow. It
+retains zero required approvals and no bypass actors, while strict `test` and
+`dependency-review` checks are bound to the GitHub Actions application. CodeQL
+merge protection blocks errors and security alerts at medium severity or
+higher. Repository Actions default to read-only permissions, cannot approve
+pull requests, require immutable full-SHA references, and allow only
+GitHub-owned actions plus `astral-sh/setup-uv`. Every external contributor's
+fork workflow requires approval before running, and merged branches are deleted
+automatically.
+
+CodeQL default setup runs weekly and on applicable pushes and pull requests for
+GitHub Actions, JavaScript/TypeScript, and Python. Initial run `31696247639`
+completed successfully on exact public `main` commit
+`17b6e8ed61526e893c6c72f2577fe23ea19542e4`, but correctly reported five open
+Python findings: four potentially untrusted redirects and one polynomial email
+validation regular expression. The pull-request fix validates origin-local
+redirects at the response boundary and replaces the regular expression with
+bounded linear validation. CodeQL analysis of exact fix commit
+`868009bb569ef47b6bde0900cb78b104d62d10e5` then reported zero results in all
+three configured language categories. These automated results are not an
+independent security review or penetration test.
+
 The first hosted run on `313ae7dd98e7241174b1dbce1134e0d09eaa7866` failed
 before creating a job because the workflow used a runner-only context in
 job-level environment configuration. Commit

From 295a11ef258856249ba763644d8a74494c5979d5 Mon Sep 17 00:00:00 2001
From: Pieter de Villiers <pieter.devilliers@gmail.com>
Date: Mon, 31 Aug 2026 15:02:42 +0200
Subject: [PATCH 4/4] Additional documentation

---
 docs/README.md                                |   9 +
 .../day-transition-and-closing-inspiration.md | 147 +++++++++
 docs/high-level-product-design.md             |   8 +-
 ...work-and-cultural-practices-inspiration.md | 289 ++++++++++++++++++
 4 files changed, 452 insertions(+), 1 deletion(-)
 create mode 100644 docs/day-transition-and-closing-inspiration.md
 create mode 100644 docs/japanese-work-and-cultural-practices-inspiration.md

diff --git a/docs/README.md b/docs/README.md
index 173b62a..ecb4aed 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -18,6 +18,15 @@ guidance, not medical advice or a substitute for ADHD assessment or treatment.
   records screenshot- and implementation-backed usability findings, prioritized
   safety and accessibility issues, proposed interaction requirements, validation
   scenarios, and a staged optimization plan.
+- [Day-transition and achievement-closing inspiration](day-transition-and-closing-inspiration.md)
+  preserves experiential input about small ritual boundaries, acknowledging
+  progress and effort, and carrying one concrete next action into the following
+  day without turning Close into a score, streak, or second task manager.
+- [Japanese work and cultural practices: product inspiration](japanese-work-and-cultural-practices-inspiration.md)
+  evaluates Kanban/pull, *genchi genbutsu*, pointing and calling, 5S,
+  Kaizen/Improvement Kata, jidoka/poka-yoke, and *ma* against Timemanager's
+  low-friction product and evidence boundaries, with first-party and academic
+  references.
 - [Task detail and complex-work requirements](task-detail-and-complex-work-requirements.md)
   defines the Phase 1 task-detail, component, lightweight-project, ordering,
   dependency, external-waiting, readiness, and Today-placement contracts.
diff --git a/docs/day-transition-and-closing-inspiration.md b/docs/day-transition-and-closing-inspiration.md
new file mode 100644
index 0000000..621a1f5
--- /dev/null
+++ b/docs/day-transition-and-closing-inspiration.md
@@ -0,0 +1,147 @@
+# Day-transition and achievement-closing inspiration
+
+Status: product inspiration; not implemented or participant-validated
+
+Recorded: 2026-08-31
+
+Evidence label: Experiential — user-provided lived-experience input
+
+## Purpose
+
+This note preserves additional input for the proposed Transition, Close,
+Review/Reset, focus-outcome, and history experiences. It does not change the
+canonical milestone order, establish an implementation decision, or provide
+evidence of clinical effectiveness.
+
+[Japanese work and cultural practices: product inspiration](japanese-work-and-cultural-practices-inspiration.md)
+adds referenced research on Kanban/pull, *genchi genbutsu*, pointing and
+calling, 5S, Kaizen/Improvement Kata, jidoka/poka-yoke, and *ma*. Their proposed
+Timemanager translations remain product hypotheses rather than validated ADHD
+interventions.
+
+## Lived-experience signal
+
+A forward-looking task system makes unfinished work and future challenges highly
+visible. Completed work, partial progress, recovery after difficulty, useful
+decisions, and other forms of effort can be much easier to forget. The resulting
+view may show the mountain ahead while obscuring the ground already crossed.
+
+An intentionally small closing reflection could help balance that view by
+preserving what happened and acknowledging that the day's effort is finished.
+
+> The plan shows what remains. The close preserves what happened.
+
+## Closing acknowledgement
+
+The Japanese expression **今日も一日お疲れ様** (*kyō mo ichinichi
+otsukaresama*) was supplied as inspiration for this boundary. Its approximate
+sense in this context is: *Good work today; you've worked hard today.*
+The useful product idea is not that every user should adopt this exact phrase.
+It is that the product may offer a user-chosen acknowledgement that today's
+effort has been seen and the day can end.
+
+A possible optional Close flow is:
+
+1. **What did you move forward today?** Select or write no more than three
+   acknowledgements.
+2. **What helped, even if it was not completed?** Optionally record progress,
+   effort, recovery, a decision, asking for help, deliberate rest, or making
+   tomorrow easier.
+3. **Tomorrow I start with:** Save one concrete, user-confirmed next action.
+4. Show the user's preferred short closing acknowledgement.
+
+Achievements must not be limited to completed tasks. Starting difficult work,
+making partial progress, recovering after losing focus, responding to an
+interruption, making a decision, reducing an unrealistic plan, or deliberately
+stopping can all be legitimate acknowledgements when the user chooses them.
+
+The initial product hypothesis is that this should take about 60 seconds and
+remain useful even when the only acknowledgement is "I kept going" or "I made
+tomorrow easier."
+
+## Day-boundary rituals
+
+The same principle may extend to transitions between parts of the day. Each
+boundary combines a cognitive handoff with one to three user-chosen physical or
+environmental cues.
+
+| Boundary | Cognitive handoff | Example user-chosen cues |
+| --- | --- | --- |
+| Start day | **Today:** what matters? **First:** how do I begin? | Open curtains, move briefly, make tea |
+| Lunch | Where is work safely parked? | Clear the desk, wash hands, eat elsewhere, take a short walk |
+| End work | What moved? Where exactly do I resume? | Save the next action, close applications, change the environment |
+| Before bed | What should be acknowledged, and what would make morning easier? | Prepare one item, choose a quiet activity, close the day |
+
+The examples are inspiration, not a prescribed routine. Ritual steps should be
+user-authored or explicitly selected, culturally adaptable, editable,
+reversible, and skippable.
+
+## Product constraints
+
+- Keep each transition deliberately small; do not create a checklist marathon.
+- Do not require journaling, inbox zero, a complete review, or an impressive
+  achievement.
+- Do not add scores, grades, streaks, productivity comparisons, routine debt,
+  or failure language.
+- Do not infer an achievement, effort level, emotional state, or meaning from
+  task data. The user decides what deserves acknowledgement.
+- Suggestions may use visible facts such as tasks the user completed today, but
+  nothing is recorded until the user confirms it.
+- Saving a next action must not silently complete, schedule, promote, reorder,
+  or roll over a task.
+- Low Capacity should reduce the experience to one optional acknowledgement or
+  one anchor action, with an immediate exit.
+- The phrase, language, and ritual framing must be optional and localizable.
+- A missed or deferred Close must not block tomorrow's plan or create a warning.
+
+## Relationship to existing concepts
+
+- **Today highlight** can provide the proposed morning **Today** intention.
+- A task's saved **next action** can provide **First** and **Tomorrow I start
+  with**, subject to explicit confirmation.
+- Existing completed-today tasks may be offered as acknowledgement candidates,
+  but they are not the only valid achievements.
+- **Remember** remains a separate three-item transient cue list. It must not be
+  repurposed as an achievement history or daily journal.
+- Existing reflection markers may eventually annotate a user-confirmed outcome,
+  but they must not replace the plain acknowledgement or make Close feel like a
+  questionnaire.
+
+If a future implementation persists daily closing records, they become private
+user-authored data. Before implementation, define account ownership, stable
+identity and revision semantics, correction and deletion, retention, account
+export/import, migration behavior, and recovery. Do not store this content only
+in browser state without a deliberate privacy and interruption-recovery
+decision.
+
+## Roadmap relationship
+
+This input may inform several existing milestones without changing their order:
+
+- **1.3 Review and consequence-aware Reset/recovery:** distinguish balanced
+  acknowledgement from backlog review and scoring.
+- **1.4 Fixed commitments and transition boundaries:** test optional ritual
+  cues at start, lunch, work close, and bedtime boundaries.
+- **1.6 Bounded focus-session record:** allow a user-confirmed progress and
+  next-action outcome when stopping or switching.
+- **1.7 Last Done and execution history:** reuse compatible privacy, correction,
+  reflection, and export contracts without conflating an achievement
+  acknowledgement with an activity execution.
+
+The outstanding validation interlock and existing milestone sequence remain
+authoritative. This note is discovery input for prototypes and requirements,
+not authority to implement persistent behavior.
+
+## Questions to validate
+
+- Does the Close feel like acknowledgement rather than another review burden?
+- Can a participant complete or skip it comfortably in about 60 seconds?
+- Do incomplete progress and recovery feel as legitimate as task completion?
+- Does the closing acknowledgement make stopping feel more deliberate without
+  creating dependency on the application?
+- Does a concrete next-start handoff reduce reconstruction effort the following
+  day without silently deciding the new Today plan?
+- Are one to three ritual cues helpful, or do they become another routine to
+  maintain?
+- Can users replace the supplied language and cultural framing with wording and
+  rituals that feel natural to them?
diff --git a/docs/high-level-product-design.md b/docs/high-level-product-design.md
index 8508758..aa30a9f 100644
--- a/docs/high-level-product-design.md
+++ b/docs/high-level-product-design.md
@@ -2,7 +2,7 @@
 
 Status: proposed product direction
 
-Updated: 2026-07-28
+Updated: 2026-08-31
 
 ## Implementation status
 
@@ -383,6 +383,12 @@ It asks:
 
 The close does not require journaling, complete time logs, or inbox zero.
 
+[Day-transition and achievement-closing inspiration](day-transition-and-closing-inspiration.md)
+records additional experiential input about balancing the visible work ahead
+with a brief acknowledgement of progress and effort, carrying one concrete next
+action forward, and using small user-chosen rituals to mark day boundaries. It
+is product-discovery input, not implemented or participant-validated behavior.
+
 ### 9. Learn: "Help plans become more realistic"
 
 A five-minute weekly review presents a small number of patterns:
diff --git a/docs/japanese-work-and-cultural-practices-inspiration.md b/docs/japanese-work-and-cultural-practices-inspiration.md
new file mode 100644
index 0000000..bcdb304
--- /dev/null
+++ b/docs/japanese-work-and-cultural-practices-inspiration.md
@@ -0,0 +1,289 @@
+# Japanese work and cultural practices: product inspiration
+
+Status: product research and inspiration; no new behavior implemented or
+participant-validated
+
+Research snapshot: 2026-08-31
+
+## Purpose and evidence boundary
+
+This note evaluates a small set of Japanese industrial practices and cultural
+ideas as possible inspiration for Timemanager. The goal is not to assemble
+Japanese-themed productivity features. It is to identify simple mechanisms that
+could reduce planning, starting, switching, and recovery friction without
+creating another system to maintain.
+
+The sources establish the original industrial practice, management framework,
+laboratory result, or cultural concept. They do not establish that the proposed
+Timemanager translation helps adults with ADHD. Under this repository's evidence
+model, the exact product translations remain **Plausible** unless explicitly
+identified as **Experiential**. None is evidence of treatment or clinical
+effectiveness.
+
+"Japanese work" is not one uniform method. This review distinguishes:
+
+- Toyota Production System mechanisms such as kanban, pull, Just-in-Time, and
+  jidoka;
+- wider workplace practices such as 5S and pointing and calling;
+- Mike Rother's later Improvement Kata framework, derived from his study of
+  Toyota rather than documented as Toyota's own named routine; and
+- *ma* as a broad cultural concept of interval or in-between space, not an
+  industrial productivity method.
+
+## Evidence ledger and recommendation
+
+| Candidate | Source establishes | Proposed Timemanager use | Evidence status | Recommendation |
+| --- | --- | --- | --- | --- |
+| Kanban, pull, and work-in-progress limits | Toyota uses kanban cards to support a pull system in which the next process requests what it needs [1] | Keep Later as the backlog, Today as a bounded buffer, and one task as the current work | Plausible translation; Today already implements part of it | Retain the mechanism; do not add a large board |
+| *Genchi genbutsu* | Toyota describes going to the source to find facts before deciding [3] | A ten-second **What is true now?** orientation using current time, commitments, capacity, and blockers | Plausible translation | Use as an internal design principle |
+| Pointing and calling | Japanese railway and industrial research found fewer errors in controlled choice and checking tasks [4][5] | Optional embodied confirmation for two or three consequential transition checks | Plausible translation from non-ADHD safety research | Prototype narrowly; never require voice recording |
+| 5S | JICA describes Sort, Set, Shine, Standardize, and Sustain as workplace-organization practices [6] | Remove one obstruction, return needed items, and stage the first item for the next context | Plausible translation | Test one micro-reset, not a five-part audit |
+| Kaizen and Improvement Kata | Toyota documents continuous improvement; Rother formalizes a current-condition, target-condition, experiment pattern [2][7] | Select one small, reversible weekly experiment based on observed friction | Plausible translation | Keep one experiment at a time |
+| Jidoka and poka-yoke | Toyota describes stopping when an abnormality appears; Shingo's mistake-proofing work designs around predictable human error [2][8][9] | Let the user stop an invalid plan, preserve work, and make the safe next choice obvious | Plausible translation; some safety behavior already exists | Treat as a system-wide safety principle |
+| *Ma* | Research describes *ma* as an interval or in-between space in Japanese arts and daily-life practices [10] | Preserve a short buffer that closes one context before presenting the next | Experiential/cultural inspiration | Use as a design metaphor, not an efficacy claim |
+
+## 1. Kanban: pull only when capacity exists
+
+Toyota's Just-in-Time explanation describes a pull system: the following
+process takes what it needs from the preceding process, and kanban cards help
+coordinate replenishment [1]. The transferable idea is not the familiar
+software board. It is that work enters the active system only when capacity is
+available.
+
+The smallest Timemanager interpretation is:
+
+- Later remains the backlog;
+- Today remains a deliberately bounded buffer;
+- no more than one task is treated as current work;
+- finishing or deliberately parking that task creates capacity to pull another;
+  and
+- overflow remains visible but is never promoted automatically.
+
+The accepted small-Today decision already implements one highlight, no more
+than three optional active actions, recoverable overflow, and no silent
+promotion. Kanban therefore reinforces the current direction; it does not
+justify replacing Today with a draggable multi-column board.
+
+Potential later experiment: when bounded focus sessions are implemented, test a
+single explicit **Working now** container with **Finish**, **Park safely**, and
+**Pull another** actions.
+
+## 2. *Genchi genbutsu*: plan from present facts
+
+Toyota describes *genchi genbutsu* as going to the source to find the facts
+needed for correct decisions [3]. Personal planning cannot literally copy a
+factory practice, but it can adopt a fact-first orientation:
+
+> **What is true right now?**
+
+A compact orientation could show only facts Timemanager can support accurately:
+
+- current time;
+- the next fixed commitment and transition boundary, once implemented;
+- the user's selected capacity mode, without inferring health or mood;
+- the selected task's saved next action and visible blocker; and
+- whether the earlier plan still fits the remaining time.
+
+This should not become another form to complete. Its purpose is to reduce the
+gap between an idealized plan and the current situation. It fits the proposed
+Orient and consequence-aware Reset experiences.
+
+## 3. Pointing and calling: an embodied critical check
+
+Pointing and calling combines looking at an object, pointing to it, and saying
+its identity or state. In Haga, Akatsuka, and Shiroto's controlled experiments,
+the combined procedure produced the lowest error rate of the tested conditions;
+in a second experiment, none of twelve participants using it made the critical
+red-signal response error, compared with five of twelve without it [4]. A later
+Railway Technical Research Institute report summarizes one mean error-rate
+comparison as 0.38% with pointing and calling versus 2.38% without it [5].
+
+These are laboratory and occupational-safety results, not evidence about ADHD
+planning or ordinary household routines. The likely value is limited to a
+small number of checks where prospective-memory failure has a meaningful
+consequence.
+
+Possible examples:
+
+- **Leaving:** keys present; required bag present; departure step confirmed.
+- **Closing work:** exact next-start file or object staged; unsaved work handled.
+- **Changing location:** the one essential item for the next context present.
+
+Timemanager could display the check while the user points or speaks. It should
+not listen, record audio, demand performance, or claim that tapping a checkbox
+is equivalent to the researched embodied procedure. Repetition for ordinary
+tasks would add friction and should be avoided.
+
+## 4. 5S: a bounded environmental reset
+
+JICA describes 5S as Sort, Set, Shine, Standardize, and Sustain, originating
+from the Japanese terms *seiri*, *seiton*, *seiso*, *seiketsu*, and *shitsuke*
+[6]. Its full workplace form involves ongoing organization and standards. A
+personal productivity product should not reproduce that governance overhead.
+
+The high-value reduction is:
+
+> **Remove one obstruction → return needed things → stage the first thing for
+> the next context.**
+
+At the end of work this might mean clearing one surface, closing the current
+materials, and opening or placing the exact first item for tomorrow. At lunch it
+might mean leaving the current task in a recoverable state and physically
+leaving the work surface.
+
+This should be one optional transition ritual, not a cleaning score, recurring
+audit, streak, household standard, or expanding checklist.
+
+## 5. Kaizen and Improvement Kata: one experiment
+
+Toyota describes daily incremental kaizen as part of the continuing Toyota
+Production System [2]. Mike Rother's Improvement Kata, developed from his study
+of Toyota, uses a repeatable pattern: understand the current condition, define a
+nearer target condition, and move toward it through experiments that expose new
+obstacles [7]. The distinction matters: **Improvement Kata** is Rother's named
+framework, not a claim that Toyota uses that exact label or card internally.
+
+Timemanager's proposed weekly learning loop already contains the smallest useful
+translation:
+
+1. What friction repeated?
+2. What is one small change worth trying?
+3. What happened when I tried it?
+4. Keep, change, or stop the experiment.
+
+Only one experiment should be active by default. It must be reversible and must
+not imply that every difficult day reveals something the user must optimize.
+Examples include staging a starting file before stopping work or using a
+smaller first focus interval for one week.
+
+## 6. Jidoka and poka-yoke: stop safely and design around slips
+
+Toyota describes jidoka as detecting an abnormality and stopping rather than
+allowing the problem to continue through the process [2]. Shigeo Shingo's
+poka-yoke work addresses mistake-proofing at the source [9]. The Shingo
+Institute emphasizes the non-blaming premise that mistakes are human and that a
+useful countermeasure must not burden or disrespect the person using it [8].
+
+Possible Timemanager implications are:
+
+- a prominent **The day changed** or **This plan no longer fits** action;
+- blocked work offers **Clarify**, **Park safely**, or **Ask**, rather than
+  repeatedly demanding **Start**;
+- interrupted edits remain recoverable;
+- destructive actions have confirmation and recovery paths;
+- invalid capacity or ownership states fail closed; and
+- transitions can stage the next required object or action so success depends
+  less on remembering later.
+
+These principles already align with recoverable Today overflow, preserved
+drafts, dropped-task recovery, explicit ownership, and the proposed Reset flow.
+They should guide implementation rather than appear as Japanese-branded user
+features.
+
+## 7. *Ma*: preserve the interval
+
+Tseng's qualitative research describes *ma* as a Japanese concept of gap,
+interval, or in-between space across arts and daily-life practices [10]. That
+work concerns contemporary dance and togetherness; it does not test personal
+productivity or transitions for adults with ADHD.
+
+The defensible use is therefore metaphorical:
+
+> A transition needs space; it is not merely the instant when one task replaces
+> another.
+
+A product experiment could insert a short neutral boundary between contexts:
+close the previous task, hold a brief unfilled interval, and then show the next
+commitment or chosen action. The app should not fill that interval with more
+content, advice, or notifications.
+
+## Ranked shortlist
+
+| Rank | Smallest high-value idea | Product role | Smallest exit gate before adoption |
+| --- | --- | --- | --- |
+| 1 | Pull work only when capacity exists | Preserve bounded Today; later test one **Working now** item | Users can finish or park current work and deliberately pull another without losing overflow |
+| 2 | Orient from current facts | **What is true now?** summary in Orient/Reset | Synthetic scenario proves facts stay distinct from suggestions and no mood/health state is inferred |
+| 3 | Stop safely when the plan is invalid | User-invoked Reset and recoverable state | Day-change scenarios preserve data and require confirmation for every mutation |
+| 4 | Reset and stage the environment | One optional transition cue | Participants can complete or skip it without routine debt or checklist growth |
+| 5 | Confirm only consequential transitions | Optional point-and-call prompt | Test demonstrates the prompt is understandable, rare, accessible, and usable without recording audio |
+| 6 | Run one reversible experiment | Weekly learning | One experiment can be started, reviewed, changed, or stopped without a score or streak |
+| 7 | Protect an interval between contexts | Transition presentation principle | Participants experience a clearer boundary without perceiving delay or added work |
+
+## What not to import
+
+- Do not build a large Kanban board merely because kanban is Japanese. Visual
+  columns and drag-and-drop can increase scanning and maintenance without adding
+  pull or capacity control.
+- Do not turn 5S into an audit of the user's home, discipline, or cleanliness.
+- Do not translate kaizen into permanent self-optimization or treat every bad
+  day as a process defect.
+- Do not make pointing and calling ceremonial, public, or mandatory.
+- Do not use *ma*, Zen, *ikigai*, or other broad cultural terms as unsupported
+  efficacy claims or decorative branding.
+- No separately sourced *hansei* feature is recommended from this review. A
+  deficit-first reflection would conflict with the experiential requirement to
+  preserve achievements and effort alongside unfinished work.
+
+## Relationship to current roadmap
+
+This research does not change the canonical execution order or implementation
+status.
+
+- The implemented small Today plan already provides a Kanban-like work-in-
+  progress boundary without claiming to be a complete Kanban system.
+- *Genchi genbutsu*, jidoka, and poka-yoke may inform milestone 1.3 Review and
+  consequence-aware Reset/recovery.
+- Pointing and calling, simplified 5S, and *ma* may inform milestone 1.4
+  transition-boundary prototypes.
+- A one-item pull state may be tested with milestone 1.6 bounded focus sessions.
+- The one-experiment Kaizen/Kata interpretation belongs in the existing weekly
+  learning proposal and must not bypass the Phase 1 validation interlock.
+
+Before implementation, each visible feature still needs a synthetic prototype,
+manual accessibility review, and participant evidence. Any persisted ritual,
+check, experiment, or transition history also needs account ownership,
+correction, deletion, retention, export/import, and migration decisions.
+
+## References
+
+1. Toyota Motor Corporation. [Toyota Virtual Plant Tour: Toyota Production
+   System](https://global.toyota/en/company/plant-tours/production-system/).
+   Official explanation of Just-in-Time, the pull system, and kanban cards.
+   Accessed 2026-08-31.
+2. Toyota Motor Corporation. [Toyota Production
+   System](https://global.toyota/en/company/vision-and-philosophy/production-system/).
+   Official explanation of Just-in-Time, jidoka, abnormality stops, and daily
+   incremental kaizen. Accessed 2026-08-31.
+3. Toyota Motor Corporation. [Toyota Global
+   Vision](https://global.toyota/pages/global_toyota/ir/presentation/20110309_presentation_en.pdf).
+   2011. See the Toyota Way description of kaizen and *genchi genbutsu*.
+4. Haga, Shigeru, Hajime Akatsuka, and Hiroaki Shiroto. [Laboratory experiments
+   for verifying the effectiveness of "finger-pointing and call" as a practical
+   tool of human error
+   prevention](https://doi.org/10.32222/jaiop.9.2_107). *Japanese Association of
+   Industrial/Organizational Psychology Journal* 9, no. 2 (1996): 107–114.
+5. Shigemori, Masayoshi, Ayanori Sato, and Takayuki Masuda. [Experience-based PC
+   Learning System for Human Error Prevention by Point-and-Call
+   Checks](https://doi.org/10.2219/rtriqr.53.231). *Quarterly Report of RTRI* 53,
+   no. 4 (2012): 231–234.
+6. Japan International Cooperation Agency. [JICA President Akihiko Tanaka Visits
+   South
+   Africa](https://www.jica.go.jp/english/about/president/archives_tanaka/130226_01.html).
+   2013. Notes define the five Japanese and English 5S terms. Accessed
+   2026-08-31.
+7. Rother, Mike. [Toyota Kata introduction and Improvement Kata
+   overview](https://www.lean.org/wp-content/uploads/2022/04/toyota_kata.pdf).
+   Lean Enterprise Institute presentation based on *Toyota Kata: Managing
+   People for Improvement, Adaptiveness and Superior Results* (McGraw-Hill,
+   2010).
+8. Hamilton, Bruce. [Mistake-Proofing
+   Mistakes](https://shingo.org/mistake-proofing-mistakes/). Shingo Institute,
+   2020. Discusses non-blaming, usable mistake-proofing and common failure
+   modes. Accessed 2026-08-31.
+9. Shingo, Shigeo. *Zero Quality Control: Source Inspection and the Poka-yoke
+   System*. Portland, Oregon: Productivity Press, 1986.
+10. Tseng, Chiahuei. [MA and Togetherness (Ittaikan) in the Narratives of
+    Dancers and Spectators: Sharing an Uncertain
+    Space](https://doi.org/10.1111/jpr.12330). *Japanese Psychological Research*
+    63, no. 4 (2021): 421–433.
+