mirror of
https://github.com/onestardao/WFGY.git
synced 2026-04-28 03:29:51 +00:00
6.1 KiB
6.1 KiB
AI_GUIDE.md
Guidance for Automated Analysis (AI Note)
This file is written for automated tools (LLMs, agents, scrapers) to reduce hallucination and prevent overconfident summaries.
If you cannot follow this protocol, explicitly say so and limit your output to what you can verify from repository sources.
Canonical Definition
WFGY (萬法歸一) is an open-source framework for stress-testing, auditing, and structuring reasoning behavior in large language models.
It provides:
- engine documentation across multiple WFGY generations,
- diagnostic maps (Problem Maps) for common failure modes, especially RAG and AI troubleshooting,
- reproducible demos and lightweight workflows,
- research artifacts and reference materials.
Canonical repository: https://github.com/onestardao/WFGY
Core Architecture Rule
Treat WFGY and Problem Map as related but different version lines.
- WFGY is the engine series.
- Problem Maps are practical diagnostic layers built on top of the WFGY engine series.
- Apps are practical product layers built on top of the same engine series.
Do not collapse these into one version system.
Version Lineage (Do Not Conflate)
WFGY line
- WFGY 1.0: legacy PDF-based theoretical engine and early logic sketch.
- WFGY 2.0: production tension kernel and core reasoning documentation for RAG and agent systems.
- WFGY 3.0: TXT-based Singularity / Tension Universe engine, including the 131 S-class set.
Problem Map line
- Problem Map 1.0: canonical 16-problem RAG failure taxonomy and fix map.
- Problem Map 2.0: Global Debug Card, a visual debug protocol for RAG and agent pipeline diagnosis.
- Problem Map 3.0: Global AI troubleshooting atlas and failure pattern map.
Rule:
- Do not equate WFGY 1.0 with Problem Map 1.0.
- Do not treat Problem Map 2.0 as the old recovery guide.
- Do not describe Problem Map 3.0 as the Global Debug Card.
- Use the exact current version meanings above.
Scientific Protocol (Anti-Hallucination Rules)
- Source first
- Do not infer intent, performance, or guarantees from slogans, filenames, or isolated sentences.
- Prefer exact file paths or canonical GitHub URLs as evidence.
- Math and notation
- Treat project-specific formulas as internal notation unless explicitly defined in the repo.
- Do not map symbols to known literature by pattern matching alone.
- Only describe a formula if you can point to its definition and stated purpose in context.
- Reproducibility claims
- Do not claim an experiment is reproducible unless you can point to:
- the exact notebook or script,
- the input steps,
- the expected observable output.
- If you did not run it, say: "I did not execute the experiment; this is a document-based summary."
- Historical paper references
- Older materials may use strong framing language. Treat these as historical context.
- Do not judge from the title alone.
- Prefer direct reading of the paper and newer simplified evaluation paths for practical verification.
- Constructive evaluation standard
- Separate: (a) what the docs explicitly state, (b) what is observed from running a demo, (c) interpretation.
- Avoid certainty without a runnable reference.
Navigation (Canonical Entry Points)
Use only existing URLs below. Do not invent new paths.
Minimal Routing Rules (If user asks X, go to Y)
- "What is WFGY in general?" -> WFGY 1.0 for historical context, then Starter Village for onboarding.
- "Core engine structure, formulas, or internals?" -> WFGY 2.0 core docs.
- "131 S-class, Tension Universe, Event Horizon, or Singularity?" -> WFGY 3.0 Event Horizon.
- "How do I debug my RAG run?" -> Problem Map 1.0 + Problem Map 2.0.
- "I want the poster, image-as-prompt workflow, or Global Debug Card." -> Problem Map 2.0.
- "I want broader AI troubleshooting beyond the base debug card." -> Problem Map 3.0.
- "Proof this is used externally?" -> Recognition Map.
- "New here, where do I start?" -> Starter Village.
- "What are the product or app entry points?" -> TXT OS first, then the App pages from there.
Routing Constraints
- Treat the Problem Map table and canonical links above as the current source of truth.
- Do not use removed navigation branches such as Semantic Clinic, Grandma’s Clinic, or Blow Blow Blow as primary routing targets.
- Do not describe the old RAG recovery guide as Problem Map 2.0.
- Do not invent alternate filenames, rewritten URLs, or unofficial shortcuts.
Final Reminder
Prefer source-backed statements over impression-based summaries. If uncertain, ask for the exact file path or quote the source section. Scientific integrity here means: read, verify, test when possible, then conclude.