WEIPING_WIKI Maintenance System
Historical aliases: vipinknowledge, vipin wiki, and vipin-wiki. The old page slug vipinknowledge-maintenance-system is retained as a compatibility alias; new docs should link here.
Purpose
EXTRACTED: WEIPING_WIKI should function as a maintained whole-computer project map and durable knowledge system, not as a wiki that depends on a fresh prompt every time.
The maintenance system has three jobs:
- keep important project roots detailed enough for a future agent to start work safely
- keep low-value/system/cache/download roots summarized instead of over-reading them
- improve the
weiping-wikiskill, scripts, and docs whenever maintenance becomes prompt-dependent;vipin-wikiremains a historical alias for old paths and prompts - coordinate with the shared
workstation-maintenanceskill when physical C:/D:/G: organization is required - keep the WEIPING agentic project constellation connected through public-safe route pages, optional artifact contracts, and validation commands without making repositories depend on each other’s private runtime state
Defaults
EXTRACTED: The default maintenance policy is weekly automatic maintenance, safe auto commit and push, and shallow all-drive scanning.
| Decision | Default |
|---|---|
| Schedule | Weekly Tuesday afternoon local time |
| Model | gpt-5.5 |
| Reasoning | xhigh when supported; otherwise record the strongest accepted fallback |
| Scan boundary | Shallow C:/, D:/, and G:/ scan |
| Deep reads | Only important roots and only entry evidence |
| Commit policy | Commit and push scoped validated changes |
| Report storage | Ignored .wiki-tmp/vipinknowledge-maintenance/ for historical compatibility |
| Physical file moves | workstation-maintenance manifest or D-root organization plan plus user approval; broad approval can cover all currently preflighted low-risk batches; no deletion |
Canonical Command Surface
The canonical dry-run/report command is:
python scripts/wiki.py maintain --scope whole-computer --jsonIt collects:
- git dirty summary
- agentmemory health
- shallow computer inventory
- wiki maintenance audit
- wiki health, lint, and catalog status
- recommendations for curated maintenance
The thin PowerShell wrapper is:
powershell .\scripts\wiki-maintain.ps1 -Scope whole-computer -JsonSkill Layer
EXTRACTED: Codex uses .codex/skills/vipin-wiki/SKILL.md; Claude Code and OpenCode can use .claude/skills/vipin-wiki/SKILL.md. These compatibility folders now expose the weiping-wiki skill name while preserving the historical vipin-wiki path.
EXTRACTED: Physical drive organization is delegated to D:/agent-resources/skills/vipin/workstation-maintenance, which is exposed through D:/devtools/codex/home/skills/workstation-maintenance and D:/devtools/claude/skills/workstation-maintenance by local junctions.
The Codex skill is the full orchestrator. Its references split the recurring procedures:
whole-computer-depth.md- importance tiers and evidence depthweekly-maintenance-runbook.md- recurring automation behaviorskill-upgrade-loop.md- how to improve the skill itselfsafety-and-automation.md- public/private and commit/push gatesmaintenance-model.md- broad maintenance model
The shared workstation skill owns dry-run C:/D:/G: inventory manifests, risk classification, D:/Research resolved-path exclusion, type-grouped and age-gated user-approved file move batches, D-drive root move-with-junction organization, broad-approval execution, approval packets, rollback manifests, and devtools/agent-resources/WEIPING_WIKI skill-link sync checks.
Whole-Computer Routing
Use whole-computer-project-map first for all whole-computer maintenance. It decides how deeply to inspect each drive/root.
Use d-drive-project-map for D-drive infrastructure detail, local-active-project-roots for active non-research projects, local-project-roots for broader local roots, and research-project-workbench before repeated research project work.
Use weiping-agentic-project-constellation when the maintenance task mentions WEIPING_WIKI, devtools, AGENT_RESOURCE, AGENTIC_SCIENCE, WEIPING_LAB, WEIPING_COUNCIL, vipinknowledge, vipin-lab, or vipin-council together.
Important roots should record path, purpose, current activity status, first-read files, safety boundary, related wiki pages, and last verified evidence. Low-value roots should stay as bucket summaries.
If the work involves moving files, generate the workstation manifest and conservative move plan first. Live move plans defer recent files and cap batch sizes by default; every batch can be preflighted together without moving files, and exact batches may be preflighted again immediately before approval. If the work involves immediate D-root directory organization, generate a drive-root organization plan and preflight it; eligible roots move under D:/_Organized/<bucket>/_RootDirs while old paths stay usable through junctions. When the user grants broad approval, proceed through all currently passing low-risk batches instead of asking for trivial per-batch confirmations. Update wiki pages after dry-run evidence or after an approved batch changes the filesystem. Public pages should summarize bucket-level state and safety rules, not raw sensitive file names.
Automation Contract
Automation may commit and push only after:
python scripts/wiki.py catalogpython scripts/wiki.py lintpython scripts/wiki.py health --jsonpowershell .\scripts\Test-PrePushSafety.ps1git diff --check
Automation must stage only scoped wiki/skill/script/doc changes. It must not stage unrelated dirty work, ignored report artifacts, workstation manifests, preflight manifests, move plans from .wiki-tmp, memory session dumps, raw private material, caches, generated runtime artifacts, or external project files.
EXTRACTED: Obvious same-session or cross-chat wiki/raw/memory/doc outputs should not be left behind just because they look like adjacent dirty work. If inspection shows they are deliberate, public-safe, validated, and part of the user’s ongoing knowledge work, include them in a scoped commit. Hold them back only when they are source-unclear, sensitive, conflicting, incomplete, external-project edits, or validation-failing.
If validation fails, the automation stops before commit/push and leaves the report for a future agent.
Recurring WEIPING_WIKI maintenance should be Codex-owned. It should not invoke CC/Claude/OpenCode partner review from the scheduled automation; use local evidence, Codex self-review, and validation gates unless the user explicitly scopes a separate partner review.
UUPF-Aided Skill Upgrades
EXTRACTED: Major maintenance-skill redesigns should use UUPF from D:/AGENTIC_SCIENCE/uupf/UniversalUpgradeForge.zip in offline mode first. A valid UUPF planning pass should produce 108 iteration records, FINAL_REPORT.md, ITERATION_LOG.md, and PROVENANCE.md under ignored .wiki-tmp/uupf-runs/.
UUPF reports are audit input, not automatic truth. The responsible agent still hand-applies concise changes, checks live project evidence, preserves public/private boundaries, and validates before commit.
EXTRACTED: On 2026-06-04, UUPF was run in offline mode against the Codex weiping-wiki skill and the shared workstation-maintenance skill for 108 iterations each. The accepted durable outcome was curated rule/script/doc updates, not raw UUPF report publication.
Tight Links, Low Coupling
EXTRACTED: WEIPING_WIKI should connect the important local projects tightly through routing maps, aliases, optional artifact paths, and source-of-truth entry docs.
INFERRED: High coupling is a maintenance risk. A public route is acceptable when each repository can still run its own basic verification without another repository’s private .env, local DB, runtime cache, generated UUPF report, or active workspace.
Counterpoints And Gaps
- The system is intentionally not a full-disk deep crawler; deep crawling would be slower, noisier, and riskier around private material.
- The maintenance command produces evidence and recommendations, but curated wiki/skill edits still require agent judgment.
- Whole-computer maps can drift as folders move or projects become active; future agents should rescan live evidence before making current-state claims.
- CC-family review may be unavailable if local partner tooling or upstream credentials are down; in that case Codex should state the limitation and perform a bounded self-review.
- Some important roots are still newly promoted in the maps; future automation should verify their current README/AGENTS/package evidence before claiming deep understanding.