docs: add balance checkpoints to maintainer workflow

Author: kvz

CHANGELOG.md

@@ -28,14 +28,13 @@ Ideas that will be planned and find their way into a release at one point
 - [ ] Parse `require`s with ts-morph. Then we can add dependencies back to website
 - [ ] website: Render authors server-side
 - [ ] website: Fix the search functionality
-- [ ] Verification: verify examples against native runtimes (PHP/Go/Python/Ruby/C) with Docker
-      - [x] `yarn verify` and `yarn verify:php` scripts added
-      - [x] Docker-based PHP verification working (62/91 string functions pass, 68.1%)
-      - [x] Parallel execution with p-map (8x concurrency)
-      - [x] Cache invalidation when verify.ts changes
-      - [x] Strip PHP warnings from output, fix object literal translation, string-aware property access
-      - [x] JSON forward slash normalization, skip language constructs (echo)
-      - [ ] Remaining 29 failures: Unicode handling, pass-by-ref patterns, implementation differences
+- [ ] Verification: verify examples against native runtimes with Docker (balance efforts across languages)
+      - [x] PHP: 62/91 (68%) - remaining: Unicode, pass-by-ref, complex edge cases
+      - [ ] Go: not implemented (Docker image configured but verification skipped)
+      - [ ] Python: not implemented
+      - [ ] Ruby: not implemented
+      - [ ] C: not implemented
+      - [x] Infrastructure: parallel execution, caching, PHP warning stripping
       - [ ] CI integration: fail if verification diverges
       - [ ] Badge: "Verified against PHP 8.3"
 - [ ] Modernize, e.g.:

CORE_MAINTAINER.md

@@ -20,14 +20,16 @@ Note that for any task, it's important to first get ample context. Search past i
 2. Use `gh` to check on pending PRs. First run `gh auth status` to understand what our GitHub identity is. Make sure all PRs have reviews by other people than our identity (fixable only when PRs are submitted by others), that PRs pass (fixable only if they were submitted by US), fix what can be fixed, then re-check next iteration. If all is green, merge. LLMs should refrain from commenting on PRs, but deep reviews on PRs by others are allowed.
 3. Triage issues. Confirm repro, decide scope, and say no when needed to protect project goals (see `## Vision`, `README.md`, `CHANGELOG.md`, and `website/source/about.md`). LLMs should refrain from commenting on Issues.
 4. To continuously modernize the project, revise the Backlog/Roadmap in `CHANGELOG.md`. Don't forget about the website, which lives in this repo and is deployed via GHA. Check off items and/or move them into releases as appropriate.
-5. Decide an issue to work on. Attempt to balance time spent over different areas. It could come from 
+5. Decide an issue to work on. **Before starting, check:** What areas have received attention in the last 5 iterations? Prioritize neglected areas. Balance time across: verification (all languages), modernization, TypeScript, website, dependencies.
+
+    It could come from:
     - a security concern
-    - the Backlog/Roadmap in `CHANGELOG.md`. Attampt to balance time spent in different parts of this, too
+    - the Backlog/Roadmap in `CHANGELOG.md` (balance across different items)
     - a verified GitHub issue
     - a PR failure
     - upgrading outdated dependencies, checking release notes, taking care of the potential migration, leveraging new capabilities
     - unfinished business
-    
+
     Do what is most important and impactful first. First search what is already available, and what we can already re-use, even if it takes a little refactoring. Define what a successful outcome looks like and how you'll validate it (tests, browser checks, screenshots for design changes, or a working migration). This is imperative: no changes without validation. Anything that can't be validated should not be PR'ed or merged.
 6. **NEVER commit directly to `main`.** Always create or (re-use, see `Batching Related Work`) another branch and open a PR:
     ```bash

docs/prompts/LOG.md

@@ -6,6 +6,8 @@ LLMs log key learnings, progress, and next steps in one `### Iteration ${increme
 
 - An iteration starts with a level 3 heading: `### Iteration ${incrementing number}`
 - An iteration contains the datetime, and a list of bullet points
+- Each iteration should note which backlog area was touched (e.g., verification, modernization, TypeScript, website, dependencies)
+- Every 10 iterations, review balance: have different backlog areas been addressed, or has one area dominated?
 - Every 10 iterations must be summarized and compacted into one list of bullet points, e.g. `### Iterations 1-10`.
 - If you write to this file and find any violation, revise this document to make it adhere