Wiki Maintenance Log

Auto-maintained by the wiki-sweep routine. Each run records what was swept, advances the category rotation, logs ecosystem signals, and tracks community reception. Do not hand-edit the state block – the routine overwrites it.

The sweep enforces RADIX Wiki's editorial policy: verifiability, neutral point of view, no original research, notability, conflict of interest, and freshness – the last of which sets the 180-day re-verification window this log exists to keep.

Current Status

Signal Watermarks

226 older watermarks held in state.

Open Backlog

• RESOURCES STALENESS HEAD after run 436: legal/privacy-policy and legal/terms-of-use (18 August) remain the two FLAG FOR A HUMAN items; python-scripts/dlt-efficiency-metric and proof-of-work (18 August, verified 6 September, accurate); then recycled-telegram-handles (30 August, not re-swept: t.me web pages do not distinguish an unregistered handle from an empty channel, so the WhyNotXRD and DELIVER_XRD re-check needs the MTProto scraper), brand-assets and radix-visuals (6 September). acceptable-use-policy v1.2.1 and how-to-buy-xrd v1.13.0 were edited and stamped this run.
• FLAG FOR A HUMAN (run 409, process, and it is the second instance of backlog #6's class in two weeks): A SWEEP DIED MID-RUN AND A HARD RESET DELETED ITS SCRIPT WHILE THE EDIT WAS LIVE. Run 409's first session applied the drain-page split to the production database at 14:02 UTC, posted its tweet at 14:13, committed the script as 2193882 at 15:04, and at 15:15 a `git reset --hard HEAD~1` removed the script from the working tree. The session exited at 15:19 without ever writing maintenance-log state. The second session (this one) found totalRuns still 408 with the split live in the database, restored the script from the dangling commit and carried the run to completion. Two things need a human: a concurrency guard so two wiki-sweep sessions cannot be in flight at once (the scheduled task fired twice inside twenty minutes, and memory already records the same collision double-posting a tweet on 2026-07-23), and an answer to what issued the reset, because nothing in the routine calls `git reset --hard` and it discarded the only in-repo record of a major restructure.
• FLAG FOR A HUMAN, opened run 408, and it is the same class as the run-292 em-dash flag rather than an edit this routine should make alone: THE $XRD CASHTAG ABSOLUTE AND THE WIKI CORPUS DISAGREE, CORPUS-WIDE. radix-studio/VOICE.md absolute #1 bans writing a ticker without its cashtag in terms ('10 $XRD, never 10 XRD') and names wiki prose as a surface the file governs. Census taken run 408 over 374 pages: 86 pages contain a bare '<number> XRD' amount and 41 contain '$XRD' at all. This wiki's house style writes XRD as a unit of measure after a figure ('1,455,804,324 XRD') and has done so across every halt reading, every supply table and every treasury figure on the site. Run 408 wrote four new figures in the page convention rather than the VOICE convention, deliberately, because converting one paragraph inside a 146,000-character page whose every other figure reads the other way produces a page that contradicts itself - which is exactly the third option the em-dash flag declined. The two coherent resolutions are the same two as for the em dash: (a) amend VOICE to exempt a unit-of-amount use in long-form wiki prose from the cashtag absolute, keeping it binding on tweets and short-form where it plainly belongs and where this routine already follows it; or (b) keep the absolute and add a bounded conversion pass to each rotation. Do not half-convert. Census query: count pages where content::text matches '[0-9] XRD' versus content::text like '%$XRD%'.
• FLAG FOR A HUMAN (run 414, process, and it is the THIRD instance of this class in thirteen days - see the run-409 and run-338 flags above): TWO MORE SWEEPS EDITED THE LIVE WIKI AND NEVER WROTE STATE. Runs 412 and 413 committed at 21:17 and 21:36 local on 11 September (92d40b0, bf42863) with scripts retained in scripts/ and real edits live on five category hubs, and state was left at totalRuns 411 with rotation.next still 'ecosystem'. Run 414 found the gap, reconstructed both entries into runHistory from the commit messages and the scripts, and moved totalRuns 411 -> 414 in one step. The reconstruction is faithful but it is not the runs' own account, and the rotation accounting is a judgement: run 412 audited the Ecosystem hub, so this run treated the index-9 'ecosystem' slot as spent and took index 10 'ideas'. THE PATTERN IS NOW THE FINDING rather than the incident. Three times in thirteen days a session has written to production and died before writing state, which means the recovery depends on the NEXT run noticing a totalRuns number that does not match git log - and nothing in the routine tells it to look. The cheap fix is an ordering change the routine can adopt without code: write the runHistory entry BEFORE the last edits rather than after, or have step 0 compare totalRuns against the newest sweep-NNN script in scripts/ and stop if they disagree. Both need a human to amend the skill.
• The Community section was retired on 9 September 2026. All twelve profiles and the section hub were deleted, the tag node removed from src/lib/tags.ts, and the rotation slot dropped. The Dan Hughes biography moved to /contents/history/dan-hughes and keeps its history. Two facts that only lived on a profile were folded onto the pages that had deferred to them: the governance quorum recomputation onto /contents/tech/core-concepts/radix-governance, and the validator-badge concentration plus the $4,000 funding proposal onto /contents/tech/releases/stokenet. This closes the run-232 FLAG FOR A HUMAN on /community/cryptoants, which was the last auth-route shell. No page on the wiki links into /community any more; names that were linked are now plain text.
• FLAG FOR A HUMAN (run 362, and it is a deployment rather than an edit): MIOW.ME HAS NO DEPLOYMENT. Read at 03:11 UTC on 4 September, miow.me answers HTTP 404 at the root with x-vercel-error DEPLOYMENT_NOT_FOUND and a 107-byte text/plain body reading that the deployment could not be found on Vercel. That is the domain resolving to nothing rather than a bot wall or an app error, and /llms.txt, /sitemap.xml, /guide, /AGENTS.md and /s/blockspace-capital all answer identically. /ecosystem/miow links to it as a live project. This routine is not going to mark a sibling studio project dormant over a deploy a human can reattach; if the domain is still unattached at the next ecosystem rotation, the page needs a status line either way. || RUN 367 UPDATE: re-read at 23:09 UTC on 4 September, twenty hours later, and it is identical - the deployment is gone, not down. The WIKI side is now closed: /ecosystem/miow v2.1.0 records the outage, unlinks the six dead citations and moves the status to Dormant, and the operational-status index moved it with it. What is still for a human is the deployment itself.
• FLAG FOR A HUMAN (run 355, measured, and it has a date on it): THE FIRST 'MAY BE OUTDATED' BANNER THIS WIKI EVER SHOWS WILL SIT ON A PAGE THE SWEEP CANNOT CLEAR. Read 2 September, no page on the wiki is past the 180-day freshness threshold, and the oldest reading is /ecosystem/xrd-domains - never verified, last edited 28 March 2026, 158 days - which crosses 180 days on 24 SEPTEMBER 2026. That page is one of the two in LOCKED_PAGES in src/lib/tags.ts (with /ecosystem/radix-namespace), so this routine may not edit it; and although scripts/mark-verified.mjs carries no lock guard and would technically write a stamp, stamping a page the sweep cannot then correct would assert a verification it is not in a position to act on. Someone has to choose before 24 September: unlock the page for maintenance, verify it by hand, or accept the banner. Recorded on /policy/freshness v1.4.0 so the wiki states the problem itself. Pairs with the run-232 community/cryptoants flag and the run-256 flag on there being no editor control for verification.
• FLAG FOR A HUMAN (run 338, and it is a process fault rather than a code one): TWO RUNS EDITED THE LIVE WIKI AND NEVER WROTE STATE. scripts/sweep-336-weft-collateral-exploit.mjs and sweep-337-weft-exploit-price-feed.mjs both landed on /ecosystem/weft-finance this evening (revisions at 18:44 and 19:03 UTC, v4.3.0 -> v4.5.0) and are committed in git, but the maintenance log still read totalRuns 335 with rotation.next unmoved at policy when this run opened. The cursor is the only thing standing between the rotation and starvation, so a routine that edits without writing state makes it lie. This run set totalRuns to 338 to close the gap, which loses runs 336 and 337's own runHistory entries - the git log and the two pages' revision rows are the only record they exist. Either those sweeps should write state, or whatever invokes them should.
• FLAG FOR A HUMAN (run 309, code change, one line, and it is now visible to search engines): the `policy` node in src/lib/tags.ts names FIVE policies in its description - 'verifiability, neutral point of view, no original research, notability, and freshness' - and the category holds SEVEN, having gained conflict-of-interest earlier and editorial-notices this run. That string renders as the category page's meta description, so the omission is what Google reads off /policy. It also carries an em dash, which is the run-292 VOICE flag in the same line. MITIGATED IN CONTENT, NOT IN CODE, run 377: /policy now has a hub article at the empty slug, "RADIX Wiki Editorial Policy", whose metadata.excerpt names all seven. generateMetadata prefers a hub excerpt over the node description for a category page, so the string Google reads off /policy is now correct and the page title is the article title rather than "Policy" (verified live after four forced ISR regenerations). The tags.ts string itself still names five and still carries the em dash, so the one-line code change is still the fix wherever else that description renders.
• BANKED, run 306, and it is an outreach call rather than an edit: THE COMMUNITY INDEX OF RADIX MCP SERVERS DOES NOT LIST THIS WIKI'S. github.com/xstelea/awesome-radix-mcp-servers is 465 bytes and names three servers (Attos World, SBOR EZ Mode, Astrolescent). radix.wiki has run a spec-correct Streamable HTTP server since at least Aug 2026, is published in the official MCP registry as wiki.radix/radix-wiki, and is absent from the index; so is the RadixScan Agent Layer, which /developers/radix-developer-resources also links. Adding either is a pull request to someone else's repo, which this routine does not open. FLAG FOR A HUMAN if the listing is wanted.
• MEASURED, run 308: THE LEDGER AND THE RULEBOOK DISAGREE ON A FIELD NAME AND ONLY ONE OF THEM IS AUTHORITATIVE. The deployed governance component's election parameter set carries minimum_median_grade. The framework it implements settles grades at the Grade Quantile, three-fifths of the voting power cast, and DAO Parameters 6B records that quantile as 'fixed in Proposal & Voting Framework 6.2.4; not a parameter' and calls the floor the MJ Minimum Qualifying Grade. GP-ELECT-1 says in terms that grades are settled at the quantile 'not at the median'. This wiki repeated the median reading from 14 Aug to 26 Aug and it is now corrected on /ideas/dao-elect-permanent-rac. Watch: if the contract is redeployed, see whether the field is renamed. The same median wording also sits in an exemplar in radix-studio/VOICE.md 2, which is a human's file - FLAG FOR A HUMAN rather than an edit.
• FLAG FOR A HUMAN (run 305, and it is a scheduling decision rather than a maintenance one): THE HOOK PIPELINE IS BACKING UP FASTER THAN THE CAP CAN DRAIN IT. Seven runs in a row have now skipped the tweet on cadence (297, 298, 299, 301, 303, 304, 305) and SEVEN priority hooks sit banked and unposted - runs 297, 298, 299, 301, 303, 304 and this one. The arithmetic is structural, not bad luck: wiki-sweep runs roughly every four hours (six times a day), each run is expected to produce something worth sharing, and the @RadixWiki feed is shared with the radixwiki-tweet routine, all against a 1-2 originals/day cap. On 25 Aug the day's three originals were 03:11, 11:16 and 20:12, and only two of the three came from this routine. Two of the banked hooks have already had a decay date pass or approach (run 297's StakeSafe beat, 30 Aug; run 304's ZENITH beat, 30 Aug). The decision a human owns: either lift the cap, or give wiki-sweep a reserved slot in the shared feed, or accept that most of what this routine finds is never posted and stop scoring runs on whether they tweeted. Do NOT resolve it by tweeting more inside the current cap - reception is healthy precisely because the feed is not crowded (22 judged, median 15.5 lk / 250.5 imp, one zero-engagement post and it is a reply).
• FLAG FOR A HUMAN, opened run 292, and it is a VOICE decision rather than a maintenance one, measured before being raised: radix-studio/VOICE.md absolute #1 bans the em dash on EVERY surface and names wiki articles as a public-facing surface, and this wiki carries 982 em dashes across 115 of its 365 pages. This is not one drifted page. It is the house style of the corpus, written that way by this routine over many runs, and run 292's own three edits added more before the census was taken. Two coherent resolutions and this routine should not pick between them alone: (a) amend VOICE to exempt long-form wiki prose from the em-dash absolute, which is the smaller change and matches what both wikis actually publish, or (b) keep the absolute and add a bounded en-dash pass to each rotation - roughly 8 pages a run at the current cadence, mechanical, and every one of them needs a revision row. What must NOT happen is the third option this run declined: fixing only the pages a sweep happens to touch, which leaves the corpus half-converted and the rule half-enforced with no record of which half. Census query: SELECT count over pages where content::text matches an em dash or &mdash;.
• FLAG FOR A HUMAN (run 265, code change, and without it the data fix above decays): the TipTap Link extension stamps every hand-typed link with target="_blank" rel="noopener noreferrer nofollow". That is right for an outbound citation and wrong for a link to another page of this wiki, and it is why 271 internal anchors carry nofollow. The editor should choose per-href: internal (starts "/" or radix.wiki) gets rel="noopener" and no target; external keeps the current default. One conditional in the Link extension config. Until it ships, every page edited in the browser reintroduces the defect.
• FLAG FOR A HUMAN (run 256, code change, and it is the smallest of the standing flags): there is no way for an editor to record that they re-checked a page. lastVerifiedAt is read in five places in src/ and written in none — only scripts/mark-verified.mjs sets it — so every verification the wiki displays comes from the sweep, and a human editor who confirms a page is still correct leaves no trace but a revision. /policy/freshness now says so plainly (v1.3.0), which is the honest fix, but the real fix is a "mark verified" control on the editor or an API field on PUT /api/wiki/[...path]. Pairs with the run-239 flag on BANNER_META hrefs: both are small edits to make the policy cluster describe a system that exists.

45 older open items held in state.

Community Feedback & Reception

• 2026-09-17 – run 445: no new wiki comments; @RadixWiki likes_per_1k 40.6 vs 19.6 at d7 on the last 8 judged posts. Traffic flat at 3,804 visitors/30d; /api/mcp still the top path.
• 2026-09-16 – run 442, measurement: @RadixWiki likes_per_1k 29.8 over 23 judged posts against 19.6 seven days earlier, median impressions 291 (flat). Third consecutive reading near 28-30, so the rise since 11 September is holding rather than one post's spike.
• 2026-09-16 – run 439, and it is a measurement rather than a comment: @RadixWiki's likes_per_1k is 28.3 over 23 judged posts against 19.6 seven days earlier, on a median impression count that has not moved (298 against 310). The zero rate is one post in 23 and that one is a reply. Per REACH.md Law 2 the rate is the health metric and the zero rate is not, so this reads as the feed getting better response from the same reach rather than more of it.
• 2026-09-15 – run 438, and it is feedback from the measurement rather than from a person: @RadixWiki's likes_per_1k is 28.4 against 19.6 seven days ago, and the best post of the 23 judged is the 11 September VaultDrainer one, 18 likes on 474 impressions. Both of this run's leads were discoveries with a ledger reading behind them rather than "here is what I tidied up", which is the shape the ledger row keeps rewarding.
• 2026-09-15 – run 436: @RadixWiki reception steady (median 9.5 likes / 306.5 impressions, likes_per_1k 28.4 against 19.6 at d7). The hyperlane-asset-drain page still carries the most wiki traffic after the MCP endpoint (680 of 3,750 visitors in 30 days); how-to-buy-xrd is not in the top six.
• 2026-09-15 – run 434: @RadixWiki 24 judged posts at 18h, median 9.5 likes / 293 impressions, likes_per_1k 28.5 against a d7 reading of 19.6, one zero (a reply). Plausible 30d radix.wiki: 3,750 visitors; top pages /api/mcp 746, hyperlane-asset-drain-2026 680, / 656, /ecosystem 165; daily visitors eased from 335 on 1 Sept to 114 on 14 Sept. Neither page edited this run is in the top pages.
• 2026-09-15 – run 433: no wiki comments or @RadixWiki mentions about the wiki found. X reception flat (median 9.5 likes / 291.5 impressions, likes_per_1k 28.6, trend null). Plausible 30d unchanged since run 431; the drain article (680) remains the only history page in top_pages.
• 2026-09-15 – run 432: @RadixWiki 24 judged, median 9.5 likes / 290 impressions, likes_per_1k 28.7 (flat against runs 430-431). The 14 Sept 20:09 exchange-rate post sits at 6 likes / 177 impressions at 7h, below median. Zero wiki comments seen this run. Traffic 30d 3,750 visitors; /api/mcp 746 and the drain page 680 lead, daily visitors easing from the 1 Sept peak of 335 to 114 on 14 Sept.

32 older entries held in state.

Recent Runs