Журнал изменений

Stage 2 of docs/COMMENTS-REDESIGN-2026.md. The comment body becomes the source the author wrote and the parser escapes it on read, every write is transactional and idempotent, and the table gains the columns and indexes that make a soft delete, an idempotency key and a keyed flood fingerprint possible.

Core changes:

1. Comment subsystem (core/classes/comment.php):

2. checkRules() replaces checkAddRules()/checkEditRules() as one ordered rule set

   • the length rule measures the longest word, not the last one
   • it counts characters instead of bytes
   • the add-only rules (guest name, flood window, captcha) stay bound to the add

3. add, edit, status and delete are transactional with checked results

   • status and delete are conditional updates, so a parallel request cannot count twice
   • the row is read FOR UPDATE inside the same transaction
   • an operation joins a transaction that is already open instead of refusing
4. deleteComment() marks the row instead of erasing it, and every read filters it
5. addComment() stores reqkey, iphash and format and answers a replay from the failed insert
6. filterCommentBody() replaces filterHtml() in the write path and stores source
7. getBodyFormat() refuses html as a comment format
8. CommentMode replaces the bare acomm comparisons, getTargetMode() answers the enum
9. listings sort on time, id
10. Parser (core/classes/parser.php):

11. filterContent() and filterDoc() take the source format as a fifth argument

    • plain recognises no Markdown construct and turns line endings into breaks
    • anything else is Markdown, which is what every existing caller gets
12. the inline BB pairs stash their tags, so safe = true keeps them readable
13. Schema (setup/sql/table.sql, setup/sql/table_update6_3.sql):
14. five columns added: format, edited, deleted, reqkey, iphash
15. five indexes added, cid and modul_status dropped, KEY time kept
16. new addcol procedure, reqkey backfilled before its unique index is created
17. a fresh install and the upgrade produce an identical table definition
18. Storage migration (tools/comment-migrate.php):
19. classify writes the format of every row in its own reviewable pass
20. convert rewrites the bodies per class, in batches, resumable through a ledger
21. iphash backfills the flood fingerprint from the stored address
22. report and sample answer read-only, and --db runs the whole thing on a copy
23. Render sites (core/user.php, core/system.php, admin/modules/comments.php):
24. all four comment renders moved to safe = true and pass the row format
25. the moderation save reads the raw field, because the body is source now
26. Tests (tests/Unit/CommentStateTest.php, tests/Support/contract_probe.php):
27. 15 cases over a probe that signs in as an administrator before the core boots

28. repeated status transitions, idempotent delete, replayed key, stable sort, round-trip of both classes and the write-path normalisation are all measured

29. the stage 0 guard and the parser fixtures follow the two shapes this stage changed

Benefits:

• stored XSS through the comment path is closed by the rendering model itself

• a moderation click, a double submit and a repeated delete can no longer move a target counter or an author's points twice

• the flood check runs on an indexed fingerprint instead of a plain address
• the list, its count and its pager can no longer disagree about a deleted row

Technical notes:

• the body format is stored per row: plain or markdown, never html

• the upgrade is idempotent, but tools/comment-migrate.php is not optional - until classify and convert have run, comments render with their old escaping

• 121 of 7353 rendered comments change on purpose and are recorded in the plan

• docs/BACKUP-2026.md and docs/UPLOAD-2026.md carry an unrelated rewrite that was already in the working tree

The order table of the shared execution cookbook records that the mail queue and drain stage is finished and committed, so the next chat opens at the row after it instead of re-reading a stage that is already in the tree.

Core changes:

1. Order of work (docs/EXECUTION-2026.md):
2. row 4, mail stage 2, struck through and marked done

3. the next open row is comments stage 2, which still needs its one comment-baseline capture before its first chat

Benefits:

• the cookbook keeps telling a fresh session where to start

Technical notes:

• no code changes and no changes to the prompts or the templates

Stage 2 of docs/MAIL-2026.md. addQueue() stores a row and answers accepted into the queue; delivery moves to a scheduler job that claims, sends and records under a lock, so no request waits on a transport and no failure stays invisible. No call site changes: all 26 moved to $mailer->addQueue() in stage 1.

Core changes:

1. The queue table (setup/sql/table.sql, setup/sql/table_update6_3.sql):

2. {prefix}_mail holds kind, sender, email, title, body, ref, prio, time, ntime, tries, status, camp, hold, locked, lockid, phase, code and error

3. the claim index leads with hold, status, prio, ntime, id; kind_status_time and kind_ref_status serve retention and the campaign queries stage 3 adds

4. the upgrade statement creates the table with its primary key alone and adds every secondary index through addidx, so a half-applied schema is repaired instead of refused

5. Queue and drain (core/classes/mail.php):

6. addQueue() stores instead of delivering; every value is bounded against the column that holds it, and an oversized subject is refused where the caller can still be told rather than by a failing write

7. getBatch() claims one batch in a single conditional UPDATE and moves the rows behind the lock window, which is what makes the claim exclusive

   • the predicate is exactly what the claim index leads with: with a marker

column in it the optimizer left that index and filesorted 99 267 rows

• setResult() records the outcome, grows the backoff per attempt and fails the row at the attempt cap; a reference to a body that is gone is not retried

• updateQueue() is time-boxed rather than count-boxed, honours mail.rate across runs through the job state, and keeps one transport connection for the run

• deleteQueue() prunes accepted rows per kind and never touches a failed one
• sending is private: the queue is the only way out
• Scheduler job (config/scheduler.php, core/system.php, setup/index.php):
• maildrain ships active, runs every five minutes and stays manually triggerable

• addMailTask() maps a run to the job status: an empty queue is a success, a run that refused everything it tried is a failure

• the upgrade inserts the job into an existing config/scheduler.php
• Queue settings and the test send (admin/modules/config.php, admin/lang/*.php):

• batch, rate, tries, backoff, keep and keepbulk get a row on the mail tab and are validated on save

• the test send queues and then drains inside the request, so the button still reports the transport's own words; a run that sent nothing says so instead of claiming a delivery nobody observed

• seven constants added to all six locales
• Tests (tests/Unit/MailQueueTest.php, tests/Unit/MailDrainTest.php, tests/Support/):
• 25 tests over the statements the queue issues and the bounds it holds

• 15 tests driving the live database and a loopback SMTP sink through tests/Support/mail_probe.php and tests/Support/mail_relay.php

• the stage 1 transport tests now enter delivery the way the drain does

Benefits:

• a request that sends mail returns at once: the security notice measured here queues in 0.11 s where the same path used to wait on mail()

• a refused delivery is retried behind a backoff and recorded instead of being discarded

• one SMTP handshake per drain run rather than one per message

• the claim reads its 25 rows in 1.9 ms with 100 000 pending, against 202 ms before the predicate was written against the index

Technical notes:

• new table {prefix}_mail; a fresh install and an upgrade produce the same definition, the upgrade is idempotent and repairs a partially applied one

• two processes racing one queue of 400 rows claimed 200 each with no overlap

• breaking change: mail becomes asynchronous on every installation that takes this release, and addQueue() answers accepted into the queue, never delivered

• no compatibility layer and no runtime schema detection
• config/mail.php is unchanged: stage 1 already shipped every queue key

The comment plan gains its last stage 1 entry and is re-measured against the code the batch left behind, so a session reading only the plan sees the delivered state rather than the designed one.

Core changes:

1. Progress and decisions (docs/COMMENTS-REDESIGN-2026.md):
2. batch 6 recorded: what moved, what was measured and how

3. eight decisions added, covering the single module map, the public resolver against the private counter, the deletion of ashowcom() rather than a rename, the precomputed sidebar count and the shape the guard has to look for

4. deviations added: the render defect moved verbatim, the unstable sort that makes an ascending capture differ from itself, two measurement artefacts, and the config cache that silently defeats a sort change

5. Facts re-measured after the move:
6. core/system.php 5944 to 5689 lines; the render is 136 lines in core/user.php
7. seven defined('ADMIN_FILE') branches inside the deleted function, not eight
8. no stored comment carries a module outside the eight-entry map
9. line references refreshed across the Facts, Target design and Stage 2 sections
10. Blockers closed:

11. the frontend page-cache mechanism is index.php:130 through Cache::addEpoch(), mixed into every page key by getPageHash(); the two halves of the contract it does not meet are named and handed to stage 4

12. the admin sidebar chip entry of the consumer list is struck through
13. Execution cookbook (docs/EXECUTION-2026.md):

14. comments stage 0, mail stage 1 and comments stage 1 marked done in the order table, so the next chat starts at mail stage 2

Benefits:

• the plan states what was delivered and what was deliberately not, so the next stage does not rediscover either

• every number quoted in it was measured against the current tree

Technical notes:

• no code changes

• one item of the stage is recorded as not delivered: deleteUser(), because the behaviour it would replace has never been decided

• the markup baseline is left reporting CHANGED for three modules; the cause is recorded with the statement that restores it

The Progress section is the only place decisions of a finished batch survive into the next chat, so batch 5 writes down what it moved, what it measured, and the two consumers the plan's own fact list had missed.

Core changes:

1. Progress and decisions (docs/COMMENTS-REDESIGN-2026.md):

2. batch 5 row: what moved, the three parity measurements, and the checks that ran

3. decisions: why deleteTarget() binds one placeholder per id and moves no counter, why it does not re-validate the module, why the whole shop id list was bound rather than the comment statement alone, what the two extra round trips per profile page buy, and where the unreachable feed guard went

4. Consumers found by reading rather than grepping:

5. modules/account/index.php built the profile hub from the same module map as the feed, so it reached the comment table through an assembled name and never appeared in a search for the literal; batch 5 migrated it

6. core/admin.php:319 counts pending comments the same way through getAdminCountRow() and is recorded as open, with what it would take

7. the stage 1 acceptance criterion now says a sweep for the literal name is not enough, and names both shapes seen so far

8. Re-measured facts (docs/COMMENTS-REDESIGN-2026.md):

9. the comment table holds 7353 rows and 3 pending, not 7357 and 4; the distribution moved with it, and the stage 2 body migration must measure the table it actually runs on

10. the class line numbers cited across the plan are refreshed
11. the shop id-list interpolation is struck from the fact list
12. Deviations worth carrying (docs/COMMENTS-REDESIGN-2026.md):

13. comment-baseline verify reported CHANGED for three modules and the cause was the verification itself: one point per rendered admin page moved a counter the author card shows; the value was restored and the baseline deliberately not re-captured

14. the comment entry of the profile module map now carries three dead keys, and that is the disguise which hid two consumers

15. two log entries found and left alone, neither owned by this batch

Benefits:

• a new chat reading only this file sees why each deviation exists
• batch 6 inherits a stage guard that knows what to look for

Technical notes:

• no code changes in this commit