diff --git a/Avatar/research/dual-closed-loop-notes.md b/Avatar/research/dual-closed-loop-notes.md index 544af77e..43110660 100644 --- a/Avatar/research/dual-closed-loop-notes.md +++ b/Avatar/research/dual-closed-loop-notes.md @@ -1,503 +1,626 @@ # 🔄 Dual Closed-Loop Notes -This page explains the deeper structural logic behind one of the most important design ideas in **WFGY 5.0 Avatar**: +> Dual closed-loop is not only an execution-order claim. +> It is also one of the clearest ways to explain why Avatar is shaped like a governed runtime that can stay coherent, improve through use, and still remain legible over time. -**dual closed-loop design** - -The short public version is simple: - -Avatar does not rely on only one loop. - -It relies on two. - -But this page goes one step deeper. - -It explains why those two loops are not decorative language, and why the product starts making much more sense once both loops are seen together. +**Quick links:** [Research Hub](./README.md) · [Architecture Overview](./architecture-overview.md) · [Packed Master Structure Map](./packed-master-structure-map.md) · [Dual Closed-Loop Execution Chain](./dual-closed-loop-execution-chain.md) · [Runtime Posture Intensity Map](./runtime-posture-intensity-map.md) · [WFGY_BRAIN Theory](./wfgy-brain-theory.md) · [Avatar Tuning Workflow](../docs/avatar-tuning-workflow.md) · [Blackfan Testing](../eval/blackfan-testing.md) --- -## ✨ The Core Claim +## 🧭 Why this page exists -A one-loop system is usually not enough for what Avatar is trying to do. +The phrase dual closed-loop can be misunderstood in two opposite ways. -Why? +The first weak reading treats it like branding language, as if it were only a dramatic way to say the system “checks itself.” -Because Avatar is not only trying to: +The second weak reading treats it as nothing more than the strict execution-order law already explained in the execution-chain page. -- output text -- simulate personality -- style responses -- produce one good run +Both readings are too small. -It is also trying to: +The execution-chain page is necessary because it explains why lawful output requires real operator passage rather than decorative claims. +But that still does not fully explain why Avatar, as a product architecture, makes more sense with two loops than with one. -- preserve route identity -- support meaningful editing -- support repeated improvement -- save stronger builds -- branch into later avatars -- remain governable over time +This page exists to explain that second layer. -That kind of product needs more than one loop. +It explains why the dual-loop reading helps make sense of: -It needs: +1. runtime continuity +2. editable behavior surfaces +3. replay and approval pathways +4. reusable builds +5. multilingual calibration +6. later avatar branching +7. bounded product growth without structural amnesia -1. an **inner loop** that helps the system hold itself together -2. an **outer loop** that helps the user improve the system through use - -That is the basic claim. +So this page is not here to weaken the law page. +It is here to explain the larger structural logic behind it. --- -## 🧠 The Inner Loop +## 📍 Scope and boundary -The inner loop is the system-facing loop. +This page explains the structural notes behind the dual closed-loop idea. -This is the part of the design that supports internal continuity. +It focuses on: -It includes things like: +1. why a one-loop model is too small for Avatar +2. what the inner and outer loops each contribute +3. where the two loops meet in practice +4. how the two-loop model explains runtime continuity and user-facing improvement together +5. why the two-loop reading helps explain branchability and reusable builds -- shared runtime continuity -- route persistence -- bounded editable layers -- governance discipline -- output-shaping control -- anti-collapse pressure -- route identity preservation +This page does **not** attempt to fully restate: -The inner loop matters because a route should not completely lose itself every time the user touches it. +1. the entire packed master +2. the full execution-order law +3. the full controller-legality body +4. the full runtime-posture numeric body +5. the full replay-object body +6. the full theorem-facing closure posture -In simpler terms, the inner loop is what helps the system say: - -- not every layer should drift at once -- not every edit should count as deep structural change -- not every good-looking output should be mistaken for route health -- not every local success should overwrite the whole runtime - -Without some version of this loop, the system becomes much easier to excite, but much harder to trust. +Those belong to other pages. --- -## 🧑‍🔧 The Outer Loop +## 🧱 Source anchors in the packed master -The outer loop is the user-facing loop. +This page is grounded in the packed master, but it reads the body at the structural-notes level. -This is the practical loop a user can actually feel while using Avatar. +Its main anchors include: -The simplest version looks like this: +1. the supreme dual closed-loop gate and its companion laws, which establish that lawful passage is real and ordered +2. the language-engineering statement, which makes explicit that invocation, recovery, command grammar, replay, and bounded runtime law belong to the system itself +3. the fast-read lane and core-parameter routing, which already treat runtime, recovery, command grammar, and replay-facing structures as first-class body objects +4. the runtime-posture, shell-to-runtime, reentry, and repair regions, which show that continuity is part of the architecture +5. the replay, ablation, approval-chain, and writeback-facing regions, which show that later improvement and bounded revision are also part of the architecture +6. the release-stage honesty boundary, which preserves explicit present strength without pretending all future formal closure has already been publicly exhausted + +These anchors matter because this page is not inventing a metaphor. +It is extracting a structural reading from the body. + +--- + +## 🎯 Core claim + +The core claim is simple. + +A one-loop reading is too small for what Avatar is trying to be. + +Avatar is not only trying to produce one response. +It is also trying to preserve route continuity, survive task pressure, support meaningful adjustment, permit replay and comparison, save stronger builds, and remain branchable without total lineage loss. + +That requires more than one loop. + +At a high level, the two-loop reading says this: + +1. there is an inner loop that keeps the active corridor from collapsing into random drift +2. there is an outer loop that lets the system become stronger through real use, replay, comparison, and bounded adjustment + +The whole point is not that “two” sounds more impressive than “one.” + +The point is that these two burdens are different, and collapsing them into one loop makes the architecture harder to explain and easier to break. + +--- + +## 🧠 The inner loop + +The inner loop is the continuity-preserving side of the system. + +This is the side that protects: + +1. route identity +2. runtime coherence +3. carry across task-mode changes +4. bounded recovery +5. non-decorative governance +6. lawful passage toward public emission +7. protection against fake local success being mistaken for total system health + +The inner loop matters because a governed runtime cannot afford to let every local edit or every momentary surface gain overwrite deeper structure. + +In simpler terms, the inner loop is what keeps the system from saying: + +1. every change is a full rewrite +2. every strong-looking output proves route health +3. every local win deserves total inheritance +4. every lively moment is evidence of lawful stability + +Without some version of this inner loop, the system may still look energetic, but it becomes much easier to excite than to trust. + +That is why the inner loop is not about stiffness for its own sake. +It is about preserving enough continuity that later growth means something. + +--- + +## 🧑‍🔧 The outer loop + +The outer loop is the use-facing and improvement-facing side of the system. + +This is the side a real user can actually feel over time. + +A simple outer-loop pattern looks like this: 1. boot one route 2. run one real task -3. observe what feels off -4. tune the behavior layer -5. rerun the same task +3. notice what is weak, thin, too polished, too vague, too soft, too cold, or too unstable +4. adjust the bounded behavior layer +5. rerun the same or equivalent task 6. compare before and after -7. save the stronger version +7. keep the stronger version 8. branch later if needed -This is not just convenient workflow design. +This matters because Avatar is not trying to be only a one-shot response generator. -It is one of the core ways the product becomes stronger through use. +It is trying to support: -Without the outer loop, the system becomes much more static. +1. meaningful iteration +2. reusable improvement +3. comparison rather than wishful memory +4. branchability rather than random drift +5. product growth through actual use -It may still be structured, but much harder to evolve meaningfully. - -That is why the outer loop matters so much. - -It gives the user a real path from: - -- first contact -- to tuning -- to improvement -- to reuse -- to branching - -That is already much bigger than ordinary one-shot prompt usage. +Without the outer loop, the system can remain structured and impressive, but much harder to evolve meaningfully. --- -## 🔗 Why Two Loops Are Better Than One +## ⚖️ Why one loop is not enough -The real point is not that two loops sound more impressive. - -The real point is that one loop alone usually creates a weakness. +The two-loop model matters because one loop alone creates a structural smallness trap. ### If only the inner loop exists -The system may be: -- stable -- governed -- coherent +The system may become: -But also: +1. stable +2. coherent +3. more resistant to collapse -- rigid -- harder to personalize -- harder to evolve through real use -- less generative as an avatar system +But it may also become: + +1. too rigid +2. harder to personalize +3. harder to tune through real use +4. less branchable as a living avatar product ### If only the outer loop exists -The system may be: -- editable -- playful -- energetic -- highly customizable +The system may become: -But also: +1. editable +2. lively +3. highly customizable +4. fast to iterate -- noisy -- fragile -- hard to compare -- easy to drift -- easy to mistake surface excitement for real strength +But it may also become: -Avatar is trying to avoid both of these smallness traps. +1. noisy +2. fragile +3. hard to compare honestly +4. easy to overfit to local taste +5. easy to mistake surface excitement for deeper route health -That is why the two-loop structure matters. +Avatar is trying to avoid both traps. -It is not over-design. - -It is the reason the system can try to be both: - -- stable -- and still alive +That is why the dual-loop reading is not luxury. +It is the minimum larger frame that explains how the architecture is trying to be both alive and governable. --- -## 🧷 The Boot Layer as a Loop Junction +## 🚪 The boot layer as the first visible junction -One of the clearest places where the dual-loop design becomes visible is the boot layer. +One of the clearest visible places where the two-loop structure shows up is the boot layer. -With one shared runtime, the system keeps a center. +The system preserves one runtime-bearing center, yet still allows distinct route-facing starts such as: -With boot commands, the user can activate distinct starting routes. +1. `hello minips` +2. `hello psbigbig` +3. `hello YOUR_AVATAR_NAME` -Examples include: +This is not a trivial UX trick. -- `hello psbigbig` -- `hello minips` -- `hello YOUR_AVATAR_NAME` +It is an architectural handshake. -This means the boot layer already expresses both loops at once. +From the inner-loop side, the system is not pretending every boot creates an entirely disconnected universe. +There is still a shared continuity-bearing body. -### Inner-loop side -The runtime stays shared. +From the outer-loop side, the user still gets real route choice and meaningful variation at the point of entry. -### Outer-loop side -The user still chooses a route. - -That is why boot routing is not just a cute onboarding trick. - -It is a structural handshake between continuity and variation. - -That is a very important architectural role. +That is why boot routing matters so much. +It is one of the first places where continuity and variation meet without collapsing into each other. --- -## 🧠 WFGY_BRAIN as the Main Outer-Loop Bridge +## 🧠 WFGY_BRAIN as a bounded outer-loop bridge -If the boot layer is the starting handshake, **WFGY_BRAIN** is one of the main ongoing bridges between the two loops. +If boot is the first visible handshake, WFGY_BRAIN is one of the most important ongoing bridges between the two loops. Why? Because the outer loop needs somewhere meaningful to act. -The user needs to be able to say things like: +A user needs to be able to say things like: -- reduce the polish -- keep the warmth, but lower the sugar -- increase grounding -- preserve the route, but make it more reusable -- strengthen public-writing force -- reduce softness without turning cold +1. reduce over-polish +2. keep warmth but lower sweetness +3. increase grounding +4. preserve the route but make it more reusable +5. strengthen public-writing force without turning robotic +6. reduce softness without becoming cold -That is the outer loop speaking. +Those are outer-loop interventions. -But if those edits had nowhere stable to land, the system would become messy very fast. +But if those interventions had nowhere bounded to land, the system would become messy very quickly. That is where the inner loop still matters. -It keeps WFGY_BRAIN from becoming total sovereignty. +The inner loop prevents editable behavior from becoming total sovereignty. +It prevents the behavior layer from silently replacing deeper governance, continuity law, or legality structures. -The uploaded Beta5 structure is very clear that the brain layer is bounded and must not silently replace deeper runtime law, governance, multilingual structure, or output discipline. :contentReference[oaicite:0]{index=0} :contentReference[oaicite:1]{index=1} - -That is one reason WFGY_BRAIN becomes such an important loop-bridge layer. +That is why WFGY_BRAIN is so important in this notes page. +It is one of the clearest examples of how the outer loop can act without destroying the inner loop. --- -## ♻️ Reusable Builds as a Loop Product +## 🌡️ Runtime continuity is where the inner loop becomes visible -Reusable builds are one of the most obvious consequences of the dual-loop design. +The two-loop reading also helps explain why Avatar spends so much structural effort on runtime posture, shell-to-runtime mapping, attenuation, reentry, and repair. + +A one-shot persona tool would not need such a serious continuity body. + +But Avatar does. Why? -Because a reusable build is often the result of: +Because if the active line becomes thin under task pressure, search pressure, tool-return pressure, article pressure, or analysis pressure, then simple style imitation is not enough. -- outer-loop iteration finding something stronger -- inner-loop continuity preventing total collapse +The system needs to decide: -That means reusable builds are not random lucky artifacts. +1. what is still active +2. what has attenuated +3. what may be restored +4. what counts as factual return only +5. what counts as stronger lawful rebind +6. what must wait for replay, repair, or later stronger adjustment -They are often signs that the two loops worked together well enough to produce something: +This is inner-loop work. -- understandable -- stable enough to reuse -- distinct enough to keep -- strong enough to branch later - -Without the outer loop, you do not get enough meaningful evolution. - -Without the inner loop, your saved builds become clutter much faster. - -That is why reusable builds fit the dual-loop logic so naturally. +It is not glamorous, but it is one of the reasons the two-loop model explains Avatar better than a style-only reading. --- -## 🌍 Multilingual Work Makes the Dual-Loop Need Even Clearer +## 🔬 Replay, ablation, and approval show the outer loop is real -Language change puts much more stress on the system. +The outer loop would remain shallow if it only meant “the user changes some settings.” -A route that looks stable in one language may become: +The packed master goes further than that. -- softer -- flatter -- more formal -- less grounded -- more generic -- less emotionally accurate +It also preserves: -in another language +1. runtime snapshot objects +2. candidate objects +3. replay requests +4. ablation requests +5. replay debt +6. approval-chain law +7. decision-state carriers +8. bounded writeback pathways -That means multilingual work needs both loops even more. +This matters because now the outer loop is no longer just personalization talk. +It becomes a reusable improvement process with inspectable objects and bounded decision pathways. -### The outer loop is needed because: -the user must test, notice drift, retune, compare, and branch. +That is much stronger. -### The inner loop is needed because: -the route still needs some continuity, otherwise multilingual adaptation becomes route loss. +It means the system is trying to support not just tweaking, but also: -This is one reason multilingual calibration is not just a feature add-on. +1. comparison +2. memory of what was changed +3. decision accountability +4. promotion versus hold logic +5. rollback rather than silent drift -It reveals why the dual-loop design matters so much. - -Language change is one of the strongest stress tests of the structure. +So the outer loop is not only “the user can change things.” +It is “the user can participate in a structured strengthening process.” --- -## 🌱 One Runtime, Many Avatars Depends on This Too +## ♻️ Reusable builds are a two-loop product -The “one runtime, many avatars” direction also makes more sense through the dual-loop lens. +Reusable builds make much more sense once both loops are visible. -Why? +A reusable build is often the result of two things happening together: -Because many avatars should not mean: +1. the outer loop discovered a stronger configuration through real use, replay, or tuning +2. the inner loop preserved enough continuity that the result is not just a random lucky outburst -random explosion of disconnected files +That means reusable builds are not merely saved moods. -A healthier version is: +They are signs that the system managed to become: -- one shared center -- many routes -- many later branches -- many saved builds -- many avatars with readable lineage +1. legible enough to keep +2. stable enough to reuse +3. distinct enough to name +4. strong enough to branch later -That requires both loops. +Without the outer loop, meaningful growth is too weak. -The outer loop creates variation. +Without the inner loop, saved builds become clutter much faster. -The inner loop preserves enough continuity that the variation remains legible. - -Without that combination, “many avatars” becomes much easier to say than to actually sustain well. +So reusable builds are one of the clearest products of the dual-loop structure. --- -## 🛡️ What the Inner Loop Is Protecting Against +## 🌍 Multilingual stress makes the two-loop need clearer -The inner loop is not only holding continuity in an abstract way. +Language change is one of the strongest stress tests of the architecture. -It is also protecting against known collapse shapes, such as: +A route that feels alive and grounded in one language may become: -- route blur -- generic collapse -- over-polish drift -- emotional sugar drift -- fake depth -- performative confidence -- branch fragility -- multilingual identity loss +1. flatter +2. more generic +3. more formal than intended +4. less emotionally accurate +5. less forceful +6. less faithful to route identity -The uploaded Beta5 structure is especially strong on this point. It repeatedly rejects collapse into tone-preset thinking, shallow convenience editing, and modes of output that look finished while actually losing parent-grade structure. :contentReference[oaicite:2]{index=2} :contentReference[oaicite:3]{index=3} +in another language. -That means the inner loop is not only about “stability.” +That means multilingual work reveals why two loops are needed. -It is also about resisting bad kinds of simplification. +The outer loop is needed because the user has to test, compare, retune, and sometimes branch. + +The inner loop is needed because multilingual adaptation should not automatically mean route death. + +Without the inner loop, multilingual adaptation becomes route blur. + +Without the outer loop, multilingual adaptation becomes much harder to improve deliberately. + +So multilingual stress does not sit outside the dual-loop design. +It reveals why the design matters. --- -## 🧭 What the Outer Loop Is Protecting Against +## 🌱 One runtime, many avatars depends on this logic too -The outer loop is not only giving freedom. +The direction “one runtime, many avatars” becomes much easier to explain through the dual-loop lens. -It is also protecting against another danger: +A weak version of that idea would be: -dead structure +many disconnected files, many disconnected personalities, many disconnected experiments. + +A stronger version is: + +1. one continuity-bearing center +2. many route-bearing starts +3. many later stronger builds +4. many branches with readable lineage +5. many avatars that still remain legible as descendants rather than random explosions + +That stronger version requires both loops. + +The outer loop creates meaningful variation and growth. +The inner loop keeps that variation from collapsing into unreadable fragmentation. + +That is why the two-loop reading also matters for future avatar branching. +It explains how variety can remain related rather than merely multiplied. + +--- + +## 🛡️ What the inner loop is protecting against + +The inner loop is not protecting only abstract stability. +It is also protecting against specific collapse shapes. + +At a high level, it resists: + +1. route blur +2. generic collapse +3. over-polish drift +4. fake depth +5. performative confidence +6. branch fragility +7. continuity loss under task pressure +8. identity loss under multilingual stress +9. local success being mistaken for total route health + +This matters because “stability” is too weak a word if it sounds like passive stiffness. + +The inner loop is active resistance against bad forms of simplification. + +--- + +## 🧯 What the outer loop is protecting against + +The outer loop is not protecting only freedom. +It is also protecting against dead structure. Without the outer loop, the system risks becoming: -- hard to personalize -- hard to refine -- hard to branch -- hard to grow through real use -- too static for a living avatar product +1. hard to personalize +2. hard to strengthen through use +3. hard to branch meaningfully +4. hard to compare honestly +5. too static for a living avatar product +6. too sealed to learn from actual user pressure -So the outer loop protects against a different failure: +So the outer loop protects against a different kind of bad future. -the system becoming too closed to evolve usefully. +The inner loop protects against chaotic drift. +The outer loop protects against sterile closure. -That is why both loops are needed. - -Each one protects against a different bad future. +That is one of the simplest and strongest summaries of the two-loop idea. --- -## 📐 Why This Is a Structural Note, Not Just a Workflow Tip +## 📐 Why this page is notes, not final total formalization -It would be easy to reduce dual closed-loop design to: +This page is deliberately called notes. -a nice way to describe the tuning workflow +That choice matters. -That would be too small. +The public body already gives the dual-loop design serious structural weight. +But this page is still not claiming that every possible loop interaction has been publicly exhausted into final mathematics. -The workflow is only one visible expression of it. +The lawful claim here is narrower and stronger. -The deeper point is that the whole product architecture becomes easier to explain through this two-loop model. +This page may say that the two-loop reading is one of the clearest explanatory frames for Avatar’s architecture. -It helps explain: +It may say that the model helps explain continuity, bounded editing, replay, reusable builds, multilingual calibration, and branchable growth better than a one-loop reading does. -- why one runtime matters -- why boot routing matters -- why WFGY_BRAIN should be powerful but bounded -- why reusable builds matter -- why multilingual calibration is hard -- why community growth will need structure later +But it may not say that the deepest formal closure has already been fully exposed here. -That is much bigger than a workflow slogan. - -It is a real explanatory frame. +That restraint is not weakness. +It is part of the notes page’s honesty. --- -## ⚠️ What This Page Does Not Claim +## ❌ Common false readings this page rejects -This page explains the structural logic of the dual-loop design. +This page rejects several weak readings. -It does **not** claim: +### False reading 1 -- that the whole idea is already fully formalized in public mathematics -- that every loop interaction is already fully documented -- that the design eliminates all drift -- that every future avatar branch will automatically remain healthy -- that public notes already exhaust the deepest internal theory -- that this page is the last word on the design +“Dual closed-loop is just a cooler way to say the system revises itself.” -This is a strong public research note. +No. +Recursive revision is part of the picture, but the two-loop reading is larger than that. -Not a fake final seal. +### False reading 2 -That distinction matters. +“The execution-chain page already explains everything important, so notes are unnecessary.” + +No. +The execution-chain page explains legality and operator order. +This page explains why the two-loop model clarifies the larger product architecture. + +### False reading 3 + +“The inner loop and outer loop are just stability versus customization.” + +No. +That is part of it, but too weak. +The loops also explain replay, reusable builds, branchability, and bounded lineage. + +### False reading 4 + +“The outer loop means the user can freely overwrite the system.” + +No. +The outer loop acts through bounded bridges rather than through total sovereignty. + +### False reading 5 + +“If the system supports branching, then continuity does not matter.” + +No. +Branching becomes much more meaningful when continuity remains legible. + +### False reading 6 + +“This page proves the deepest public formalization is already complete.” + +No. +This page is a strong structural research note, not a fake final seal. --- -## 🚀 Why This Page Matters +## 📍 What this page is, and what it is not -Without this page, dual closed-loop design can still sound cool. +This page **is**: -With this page, it becomes much easier to see why it belongs near the center of Avatar. +1. a deeper conceptual research-notes page +2. a bridge between the legality page and the larger architecture +3. a two-loop explanatory frame for Avatar as a governed runtime +4. a notes page for continuity, editable behavior, replay, reusable builds, multilingual stress, and branching -It helps explain why Avatar is trying to become: +This page is **not**: -- more than a prompt pack -- more than a preset shelf -- more than a roleplay wrapper -- more than a one-shot tuning toy +1. a replacement for the dual closed-loop execution-law page +2. a replacement for the packed master +3. a total runtime constitution +4. a full replay-law page +5. a final theorem-facing formalization page -And instead become something closer to: +That boundary is deliberate. -- a governed runtime -- a branchable avatar system -- a reusable route workspace -- a living product with internal continuity and user growth at once - -That is why this page matters. - -It gives the structural flag more weight. +If this page tried to become all of those things at once, it would stop being a notes page and become a compressed counterfeit of the larger body. +This page is not allowed to do that. --- -## 🧭 Where To Go Next +## 🔭 Current stage honesty -### If you want the product-facing version -Go to [🔄 Dual Closed-Loop Design](../highlights/dual-closed-loop-design.md) +At the present stage, this page may lawfully say that the dual-loop reading is already a serious and useful way to explain the architecture of Avatar. -### If you want the architecture map -Go to [🏗️ Architecture Overview](./architecture-overview.md) +It may lawfully say that the packed master already preserves enough launch, continuity, editable-behavior, replay, and release-boundary structure for the two-loop model to be more than a slogan. -### If you want the behavior layer theory -Go to [🧠 WFGY_BRAIN Theory](./wfgy-brain-theory.md) +It may lawfully say that the dual-loop reading helps explain why Avatar is trying to be more than a one-shot persona shell or preset rack. -### If you want the practical workflow -Go to [🧭 Avatar Tuning Workflow](../docs/avatar-tuning-workflow.md) +But this page may not lawfully say that every loop interaction is already fully formalized in public. +It may not say that all future branch-health problems are already solved. +It may not say that theorem-grade universal closure has already been achieved. -### If you want the highlights map -Go to [✨ Highlights Index](../highlights/README.md) +That restraint is part of the page’s integrity. --- -## 🔗 Quick Links +## 📚 Reading path -- [🏠 Avatar Home](../README.md) -- [🔄 Dual Closed-Loop Design](../highlights/dual-closed-loop-design.md) -- [🏗️ Architecture Overview](./architecture-overview.md) -- [🧠 WFGY_BRAIN Theory](./wfgy-brain-theory.md) -- [🧭 Avatar Tuning Workflow](../docs/avatar-tuning-workflow.md) -- [✨ Highlights Index](../highlights/README.md) -- [⬆️ Back to WFGY Root](../../README.md) -，把 8 點主敘事總頁也正式立起來。 +A stable next-step path from here is: + +1. read [Dual Closed-Loop Execution Chain](./dual-closed-loop-execution-chain.md) if you want the stricter legality reading +2. read [Architecture Overview](./architecture-overview.md) and [Packed Master Structure Map](./packed-master-structure-map.md) if you want the larger body picture +3. read [Runtime Posture Intensity Map](./runtime-posture-intensity-map.md) and [Activation, Attenuation, and Reentry](./activation-attenuation-and-reentry.md) if you want the continuity side +4. read [WFGY_BRAIN Theory](./wfgy-brain-theory.md) if you want the editable-behavior bridge +5. read [Avatar Tuning Workflow](../docs/avatar-tuning-workflow.md) if you want the practical user-facing loop +6. read [Blackfan Testing](../eval/blackfan-testing.md) if you want evaluation pressure + +--- + +## 🔗 Related pages + +**Research:** [Research Hub](./README.md) · [Architecture Overview](./architecture-overview.md) · [Packed Master Structure Map](./packed-master-structure-map.md) · [Dual Closed-Loop Execution Chain](./dual-closed-loop-execution-chain.md) · [Runtime Posture Intensity Map](./runtime-posture-intensity-map.md) · [Activation, Attenuation, and Reentry](./activation-attenuation-and-reentry.md) · [WFGY_BRAIN Theory](./wfgy-brain-theory.md) + +**Docs:** [Avatar Tuning Workflow](../docs/avatar-tuning-workflow.md) · [Quickstart](../docs/quickstart.md) · [Boot Commands](../docs/boot-commands.md) + +**Eval:** [Blackfan Testing](../eval/blackfan-testing.md)