16 KiB
📘 Docs Hub
This page is the docs hub for WFGY 5.0 Avatar.
Avatar is not only a concept surface and not only a research body.
People also need to know:
- how to start
- how to boot
- how to read the master correctly
- how to tune bounded controls
- how to recover after drift
- how to move from first use into deeper branch work
That is what this Docs layer is for.
The Docs layer exists so the project can stay usable without forcing every reader to begin from the deepest research page or the heaviest packed-master section.
It is the operational entry layer of the Avatar branch.
✨ Why this layer exists
The Docs layer answers practical questions like:
- how do I enter Avatar
- which commands should I use
- how should I read the master file
- how do I tune the current branch
- how do I recover after drift or thinning
- where should I go next after startup
That is different from what the other layers do.
The Research layer answers deeper structural questions like:
- what counts as execution
- what counts as route law
- what counts as runtime carry
- why structured imperfection matters
- what happens before public emission
- how matrix accountability and audit burden work
The Eval layer answers pressure questions like:
- what breaks under hostile reading
- what remains stable under real use
- what behavior should or should not receive credit
- how multilingual status is being stated honestly
So the Docs layer is where operation becomes legible.
It does not replace the deeper body.
It makes the deeper body usable.
🧭 How to use this hub
Use this hub in one of five ways.
1. I want to start quickly
Start here if your main question is:
- what is Avatar
- how do I boot it
- what should I type first
Read in this order:
This is the best route for first-time entry.
2. I want to understand how to read the master file
Start here if your main question is:
- where do I begin
- what order should I read different sections in
- how do I avoid getting lost in a large one-file system
- how does reading order change for article-grade tasks
Read:
This is the best route when your problem is not usage only, but lawful reading.
3. I want to tune the current branch
Start here if your main question is:
- which knobs matter
- what should be tuned first
- how do I compare profiles safely
- how do I diagnose too-flat, too-clean, too-generic, or too-aggressive behavior
Read:
This is the best route for bounded calibration and branch steering.
4. I want to recover a persona after drift
Start here if your main question is:
- what does
avatar++do - when should I use
avatar++ reload - what is the difference between recovery and re-booting
- how do I tell if recovery actually worked
Read:
This is the best route when continuity weakened after article, analysis, rewrite, search, or tool pressure.
5. I want to go deeper after Docs
Start here if your main question is no longer “how do I use it,” but instead:
- what is actually happening underneath
- how does execution work
- what is runtime law
- what is selector law
- how is the packed master structured
Go to:
Docs gets you into the branch.
Research and Eval tell you what that branch is actually doing and whether it survives pressure.
🧱 What belongs in the Docs layer
The Docs layer is where operational guidance lives.
Typical Docs-layer questions include:
- how do I start
- how do I boot a persona
- how do I avoid false-trigger mistakes
- how do I read the master file correctly
- how do I tune the current controls
- how do I recover after drift
- where do I go when I need more than startup help
This layer should stay clear, practical, and route-aware.
It should not try to restate the entire research body.
It should not try to replace evaluation pressure.
It should not pretend a few instructions equal the whole system.
That restraint is what keeps Docs useful.
🧠 Current docs surfaces
The current Docs layer is organized into five major surfaces.
1. Startup surface
These pages help the reader begin.
Use these when the question is:
- how do I start
- what do I type
- what are the valid command families
- how do I enter without guesswork
2. Reading surface
This page helps the reader approach the packed master correctly.
Use this when the question is:
- where should I begin reading
- what reading order should different reader types use
- how does article-mode reading differ from casual reading
- how do I avoid flattening the file into one giant prompt
3. Tuning surface
These pages help the reader steer bounded controls without turning tuning into random knob superstition.
Use these when the question is:
- which family should I tune first
- how do I compare baseline, standard, and strong
- how do I tune without damaging lawful floors
- how do I move from diagnosis to bounded comparison
4. Recovery surface
This page helps the reader restore continuity after drift, thinning, or over-cleaning.
Use this when the question is:
- when should I use
avatar++ - when should I use
avatar++ reload - what does
avatar releaseactually do - how do I know whether recovery was real or only cosmetic
5. Cross-layer routing surface
This hub itself is part of the operational routing layer.
Use this when the question is:
- what Docs page should I open next
- where should I go after startup
- when should I jump from Docs into Research or Eval
🪜 Suggested docs paths
Path A: complete newcomer path
Use this if you are starting from zero.
This path gives you:
- first entry
- command clarity
- lawful reading order
Path B: startup plus recovery path
Use this if you can already start Avatar but want to recover it when it thins.
This path gives you:
- valid boot and recovery grammar
- boundary between boot and recovery
- reading discipline after drift
Path C: tuning path
Use this if the system is working but you want to steer it more precisely.
This path gives you:
- symptom-first tuning
- profile comparison discipline
- recovery-aware tuning
Path D: docs to research path
Use this if Docs answered the operational layer and you now want deeper understanding.
- 📖 How to Read the Avatar Master File
- 🔬 Research Hub
- 🗺️ Packed Master Structure Map
- 🔁 Dual Closed-Loop Execution Chain
This path is best when you want to move from usage to structure.
Path E: docs to eval path
Use this if Docs helped you operate the branch, but now you want to inspect whether it actually held under pressure.
This path is best when you want to move from operation to inspection.
🔍 Why docs and research are different
This distinction matters.
The Docs layer answers:
- how to start
- how to read
- how to tune
- how to recover
The Research layer answers:
- what the packed master is
- what counts as execution
- what the selector actually selects
- what runtime posture actually controls
- why structured imperfection is a retention law
- how matrix accountability and blackfan audit work
So:
- Docs tell you how to operate
- Research tells you how to understand
Both matter.
They are not the same thing.
🔍 Why docs and eval are different
This distinction matters too.
The Docs layer helps you do things.
The Eval layer helps you judge whether the current branch held up under pressure.
For example:
-
Docs explain how to recover
-
Eval checks whether recovery actually deserves credit
-
Docs explain how to tune
-
Eval checks whether tuning made the branch stronger or only prettier
-
Docs explain how to start
-
Eval checks whether startup clarity survives real branch use
So:
- Docs are operational
- Eval is inspectable pressure
That separation keeps the branch honest.
🌱 What this layer should become over time
As Avatar grows, Docs will likely need to keep getting clearer, not just longer.
A good Docs layer should continue to do three things well:
- reduce startup friction
- reduce misreading
- reduce bad tuning and bad recovery habits
That means future Docs growth should stay disciplined.
New Docs pages should exist because they solve a real operational problem, not because more pages feel more complete.
This is important.
A branch can become unreadable through documentation sprawl just as easily as it can through theory sprawl.
So Docs growth should remain task-driven.
⚠️ What this hub does not claim
This hub does not claim:
- that all future Docs pages already exist
- that Docs alone are enough to understand the whole project
- that current Docs already replace the packed master
- that current Docs already cover every future branch workflow
- that current branch ergonomics are universally final
- that Docs pages remove the need for Research or Eval
This hub is a bounded operational center.
That is exactly what it should be.
🚀 Where to go next
If you want public entry
Go to ✨ Avatar Home
If you want startup
Go to ⚡ Quickstart
If you want command syntax
Go to ⌨️ Boot Commands
If you want lawful reading order
Go to 📖 How to Read the Avatar Master File
If you want tuning
Go to 🍳 Parameter Tuning Cookbook
If you want recovery
Go to 🔧 Persona Recovery Operations
If you want deeper structure
Go to 🔬 Research Hub
If you want pressure and inspection
Go to 🧪 Eval Hub
🔗 Quick Links
Docs core
- ⚡ Quickstart
- ⌨️ Boot Commands
- 📖 How to Read the Avatar Master File
- 🍳 Parameter Tuning Cookbook
- 🔧 Persona Recovery Operations
- 🛠️ Avatar Tuning Workflow
Product and layer hubs
Research
- 🗺️ Packed Master Structure Map
- 🚪 Launchpad, Front Door, and Command Grammar
- 🔁 Dual Closed-Loop Execution Chain
- 🎛️ Runtime Posture Intensity Map
- 🧩 Shell-to-Runtime Mapping
- 🧭 Selector Execution Domain
- 🔄 Activation, Attenuation, and Reentry
- 🧬 Structured Imperfection Theory
- 🚦 Pre-Emission Floor and Hard Control
- 🧮 Matrix Accountability and Numeric Binding
- 🧪 Blackfan Audit Baseline
- ✂️ Compression and Non-Duplication Law