Update decision-making phase and enhance localization for presence tracking

- Marked tasks as complete in the decision-making phase documentation, indicating readiness for implementation.
- Updated the README to reflect the completion status of the decision-making phase.
- Enhanced localization strings to include new presence tracking features, improving user experience.
- Revised the game screen logic to display real-time presence status, including walking states for individuals.
- Added tests to validate the new localization strings and presence functionalities, ensuring robust performance.

.claude/skills/phase-review/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: phase-review
+description: Ревью срезов и фаз проекта h-school по их же критериям приёмки — с дописыванием недостающих тестов, исправлением найденного и журналом проверенного в docs/phases/reviewed.md. Обязательно используй этот скилл, когда просят «сделай ревью», «проведи ревью», «проверь срез», «проверь непроверенные срезы», «что ещё не проверено», «review the slice» — и вообще при любой просьбе проверить, действительно ли сделанная фаза сделана. Не для ревью одного диффа или пул-реквеста: там нужен /code-review.
+---
+
+# Ревью срезов
+
+Фазы в `docs/phases/` помечаются ✅, когда их **написали**. Это заявка автора, а не
+доказательство. Скилл превращает заявку в проверенный факт: берёт срез, сверяет каждое его
+обещание с кодом и тестами, дописывает недостающее, чинит найденное и записывает результат,
+чтобы одну и ту же работу не делать дважды.
+
+Главное, что делает ревью здесь дешёвым: **критерии приёмки уже написаны**. У каждой фазы есть
+«Задачи», «Тесты, без которых фаза не закрыта» и «Критерий готовности», а у проекта — список
+инвариантов в `AGENTS.md`. Ничего не надо выдумывать, надо проверить.
+
+## Журнал
+
+`docs/phases/reviewed.md` — единственный источник правды о том, что уже проверено. Если файла
+нет, создай его с заголовком и одной строкой о том, что это такое.
+
+Раздел на срез:
+
+```markdown
+## Срез 4. Расписание
+
+- **Фазы:** 14–17
+- **Проверен на:** `3c54f98`, 2026-08-19
+- **Пути:** `src/HSchool.Schedule`, `src/HSchool.Simulation/SchoolTimetables.cs`,
+  `src/HSchool.Server/Api/TimetableEndpoints.cs`, `tests/HSchool.Schedule.Tests`
+- **Итог:** дописано 3 теста, исправлено 2 расхождения с дизайном, одно замечание оставлено
+  открытым (см. ниже)
+```
+
+Коммит в строке «Проверен на» — не украшение. Он делает журнал самопроверяющимся: срез,
+проверенный на `3c54f98`, перестаёт быть проверенным, как только его пути тронули дальше. Поэтому
+«Пути» тоже обязательны — без них дрейф не поймать.
+
+## Как выбрать, что проверять
+
+1. Прочитай `docs/phases/README.md` — там срезы, их фазы и статусы.
+2. Прочитай журнал.
+3. Срез попадает в очередь, если:
+   - его нет в журнале; **или**
+   - `git log <коммит-из-журнала>..HEAD -- <пути среза>` непустой — код менялся после проверки;
+     это перепроверка, и в отчёте её надо называть именно так;
+   - в журнале записано «проверен частично».
+4. Порядок — **от раннего к позднему**. Верхние срезы стоят на нижних: искать причину странного
+   расписания, не проверив генерацию людей, значит искать не там.
+
+Срезы в работе (есть ⬜ или 🔄, код уже пишется) проверять можно и нужно, но в журнале это
+отмечается как «в работе на момент проверки» — иначе следующий проход решит, что там всё
+закрыто.
+
+**Один срез за проход.** Проверил → починил → записал в журнал → доложил → взялся за следующий.
+Если проходов будет несколько, пользователь увидит промежуточные результаты и сможет вмешаться,
+а не получит через час одну кучу правок в семи проектах.
+
+## Что именно проверять
+
+Идти сверху вниз, по каждому пункту фазы отдельно:
+
+**1. Обещания фазы.** Для каждой задачи и каждого пункта «Тесты, без которых фаза не закрыта»
+найди фактическое подтверждение: строчку кода, которая это делает, и тест, который это
+проверяет. Галочка `[x]` подтверждением не является. Чаще всего расхождение выглядит так: код
+написан, а теста из списка нет — либо тест есть, но проверяет соседнее.
+
+**2. Инварианты `AGENTS.md`,** относящиеся к затронутым проектам. Особенно те, что нельзя
+нарушить незаметно: протокол в трёх местах сразу, отсутствие HTTP и ASP.NET в `Simulation` и в
+чистых библиотеках, фиксированный шаг вместо `DateTime.Now`, одна школа — один поток,
+детерминированность от сида.
+
+**3. «Things that will bite you».** Этот раздел `AGENTS.md` — список уже случившихся регрессий.
+Проверить, что ни одна не вернулась, дешевле, чем поймать её второй раз.
+
+**4. Дизайн-док среза** (`docs/design/*.md`, ссылка есть в индексе фаз). Расхождение кода с
+принятым решением — находка, даже если тесты зелёные. Но сначала спроси себя, не устарел ли док:
+бывает, что решение сознательно поменяли, и тогда чинить надо документ.
+
+## Как проверять
+
+**Измеряй, а не рассуждай.** Когда вопрос звучит как «а хорошо ли раскладываются часы» или
+«а сколько получается неполных семей» — не рассуждай о коде, напиши временный тест, который
+печатает реальные числа, посмотри на них и удали его. Час размышлений о том, как поведёт себя
+алгоритм, стоит дороже и ошибается чаще, чем один прогон, который печатает распределение.
+
+**Проверяй подозрение до того, как о нём докладывать.** Половина находок «на глаз» рассыпается
+при первом же взгляде на соседний файл: параметр, который считался забытым, передаётся из
+вызывающего кода; поле, которого якобы нет в размере кадра, там есть. Проверенное подозрение —
+находка, непроверенное — шум, который пользователю придётся разбирать за тебя.
+
+## Что чинить
+
+- **Недостающие тесты дописывай** в проект, который назначен политикой из `AGENTS.md`
+  («Testing policy»). Тест генерации людей не место в тестах хоста.
+- **Чини причину, а не симптом.** Падающий тест не ослабляют и не удаляют ради зелёного прогона.
+  Если тест действительно неправ — так и напиши в отчёте, с обоснованием, и меняй его осознанно.
+- **Держись границ среза.** Найденное за его пределами — в отчёт строкой «замечено рядом», а не
+  в диф. Ревью, которое походя переписало соседний проект, невозможно посмотреть глазами.
+- **Молча не меняй** версию протокола, форму сейва и публичное поведение API. Это отдельное
+  решение пользователя, даже когда оно очевидно правильное.
+
+## Окружение
+
+```bash
+dotnet test
+```
+
+```bash
+npm --prefix src/HSchool.Client test
+```
+
+Чего ждать и что делать:
+
+- **`MSB3021` / `MSB3027`, «блокирует этот файл»** — у пользователя запущено приложение, оно
+  держит DLL. **Процесс не убивать.** Проверь то, что можно проверить без сборки .NET
+  (клиентские тесты, чтение кода, дизайн-доки), а в отчёте скажи прямо: .NET-часть не
+  прогонялась, потому что запущено приложение. В журнале такой срез — «проверен частично».
+- **Концы строк.** В репозитории есть файлы и с CRLF, и с LF. Правка не должна переворачивать
+  файл целиком: сверься с `git diff --stat` — внезапные «изменено 400 строк» в файле, где ты
+  правил три, это оно.
+- **Dev-сервер не запускать.** Если нужно посмотреть на UI, пользуйся уже запущенным
+  приложением пользователя; свой не поднимай и чужой не останавливай.
+
+## Отчёт
+
+Коротко и по делу, в конце каждого среза:
+
+- что проверено и чем это подтверждено;
+- что дописано (тесты — списком, по одной строке);
+- что исправлено и почему это была ошибка;
+- что осталось под вопросом — с формулировкой, по которой можно принять решение;
+- какой срез следующий в очереди.
+
+Пустой отчёт — тоже результат: «срез 2 проверен, все восемь тестов из фазы 6 на месте,
+расхождений с дизайном нет» стоит написать явно. Это ровно та информация, ради которой
+затевался журнал.