Designing Repair Mode For LLMWikis

LLMWikis.org already treats repair as a first-class use case. The Setup Wizard’s stated purpose includes repairing an existing wiki by defining scope, taxonomy, canonical URLs, metadata, source policy, review gates, r...

Metadata

Field	Value
Source site	llmwikis.org
Source URL	https://llmwikis.org/
Canonical AIWikis URL	https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-271e8b9f/
Source reference	raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-24/Content/Designing Repair Mode for LLMWikis.org.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-16T00:45:48.3318381Z
Content hash	sha256:271e8b9f52b3a3f9df8c1cee3177dbfc4c098623e2f358fc662ad55b506d3919
Import status	unchanged
Raw source layer	data/sources/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-24-con-271e8b9f52b3.md
Normalized source layer	data/normalized/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-24-con-271e8b9f52b3.txt

Current File Content

Structure Preview

• Designing Repair Mode for LLMWikis.org
• Executive Summary
• Standards Baseline and Success Metrics
• Inputs and Platform Adapters
• Detection and Remediation Engine
• Workflow, Wizard UX, and API Design
• Security, Privacy, Testing, and Monitoring
• Migration, Versioning, and Effort Model

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 34274
• Preview characters: 11787

# Designing Repair Mode for LLMWikis.org

## Executive Summary

LLMWikis.org already treats repair as a first-class use case. The Setup Wizard’s stated purpose includes repairing an existing wiki by defining scope, taxonomy, canonical URLs, metadata, source policy, review gates, redirects, and “safe staged migration work,” and it explicitly supports both “Improve or repair an existing wiki” and “Advanced multisite workspace” modes. At the same time, the wizard’s current public boundary is intentionally conservative: it is a browser-only planner that produces a copyable Markdown packet and structured JSON, while explicitly not supporting automatic repository writes or automatic publication. That combination strongly suggests that a production “repair mode” should be designed in layers: first as a standards-aware assessor and staging system, then as an approval-gated remediation system with optional platform-specific write adapters. citeturn26view0turn26view1turn1view3

The quality bar should be defined by LLMWikis’ own standards rather than by generic SEO or generic wiki hygiene. LLMWikis describes a high-quality wiki as one with exportable files and history, explicit metadata, canonical URLs, typed navigation, trust labels, source policy, human review for AI-generated edits, and clear security/privacy boundaries. Its completion test is especially useful: a new human or AI agent should be able to tell what the wiki covers, where to start, what is authoritative, what is sensitive, who owns each core page, what may be edited, what requires human approval, and what remains unknown. citeturn1view1turn27view0turn27view1turn27view2turn27view3turn27view4turn3view6

The recommended architecture is a five-part pipeline: platform adapters, normalization, standards/rule evaluation, staged remediation generation, and approval-governed publication. That model aligns with LLMWikis’ repair guide, which frames repair as an information architecture migration rather than a cleanup pass, and with its two-step operations guidance, which separates analysis from writes so risky decisions can be reviewed before the wiki changes. For multi-site organizations, the same architecture should scale by adding a workspace root, site registry, cross-site canonical registry, and per-site policy overlays rather than by building a different product. citeturn27view5turn27view6turn27view7turn26view2

A pragmatic v1 should therefore produce four primary outputs: a scorecard against LLMWikis standards, a migration map of old URLs to canonical targets, a machine-readable remediation model, and a human-readable restructure packet for review. A later phase can add controlled writers for Git-based wikis, MediaWiki, DokuWiki, and Confluence, but destructive publication should remain explicitly review-gated. citeturn26view0turn26view1turn22view0

## Standards Baseline and Success Metrics

Repair mode should measure success against the standards that LLMWikis repeatedly emphasizes: one durable canonical URL per important concept; page-first structure; explicit index and log; typed related links and breadcrumbs; required metadata; trust labels and freshness rules; source-linked publication; and security/privacy controls that keep sensitive material out of public discovery and portable exports. Public discovery should be generated from canonical public pages only, using sitemap.xml and llms.txt, while graph views, JSON, APIs, and other derived surfaces remain secondary to reviewed canonical pages. citeturn27view0turn27view1turn27view2turn27view3turn27view4turn26view1

The following targets translate that guidance into an operational scorecard. The percentages are recommended implementation thresholds for repair mode, not official LLMWikis conformance values.

| Objective | Recommended metric | Target for high-quality state |
|---|---|---|
| Inventory coverage | Pages discovered from crawl, exports, and APIs divided by total known pages | At least 99 percent |
| Canonical integrity | Duplicate canonical targets among public pages | Zero unresolved duplicates |
| Navigation quality | Public pages with breadcrumbs and at least one local related link | 100 percent |
| Orphan control | Public pages not reachable from index, children lists, or typed links | Zero |
| Metadata completeness | Required LLMWikis fields present on public durable pages | At least 95 percent |
| Governance completeness | Authoritative or reviewed pages with owner, trust label, last reviewed date, and review cadence | 100 percent |
| Safety boundary | Restricted or archive-only pages leaking into sitemap.xml or llms.txt | Zero |
| Change control | High-risk or destructive changes written without human approval | Zero |
| Low-risk automation rate | Deterministic, reversible fixes applied automatically after approval | At least 90 percent of low-risk findings |
| Post-publish stability | Broken redirects or newly broken internal links introduced by repair | Less than 1 percent of changed routes |

Public pages should also be machine-readable outside the wiki platform itself. The Sitemaps protocol exists to list site URLs and optional metadata for crawlers, Google supports sitemap formats defined by that protocol, and llms.txt is an emerging root-level proposal intended to help LLMs use a website at inference time. For public HTML pages, repair mode should also validate canonical link behavior and structured data. Schema.org is a suitable primary vocabulary here: `WebPage` can describe pages generally, `TechArticle` or `Article` can describe page-type-specific content, and `BreadcrumbList` can describe breadcrumb trails. citeturn14search2turn14search6turn14search14turn14search3turn14search7turn25search0turn14search4turn25search1turn14search0turn19search5

## Inputs and Platform Adapters

Repair mode needs more than a starting URL. LLMWikis’ repair sequence explicitly begins by listing pages, routes, files, indexes, public URLs, sitemap entries, llms.txt entries, and internal links; the wizard’s required outputs similarly call for the root URL or repository path, raw source path, compiled wiki path, index/log paths, root index topology, and owner/review/trust/sensitivity/citation/lint policy. In other words, repair mode should treat discovery, content, and governance inputs as equally important. citeturn27view5turn26view2

| Required input | Why repair mode needs it | Typical examples |
|---|---|---|
| Target registry | Defines the repair scope | Site URLs, repository wiki URLs, Confluence site plus space keys, GitLab group/project IDs |
| Discovery files | Establishes expected public surface | `sitemap.xml`, `llms.txt`, `robots.txt`, export manifests |
| Read access | Enables full inventory for private wikis | Read-only API token, service account, Git clone credential, session cookie where appropriate |
| Content export bundle | Preserves source material and revision context | XML dump, HTML export, Markdown repo clone, media archive |
| Governance source data | Allows owner/trust/sensitivity mapping | Owner directory, space/group permissions, review policy docs, escalation rules |
| Writeback target | Supports staging rather than direct overwrite | Pull request target, staging repo, shadow wiki, draft space, redirect config |
| Rollback snapshot | Makes repair reversible | Git tag, XML dump plus DB/filesystem backup, file copy, Confluence export |
| Telemetry | Improves prioritization and validation | 404 logs, search logs, analytics, stale-page reports |

The table below summarizes the major platform differences that a repair-mode adapter layer must absorb. These assumptions come from official platform documentation for MediaWiki, DokuWiki, Confluence, GitHub, and GitLab. MediaWiki exposes Action and REST APIs along with XML export and backup guidance; DokuWiki exposes XML-RPC and JSON-RPC, ACLs, XML sitemap generation, and file-copy backup; Confluence Cloud exposes REST resources plus export and permissions workflows; GitHub wikis are Git repositories with repository-based permissions; and GitLab offers both project and group wikis, with Git-backed storage and REST APIs. citeturn10view0turn28view6turn28view7turn28view8turn28view9turn9search20turn9search0turn9search1turn9search2turn24search1turn24search2turn10view2turn28view3turn28view4turn28view5turn10view4turn10view5turn28view0turn10view6turn10view7turn28view1turn28view2

| Platform | Primary discovery/read path | Best export or backup input | Writeback and rollback notes | Org-level pattern |
|---|---|---|---|---|
| MediaWiki | `api.php`, REST endpoints, full page lists, page content, namespaces | `Special:Export`, XML dumps, plus DB/filesystem backup for real rollback | Writes should use revision-aware APIs to avoid edit conflicts; XML export alone is not a full backup | Single wiki segmented by namespaces, or multiple independent roots |
| DokuWiki | Remote API, sitemap, filesystem namespace layout | Full file copy of wiki files, plus optional export text/media | File-based backup makes rollback straightforward; ACL namespace mapping must be preserved | Namespaces within one install, or multiple installs |
| Confluence Cloud | REST API resources for spaces, pages, versions, permissions; exports | Space export to PDF, CSV, HTML, or XML | Prefer staging spaces or draft workflows; use separate read and write credentials | Spaces within one site act as sub-wikis |
| GitHub wiki | Git clone of `.wiki.git`, page history, repository permissions | Git clone plus tags/commits | Only content on the default branch is live, so staging should happen before merge/push | Organization-level means fleet analysis across many repository wikis |
| GitLab wiki | Project wiki API, group wiki API, Git-backed wiki repos | API export plus Git repo history; PDF export available | Group wikis are useful for docs shared across multiple projects; project and group scopes differ | Groups and group wikis act as org-level containers |

A practical normalization layer should hide those differences behind a common internal model such as `PageRecord`, with fields for page locator, canonical candidates, source form, rendered form, outgoing and incoming links, permissions, revision history, media references, existing metadata, and discovery-surface membership. Where platforms cannot safely host full frontmatter in the page body, repair mode should support metadata sidecars keyed by canonical URL or stable page ID. That recommendation follows from the LLMWikis metadata standard combined with the reality that the supported wiki platforms expose different native storage models and markup conventions. citeturn27view0turn28view7turn28view2turn10view4

## Detection and Remediation Engine

The detection engine should combine deterministic validation with bounded LLM-assisted analysis. Deterministic checks should cover inventory completeness, canonical collisions, breadcrumb coverage, related-link coverage, required metadata presence, stale review dates, invalid trust or status values, redirect correctness, broken internal links, sitemap/llms mismatches, and restricted-content leakage into public discovery. LLM-assisted analysis should be reserved for tasks that are difficult to encode but still bounded by evidence: page-intent classification, duplicate concept clustering, contradiction extraction, mega-page split suggestions, and canonical-winner recommendations. That division follows LLMWikis’ own repair sequence and two-step pipeline: inventory first, classify, find failure modes, choose canonical winners by intent, then stage updates for review before anything is written. citeturn27view5turn27view7turn27view1turn27view0turn27view2turn27view4

Why This File Exists

This is a memory-system evidence file from llmwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: Designing Repair Mode for LLMWikis.org; Executive Summary; Standards Baseline and Success Metrics; Inputs and Platform Adapters; Detection and Remediation Engine; Workflow, Wizard UX, and API Design; Security, Privacy, Testing, and Monitoring; Migration, Versioning, and Effort Model. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-195 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Designing Repair Mode For LLMWikis",
    "source_site":  "llmwikis.org",
    "source_url":  "https://llmwikis.org/",
    "canonical_url":  "https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-271e8b9f/",
    "source_reference":  "raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-24/Content/Designing Repair Mode for LLMWikis.org.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:271e8b9f52b3a3f9df8c1cee3177dbfc4c098623e2f358fc662ad55b506d3919",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-16T00:45:48.3318381Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-195",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}