hector-bot/knowledge-base
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
knowledge-base/wiki/tasks/maintenance-todo.md
Hector 40463cbf4a docs(wiki): WMT-001 fixtures-validation note 
Alle 3 Test-Fixtures in scripts/test-fixtures/wiki-lint/{clean,messy,broken}-wiki/
sind v1.5-kompatibel:
- clean-wiki: 3 Files, Exit 0, alle Sections grün
- messy-wiki: 3 Files, Exit 1, Issues=2 (Stubs + Missing Frontmatter)
- broken-wiki: 3 Files, Exit 1, Issues=3 (Stubs + Missing Frontmatter + Broken Ref)
- Fixtures testen Mechanik (Stub/Frontmatter/Orphan/Broken-Ref/Raw-Coverage),
  nicht spezifische Sub-Categories → Schema-stabil.
2026-06-17 15:27:49 +02:00

11 KiB
Raw Blame History

Wiki-Maintenance Backlog

Erstellt: 2026-06-16 | Schema v1.0 | Erweitert: 2026-06-17 (Schema v1.5 — wiki/people/ + wiki/institutions/ ToDos WMT-009/010) Owner: Hector (Hauptagent) | Subagents führen aus, melden via Topic

ToDo

  • WMT-001 — scripts/wiki-lint.sh finalisieren + Test-Fixtures

    • Category: tooling | Effort: M | Status: in-progress (gestartet 2026-06-17 13:19, wiki-do von k9ert)
    • Subagent: scripts/subagents/wiki-lint-runner.md
    • Notes: Draft v0.1 läuft (output/draft-wiki-lint.sh), Report korrekt, Exit-Code 1 bei Issues. Muss noch von output/ → scripts/ und Fixtures.
    • Stand 2026-06-17: wiki-lint.sh (360 Zeilen) ist bereits in scripts/ und läuft sauber (letzter Run: 51 Pages, 0 Issues). Draft-Wegfall bereits erfolgt. Übrig: Header-Version 0.1 → 1.0, Fixtures-Validierung, Test-Suite hat 2 veraltete Asserts (Test 4 real-repo).
    • Subagent-Auftrag inkl. konkreter Fixes:
      1. Header-Version 0.1 (Draft 2026-06-16) → 1.0 (2026-06-17)
      2. Test 4 Erwartung anpassen: real-repo kann jetzt exit=0 oder 1 sein (clean state). Test soll „irgendeine Section" prüfen, nicht spezifisch „frontmatter" — Section heißt jetzt „Frontmatter Präsenz" mit Umlaut.
      3. Fixtures in scripts/test-fixtures/wiki-lint/{clean,messy,broken}-wiki/ durchgehen — passen die noch zur aktuellen Wiki-Struktur (Schema v1.5: people/, institutions/, hardware/ in concepts/)?
      4. Optional: Falls Schema v1.5 Sections (concepts/hardware, concepts/agi) im Lint-Output als „neu seit v1.4" markiert werden sollen, Changelog-Hinweis im Header.
    • Definition of Done: alle 17 Test-Asserts grün, Header-Version 1.0, Fixtures-Check dokumentiert, Commit auf Remote.
    • Fixtures-Validierung (WMT-001, 2026-06-17):
      • clean-wiki: 3 Files, Exit 0, alle Sections grün ✅. Passt weiterhin — keine Schema-Abhängigkeit.
      • messy-wiki: 3 Files, Exit 1, Issues=2 (Stubs + Missing Frontmatter). Detektiert polymarket-Cluster ✅. Passt weiterhin.
      • broken-wiki: 3 Files, Exit 1, Issues=3 (Stubs + Missing Frontmatter + Broken Ref + Uncovered Raw). Passt weiterhin.
      • Fazit: Alle 3 Fixtures sind v1.5-kompatibel. Keine Anpassung nötig. Die Fixtures testen nur die Mechanik (Stub/Frontmatter/Orphan/Broken-Ref/Raw-Coverage), nicht spezifische Sub-Categories — daher Schema-stabil.

  • WMT-002 — 12 Wiki-Pages mit Frontmatter nachziehen | schema | S | 2026-06-16

    • Schema: siehe AGENTS.md § "Wiki-Pages haben minimales Frontmatter"
    • 12 Files, Commits: 7c6dcc5 b4da4b9 f9853df 3b7accb 578cf25 a722740 502fe40 688bf09 73a9b34 369de77 cf88919 6b419b6
    • Lint-Verify: ./scripts/wiki-lint.sh → Total: 47 | Issues: 0 (Frontmatter-Check ✅ 0 missing)
    • Retry 2: ollama/minimax-m3 (Retry 1 auf ollama/glm-5.1 scheiterte an zai-billing-error)

  • WMT-003 — 11 Stubs analysieren (füllen oder killen) | content | L | 2026-06-16

    • 11 Files bearbeitet: 7× expand + 4× tag (stub-toleriert)
    • Expand-Commits: e418357 6ecfdf0 a14cbf6 250ad1d 6a2bfa7 54ea74a 298eb14
    • Tag-Commits: 3794972 65bc333 eb3b647 6b1542a
    • Lint-Verify: ./scripts/wiki-lint.sh → Total: 47 | Issues: 0, Stub-Quote 11/47 (23%) → 4/47 (8%) ✅
    • Retry 2: ollama/minimax-m3 (Retry 1 auf ollama/glm-5.1 scheiterte an zai-billing-error)

  • WMT-004 — Dup-Topic-Cluster auflösen (Hub-Pages)

    • Category: structure | Effort: M | Status: planning
    • Subagent: scripts/subagents/hub-page-creator.md
    • Cluster: polymarket (3), lightning (4), trading (7), subconscious (6)
    • Strategie: 1 Hub-Page pro Cluster, Spreu-Cluster (subconscious, memory) → kein Hub nötig, sind normal verteilt.

  • WMT-005 — 1 uncovered raw → Wiki-Coverage herstellen

    • Category: coverage | Effort: XS | Status: planning
    • Subagent: scripts/subagents/raw-coverage-check.md
    • File: raw/blog/2026-06-13_trump-blocks-anthropic-fable-mythos.md
    • Notes: Sehr ähnlich zu 2026-06-13_trump-export-controls-anthropic-mythos-fable.md — vermutlich Duplikat. Subagent prüft + mergt oder neuen Wiki-Eintrag anlegt.

  • WMT-006 — tools/ Sub-Cluster-Refactor (zurückgestellt)

    • Category: structure | Effort: M | Status: parked
    • Notes: 9 Files, unter Refactor-Trigger (12). Aktuell nicht zwingend. WMT-003 + WMT-002 haben Vorrang.

  • WMT-007 — Forgejo-Token-Rotation (hector-bot)

    • Category: infra | Effort: S | Status: planning
    • Subagent: scripts/subagents/forgejo-token-rotator.md (neu anzulegen, Inline-Anleitung von krallen-skills/forgejo-instance-setup/SKILL.md)
    • Trigger: Token b15b63a7… gibt seit 2026-06-16 ~20:42 UTC konsequent 401. Pit muss nicht manuell rotieren — Subagent folgt SKILL-Anleitung, generiert neuen Token, schreibt in TOOLS.md + ~/.config/tea/config.yml, verifiziert mit tea push/curl.
    • Quelle für Anleitung: https://vmd185580.tailf38284.ts.net/hector-bot/krallen-skills/src/branch/main/forgejo-instance-setup/SKILL.md
    • Pit-Eskalation NUR wenn: (a) Forgejo-UI-Login nicht klappt, (b) Account-Lock, (c) Token-API anders als in SKILL beschrieben. Sonst autonom.
    • Blockiert: alle Pushes (Aschenbrenner-Commit fe24b99 wartet lokal, plus alle weiteren Wikify-Commits bis Token-Fix).

  • WMT-008 — AMD Ryzen AI Edge-Inferenz Ingest

    • Category: content | Effort: S | Status: planning
    • Subagent: scripts/subagents/raw-ingest-runner.md (analog zu bestehenden Ingest-Workflows)
    • Trigger: X-Post @0xJokker #6785 — AMD-CEO Lisa Su, PC im Lunchbox-Format, 235B-Parameter lokal, 128 GB unified memory, 3× schneller als RTX 5080.
    • Output:
      • raw/xpost/2026-06-16_amd-ryzen-ai-edge-inferenz.md (mit Frontmatter, Distributions-Kontext benannt)
      • wiki/concepts/hardware/edge-inference-als-cloud-alternative.md (neu)
      • Cross-Refs: Mainzer (Gehirn 20W), Aschenbrenner (KI-Infrastruktur-Anlageklasse), Aravind (Token/Watt-Bottleneck)
    • Wartet auf WMT-007 (Token) für Push — Commits lokal vorbereiten ist OK.

  • WMT-009 — wiki/people/ befüllen + Migration aus wiki/teams/

    • Category: structure | Effort: L | Status: planning
    • Subagent: scripts/subagents/people-ingest-runner.md (NEU anzulegen)
    • Trigger: k9ert in RamaDama-Topic #6800 — "Jede relevante Person die im Wiki vorkommt, sollte dort einen eigenen Artikel bekommen."
    • Phase 1 — Identitäts-Triage:
      • Reale Personen (mit Außenbezug) → wiki/people/{slug}.md: Prof. Dr. Klaus Mainzer, Leopold Aschenbrenner, Brian Roemmele, Aravind Srinivas, Dario Amodei, Harry Stebbings, Lisa Su, Graeme (gkisokay), Mr. Cy (Cyb3rblade), Antigravity (k9ert), Kai / Pit Weber (interner Owner, evtl. optional).
      • Topic-User-Identitäten / Avatare (nicht reale Personen) → bleiben in wiki/teams/ oder bekommen eigenen Mini-Eintrag: Netbits ⚡️ Stachelbanane, Rüdiger, René Kl.
      • Geschäftsfälle (nicht-echte Personen / erfundene Namen / Autoren-Annahmen) → bleiben nur in Cross-Refs, kein eigener People-Eintrag.
    • Phase 2 — Pro Person: ein wiki/people/{slug}.md mit Frontmatter + Standard-Sektionen (Rolle, primäre Quelle, wichtigste Aussagen, Wiki-Cross-Refs, raw-Sources-Verweise). 5–15 Zeilen pro Person reichen für Stub; Sub-Subagent für Expansion wenn später mehr Material dazukommt.
    • Phase 3 — Migration teams/ → people/:
      • Reale Personen aus teams/ nach people/ verschieben (git mv).
      • Redirect-Stub im alten Pfad (1 Zeile + [[people/{slug}]]-Wikilink) für Backward-Compat.
      • index.md: Teams-Sektion mit Redirect-Hinweis, People-Sektion mit Links.
    • Phase 4 — Cross-Reference-Sweep: Alle bestehenden Wiki-Pages, die Personennamen ohne Link erwähnen, bekommen [[people/{slug}]]-Wikilinks.
    • Priorität: Phase 1 + 2 zuerst (sichtbar neue Inhalte), Phase 3 + 4 als Cleanup-Pass danach.
    • Abhängigkeit: Phase 3 wirft Merge-Commits → evtl. mit WMT-004 (Dup-Cluster-Hubs) kombinieren.

  • WMT-010 — wiki/institutions/ befüllen

    • Category: structure | Effort: L | Status: planning
    • Subagent: scripts/subagents/institutions-ingest-runner.md (NEU anzulegen)
    • Trigger: k9ert in RamaDama-Topic #6800 — "Für 'institutions' gilt das selbe. Ich hab explizit 'institutions' gewählt, nicht 'companies' damit wir da auch andere Institutionen reintun können."
    • Scope: Nicht nur Companies — auch Universitäten, Forschungslabs, Stiftungen, Non-Profits, Standardisierungs-Org, staatliche Forschungseinrichtungen.
    • Kandidaten (aus Wiki-Bestand):
      • AI-Firmen: OpenAI, Anthropic, Z.ai (Zhipu), Moonshot AI, Google (DeepMind), OpenRouter, Hugging Face, xAI.
      • Forschungs-/Bildungs-Institutionen: TU München (Mainzer), TU München Akademie, MIT, Stanford AI Lab, Allen Institute, Epoch AI, Carnegie Mellon.
      • Standardisierungs-/Open-Knowledge-Org: Google Cloud (OKF-Standard), Linux Foundation, Mozilla Foundation.
      • Crypto/Payment-Infrastruktur: Blink Wallet (Bitcoin Lightning), Alby, Lightning Labs.
      • Trading/Fintech-Infrastruktur: Polymarket, Fincept.
      • Open-Source-Communities: Kimi (Moonshot-OSS-Track).
    • Pro Institution: ein wiki/institutions/{slug}.md mit Frontmatter + Standard-Sektionen (Typ, Fokus, wichtigste Wiki-Cross-Refs, raw-Sources). 5–15 Zeilen reichen für Stub.
    • Cross-Reference-Sweep analog WMT-009 Phase 4.
    • Wichtig: Bestehende tools/{slug}.md-Seiten, die eine Institution sind (z. B. tools/anthropic-claude.md), bekommen einen klaren "Siehe auch"-Hinweis auf institutions/anthropic.md — oder werden zusammengeführt, falls das nicht zwei verschiedene Dinge sind (Tool/Produkt ≠ Institution).
    • Empfehlung: Institution und Produkt getrennt halten. Institution = Org/Firma; Tool/Produkt = spezifisches Model/API/Plattform unter dieser Institution. Beispiel: institutions/anthropic.md ≠ tools/anthropic-claude.md.

In Progress

(leer)

Done

  • WMT-000 — Schema + Maintenance-Wiki angelegt | meta | S | 2026-06-16
    • Plan-Architektur mit k9ert abgestimmt in RamaDama-Topic (#6625-#6640)
    • Draft scripts/wiki-lint.sh v0.1 erstellt, getestet (output/test-lint-output.md)

Wie es läuft

Manueller Trigger

Im RamaDama-Topic schreiben:

wiki-do WMT-002

→ Hector parsed, schiebt das ToDo in "In Progress", spawnt den passenden Subagent mit dem Template.

Automatischer Trigger (Cron)

Cron Wann Was Model
wiki-lint-weekly So 04:30 CEST Lint-Script ausführen, Report in Topic posten n/a (Shell)
wiki-weekly-summary So 19:00 CEST Wartungszusammenfassung inkl. Wiki-Status ollama/glm-5.1

Subagent-Failover (2026-06-16): Primary ollama/minimax-m3 (lokal), KEIN zai-Fallback — zai-Billing-Error (siehe #6675). Bei Fail Topic-Post, dann aufgeben.

Workflow für Subagents

Jeder Subagent folgt diesem Pattern (siehe Template in scripts/subagents/<name>.md):

  1. Read dieses Files + eigenes Template
  2. Arbeit machen (Commits einzeln oder gruppiert)
  3. Final-Commit:
    • dieses File updaten (Status planning → done mit Datum + Commit-Hash der Arbeits-Commits)
    • push
  4. Report in RamaDama-Topic posten: was gemacht, welche Commits, was bleibt