Both plans keep their scope and gain the contracts their reviews found missing: the backup plan pins the scheduler boundary it depends on, and the upload plan pins the storage contracts its callers already rely on.

Core changes:

1. Backup plan (docs/BACKUP-2026.md):

2. the scheduler boundary is specified rather than assumed

   • every state-changing action is POST; GET only displays state
   • browser actions validate the SLAED CSRF token, cron authenticates by bearer

token in the body and never through the URL

• an OS flock keyed by the canonical job name owns a run; JSON status and

heartbeat are diagnostic only and unlock may not break a live lock

• dbbackup.settings defaults are synchronized across both config sources, and the 6.3 upgrade fills only missing keys

• the nine migration helper procedures are a release prerequisite; Backup fails closed while they exist and never deletes schema objects

• schema fingerprinting excludes AUTO_INCREMENT counters and table statistics
• scheduler row actions render through the real dial fragment
• the verification matrix names upgrade, route, concurrency and restore tests
• Upload plan (docs/UPLOAD-2026.md):

• deleteStoredFile() joins the public surface for the orphan case

  • a database write that fails after publication removes that exact result
  • containment and the destination lock are re-checked on the delete path

• paths are root-relative on both ends, and the stored name keeps the owner suffix the editor ownership filter reads

• go=4 stays as the editor route with two explicit cases and rejects the rest

• DNS resolution, cURL execution and the clock sit behind replaceable internal methods so the security cases are testable without a network

Benefits:

• both plans can now be handed to an implementer without a second review round
• the backup plan no longer depends on scheduler behaviour nobody wrote down
• the upload plan states the contracts a caller would otherwise rediscover

Technical notes:

• documentation only; no code, schema or configuration changes
• neither plan is started, and both keep their no-compatibility-wrapper rule

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