Docs: 7ecb337 is live; record the Gitea 504 from the server and the bundle deploy
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This commit is contained in:
14
CLAUDE.md
14
CLAUDE.md
@@ -298,12 +298,12 @@ grades 8–12 does; the 39 that fall short are all in grades 3/6/7.
|
||||
|
||||
Finishing the quiz finishes the island: `POST /api/nodes/{id}/quiz/complete` marks the node
|
||||
completed whatever the score (the owner's call on 2026-09-24: keep it simple) and returns
|
||||
`nextNodeId`. Since 2026-10-07 it refuses (in code; deployed only after the next release) a node
|
||||
`nextNodeId`. Since 2026-10-07 13:42 (live, `7ecb337`) it refuses a node
|
||||
that is locked on the map (403 `node_locked`, same rule as `/api/home`, `content.views.node_is_unlocked`),
|
||||
and a user who has not answered every quiz question (409 `answers_missing`;
|
||||
the required count is `max(client totalQuestions, min(4, questions in node))`, so the client cannot
|
||||
understate it). A node or lesson with no questions has nothing to answer: it passes when unlocked (no stars, no XP) so it does not block the chain, and is still refused when locked. `POST /api/lessons/{id}/complete` has the same lock and answer rules. Before that,
|
||||
only a user with zero hearts and no answers was refused; anyone else finished any island, locked or not. Before it existed, a node only completed when every one of its 8–13 lessons
|
||||
only a user with zero hearts and no answers was refused; anyone else finished any island, locked or not. Verified by 860 local tests and by outside probes (health, 401s, throttle); **not** verified by a real login on the server, so do one manual quiz after the next deploy. Before it existed, a node only completed when every one of its 8–13 lessons
|
||||
was completed one by one, so a student playing node quizzes was stuck after the first
|
||||
island of every unit. Details in `docs/architecture.md`.
|
||||
|
||||
@@ -827,8 +827,14 @@ migrationها اعمال شدند، سهیار و `nextLessonId` از بیر
|
||||
دستنخورده است و با `{{ block.super }}` گسترش داده شده.
|
||||
|
||||
**بکاپ:** `deploy.sh` پیش از `migrate` خودش بکاپ میگیرد (`db-before-deploy-*`، ۲ تای آخر،
|
||||
بیبکاپ migrate نمیشود)؛ فقط روی لپتاپ آزموده شد و روی سرور هنوز اجرا نشده. بیرون از ماشین بکاپی
|
||||
نیست. `sqlite3` روی سرور نصب نیست — برای بکاپِ دستی با `venv/bin/python` و
|
||||
بیبکاپ migrate نمیشود)؛ روی سرور هم اجرا شد (۲۰۲۶-۱۰-۰۷، `integrity_check: ok`). بیرون از ماشین بکاپی
|
||||
نیست.
|
||||
|
||||
**⚠️ دیپلو از ۲۰۲۶-۱۰-۰۷ بهخاطر Gitea:** از روی خودِ سرور `https://gitea.tadrisino2.ir` (حلشده به IPهای
|
||||
ArvanCloud) ۵۰۴ میدهد، پس `deploy.sh` در `git fetch` میایستد. آن روز کد با `git bundle` (از لپتاپ،
|
||||
`scp` به `.deploy-backups/`، `git fetch <bundle> main:refs/remotes/origin/main`، هشِ کامیت مقایسه شد،
|
||||
`git reset --hard origin/main`، `SKIP_PULL=1 ./deploy.sh`) رسید. علتِ ۵۰۴ پیدا نشد (مسیرِ آروان↔سرور؛ از لپتاپ ۲۰۰)؛
|
||||
مرحلهی «بررسیِ سلامت»ِ `deploy.sh` هم از داخلِ سرور همیشه شکست میخورد (همان مسیر). سلامت را از بیرون بسنجید. `sqlite3` روی سرور نصب نیست — برای بکاپِ دستی با `venv/bin/python` و
|
||||
`sqlite3.Connection.backup()` بگیر، نه با `cp`.
|
||||
|
||||
بخشهای تاریخیِ زیر بهترتیبِ زمان نگه داشته شدهاند چون درسهایشان هنوز معتبر است؛
|
||||
|
||||
Reference in New Issue
Block a user