Различия

Показаны различия между двумя версиями страницы.

--- ns:2026:09-18-2114_test_project5 [2026/09/18 21:14] – Создано по форме с lira:sga:members:2026:stutest:projects:newproject Антон Юдин
+++ ns:2026:09-18-2114_test_project5 [2026/09/21 18:45] (текущий) – удалено - внешнее изменение (Дата неизвестна) 127.0.0.1
@@ Строка 1: / Строка 1: @@
-====== test_project5 ======
------ struct table -----
-schema: project_meta
-cols: description, aim, tasks
-filter: %pageid% = $ID$
------
-<WRAP box>
-Explicit block, not automatic `bottomoutput`/`topoutput` — Struct's
-automatic banner has a confirmed duplicate-rendering bug on this
-release (full explanation: `spec-update-condensed/
--schema-reference.md`'s duplicate-banner section). **Run
-`struct-inpage-visibility-batch.sql` against `project_meta`** before or
-immediately after adding this block, and purge the render cache — until
-then this page briefly shows the data twice.
-</WRAP>
-===== Sessions logged against this project =====
------ struct table -----
-schema: log_entry
-cols: %pageid%, hit_a_wall, need_help
-filter: project_link.project = $ID$
------
-<WRAP box>
-`hit_a_wall`/`need_help` are real struct columns; `goal_today`/
-`what_i_tried`/`how_its_going` are **plain bureaucracy fields, not
-struct columns** and cannot appear in a `cols:` line — they'd render
-silently empty, no error. The doubled-percent page-id column above
-links each row through to the actual log entry for the free-form
-narrative. Promoting those fields to
-real struct columns for full narrative rollup is a schema-design
-decision, not a template fix.
-**`$ID$`, never `ns:2026:09-18-2114_test_project5`, in this filter line.** Confirmed via struct's
-own `InlineConfigParser.php`, which documents a page-id-equals-`$ID$`
-filter (doubled percent signs around the column name, same as above)
-as its own default — then verified live. `ns:2026:09-18-2114_test_project5` only substitutes
-inside a namespace template at page-creation time; used here (a
-bureaucracy-populated content template) it would save as the literal
-text `ns:2026:09-18-2114_test_project5` on every project page, silently breaking this aggregation
-forever with no error. Full mechanism and live-spike confirmation:
-build log §T3. Never quote the filter value either.
-</WRAP>
-===== "Log today's work" =====
-**Corrected this session — the mechanism this relied on no longer
-exists.** Logs stopped using `addnewpage`/`{{NEWPAGE}}` entirely this
-session (`03-templates/logs/README.md`'s new section): each level now
-has one persistent, reusable form page instead of a fresh page created
-per entry, so there's no longer a page-creation URL to build a button
-around here at all — and even before that change, the relative path
-below this line was itself miscounted (two `..:` segments, landing at
-`projects:logs:...` instead of the intended top-level `logs:...` —
-moot now, replaced rather than fixed in place).
-The corrected link goes to the student's own dashboard, where the one
-log-start link matching their actual level already lives
-(`06-buttons/student-dashboard.txt`):
-[[..:..:..:index|📋 Go to your dashboard to start today's log]]
-The student still picks this project manually from the struct
-Page-type picker on the log form once there — that choice was already
-decided as deliberately two-step, reasoning unchanged from before this
-correction (see below).
-**Decided: two-step, not one-click.** A genuine one-click mechanism
-exists (bureaucracy's `_handlePreload()`, reading a GET param named
-`@log_entry_project@`) but wiring it up needs a custom HTML/JS block
-per project page — several new, untested assumptions stacked at once.
-Weighed against that: one extra manual selection on the log form, zero
-new risk. Chosen deliberately — not a placeholder awaiting a better fix.
-If a one-click experience becomes worth the complexity later,
-`@log_entry_project@` is the confirmed starting point — not
-`addnewpage`'s own query string, which was tested and conclusively does
-not carry arbitrary params through.