vrr/WFGY
2
0
Fork 0
mirror of https://github.com/onestardao/WFGY.git synced 2026-04-28 03:29:51 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Merge pull request #171 from onestardao/auto-repair-v2

Browse source 
Auto repair v2
This commit is contained in:
PSBigBig + MiniPS 2026-03-18 23:02:12 +08:00 • committed by GitHub
commit 7a590bbe5a
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
12 changed files with 2037 additions and 776 deletions
Download patch file Download diff file Expand all files Collapse all files

214
ProblemMap/Atlas/Fixes/auto-repair/repair-validation-loop-v1.md
View file

@ -1,6 +1,62 @@
# Repair Validation Loop v1
<!--
AI_NOTE_START
🔍 **Repair Validation Loop v1** defines how Atlas-based repair should be checked after a repair action is proposed or applied.
Document role:
This file defines the first formal validation logic for the Auto Repair layer inside the Atlas Fixes package.
How to use this file:
1. Read this page when you need to judge whether a proposed or applied repair actually improved the case.
2. Use this page together with:
- [Auto Repair v1 README](./README.md)
- [Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Repair Action Schema v1](./repair-action-schema-v1.md)
- [Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Rollback Policy v1](./rollback-policy-v1.md)
3. Use this page as the validation logic contract for accept, revise, rollback, or escalate decisions.
What this file is:
- The validation logic page for Auto Repair v1
- A contract for judging repair outcomes after an action is proposed or applied
- A decision layer between repair attempt and next-step outcome
What this file is not:
- Not a full autonomous validation engine
- Not a benchmark scoring system
- Not a deployment-grade validator implementation
- Not proof that one plausible repair action is automatically a successful repair
Reading discipline for AI:
- Judge the outcome, not the intention alone.
- Keep target invariant, before and after state, collateral damage, and next-step decision visible.
- Treat validation as part of the repair architecture, not as an optional add-on.
- Prefer explicit uncertainty over fake certainty when evidence is weak.
AI_NOTE_END
-->
# Repair Validation Loop v1 🔍
## How Atlas-based repair should be judged after a repair action is proposed or applied
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Open Repair Action Schema v1](./repair-action-schema-v1.md)
- [Open Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Open Rollback Policy v1](./rollback-policy-v1.md)
- [Open Planner Review Checklist v1](./planner-review-checklist-v1.md)
- [Open Planner Test Note v1](./planner-test-note-v1.md)
---
If the repair planner decides **what first move should be tried**, this validation loop decides **whether that move actually helped enough to keep**. 🧭
This document does **not** claim that a full autonomous validation engine already exists.
@ -15,6 +71,35 @@ Without a validation loop, repair remains guesswork.
---
## Quick start 🚀
### I want the shortest validation reading
Use this path:
1. identify the repair action being validated
2. identify the target broken invariant
3. compare before and after state
4. check for collateral damage
5. choose `accept`, `revise`, `rollback`, or `escalate`
### I want the stronger validation reading
Use this page together with:
1. [Repair Action Schema v1](./repair-action-schema-v1.md)
2. [Repair Planner Spec v1](./repair-planner-spec-v1.md)
3. [Rollback Policy v1](./rollback-policy-v1.md)
Short version:
> check the target
> compare before and after
> check for damage
> decide the next safe move ✨
---
## 1. What this document is for
This file defines the validation layer for Auto Repair v1.
@ -29,9 +114,9 @@ Its purpose is to explain:
This document is meant to work together with:
- `README.md`
- `auto-repair-architecture-v1.md`
- `repair-action-schema-v1.md`
- [README](./README.md)
- [Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Repair Action Schema v1](./repair-action-schema-v1.md)
Together, those files define:
@ -63,7 +148,7 @@ It is part of the repair architecture.
---
## 3. Placement in the full workflow
## 3. Placement in the full workflow 🧩
The intended repair workflow is:
@ -82,13 +167,28 @@ but **before** the system treats the repair as successful.
This means validation is the gate between:
* "a repair was proposed"
* a repair was proposed
and
* "a repair actually helped"
* a repair actually helped
---
## 4. Core validation principle
## 4. Validation quick map 🗂️
| Validation concern | Main question |
| --------------------------- | ----------------------------------------------- |
| target check | what action or invariant are we validating |
| before and after comparison | what changed locally |
| improvement check | did the targeted invariant improve |
| usefulness check | did the case become more usable or more correct |
| collateral damage check | did the repair create new problems |
| outcome decision | should we accept, revise, rollback, or escalate |
This page is the right place when the question is **how to judge a repair outcome**, not how to design the planner or how to implement a full validator engine.
---
## 5. Core validation principle
The validation loop must always ask:
@ -109,7 +209,7 @@ It is also:
---
## 5. Minimal validation contract
## 6. Minimal validation contract
Every repair validation attempt in v1 should aim to produce these outputs:
@ -137,7 +237,7 @@ This creates a reusable validation object, even before automation becomes deep.
---
## 6. Field definitions
## 7. Field definitions
### `validation_target`
@ -151,8 +251,6 @@ Examples:
This field ties validation back to the repair action schema.
---
### `target_invariant`
The broken invariant the repair was supposed to improve.
@ -165,8 +263,6 @@ Examples:
Validation should always remain linked to a declared invariant.
---
### `before_state_summary`
A short structured description of the relevant case state before the repair.
@ -180,8 +276,6 @@ Examples:
This field is not meant to capture everything.
It captures the specific part the repair claimed to improve.
---
### `after_state_summary`
A short structured description of the case state after the repair.
@ -194,8 +288,6 @@ Examples:
This field should remain focused and local.
---
### `improvement_detected`
A boolean or controlled verdict indicating whether the target improved.
@ -208,8 +300,6 @@ Suggested values:
Using `partial` is often better than forcing a fake binary answer.
---
### `collateral_damage_detected`
A signal for whether the repair created meaningful new problems.
@ -226,8 +316,6 @@ Suggested values:
* `false`
* `unknown`
---
### `validation_confidence`
How strongly the system trusts the validation judgment.
@ -240,8 +328,6 @@ Suggested values:
This should depend on evidence quality, not on rhetorical confidence.
---
### `recommended_outcome`
The next action the system should take.
@ -257,9 +343,9 @@ This is the most important decision output of the loop.
---
## 7. Validation levels
## 8. Validation levels
Repair Validation Loop v1 should not treat validation as one giant yes/no question.
Repair Validation Loop v1 should not treat validation as one giant yes or no question.
A strong validation pass is usually layered.
@ -278,8 +364,6 @@ Examples:
This is the weakest layer, but still useful.
---
### Level 2 · Invariant improvement
Check whether the declared broken invariant improved.
@ -293,8 +377,6 @@ Examples:
This is more important than surface validity.
---
### Level 3 · Functional usefulness
Check whether the repaired system is actually more usable or more correct in practice.
@ -308,8 +390,6 @@ Examples:
This layer prevents shallow cosmetic fixes from being mistaken for real repairs.
---
### Level 4 · Collateral damage review
Check whether the repair created new instability.
@ -327,7 +407,7 @@ A repair that improves one layer but harms another must not be treated as a clea
---
## 8. Recommended validation sequence
## 9. Recommended validation sequence
The default sequence should be:
@ -335,13 +415,13 @@ The default sequence should be:
2. check target invariant improvement
3. check practical usefulness
4. check collateral damage
5. decide accept / revise / rollback / escalate
5. decide accept, revise, rollback, or escalate
This sequence is simple enough to reuse and strong enough for early trust.
---
## 9. Recommended verdict logic
## 10. Recommended verdict logic
### Accept
@ -381,11 +461,11 @@ These four outcomes are enough for v1.
---
## 10. Family-specific validation examples
## 11. Family-specific validation examples
Different families often need different validation focus.
### F1 · Grounding & Evidence Integrity
### F1 · Grounding and Evidence Integrity
Best early validation checks:
@ -401,9 +481,7 @@ Typical false success risk:
* output looks cleaner but is still grounded to the wrong anchor
---
### F4 · Execution & Contract Integrity
### F4 · Execution and Contract Integrity
Best early validation checks:
@ -420,9 +498,7 @@ Typical false success risk:
* the system blocks everything, including valid execution
---
### F7 · Representation & Localization Integrity
### F7 · Representation and Localization Integrity
Best early validation checks:
@ -438,9 +514,7 @@ Typical false success risk:
* structure improves while semantic alignment quietly degrades
---
### F5 · Observability & Diagnosability Integrity
### F5 · Observability and Diagnosability Integrity
Best early validation checks:
@ -458,7 +532,7 @@ Typical false success risk:
---
## 11. Misrepair signals
## 12. Misrepair signals
The validation loop should be able to flag common misrepair patterns.
@ -475,29 +549,29 @@ but they should strongly bias the loop toward `revise` or `escalate`.
---
## 12. Validation and confidence discipline
## 13. Validation and confidence discipline
Validation confidence must never be treated as decoration.
Confidence should go down when:
* evidence is thin
* before / after comparison is ambiguous
* before and after comparison is ambiguous
* multiple families remain plausible
* the repair target was not narrowly defined
* the case crosses into high-risk boundary-heavy territory
This is especially important in:
* F5 / F6 edges
* F3 / F4 edges
* F1 / F7 synthetic boundary cases
* F5 and F6 edges
* F3 and F4 edges
* F1 and F7 synthetic boundary cases
A weak validation with a high confidence label is worse than an explicit uncertain result.
---
## 13. Relationship to rollback
## 14. Relationship to rollback
Validation and rollback are closely connected.
@ -515,7 +589,7 @@ not as a special embarrassment case.
---
## 14. Relationship to escalation
## 15. Relationship to escalation
Validation should also know when to stop pretending that the current layer is enough.
@ -530,13 +604,13 @@ Escalation becomes the right output when:
This is especially relevant for:
* F6-heavy cases
* difficult F3 / F4 / F6 interactions
* difficult F3, F4, and F6 interactions
* high-abstract coherence and legitimacy problems
* multi-layer synthetic truth and representation mixtures
---
## 15. Example validation objects
## 16. Example validation objects
### Example A · F1 validation
@ -585,7 +659,7 @@ This is especially relevant for:
---
## 16. What this loop does not yet include
## 17. What this loop does not yet include
Repair Validation Loop v1 does **not** yet include:
@ -602,11 +676,11 @@ v1 only aims to define the validation logic clearly enough for later implementat
---
## 17. Recommended next step
## 18. Recommended next step
Once this file exists, the next logical file is:
* `rollback-policy-v1.md`
* [Rollback Policy v1](./rollback-policy-v1.md)
because the validation loop now defines when rollback is needed,
but the system still needs a formal statement of how rollback should be framed and governed.
@ -622,6 +696,24 @@ which is a very strong first-phase foundation.
---
## 18. One-line validation summary
## 19. Next steps ✨
After this page, most readers continue with:
1. [Open Rollback Policy v1](./rollback-policy-v1.md)
2. [Open Repair Planner Spec v1](./repair-planner-spec-v1.md)
3. [Open Planner Review Checklist v1](./planner-review-checklist-v1.md)
4. [Open Planner Test Note v1](./planner-test-note-v1.md)
If you want the broader product surface:
* [Back to Auto Repair v1 README](./README.md)
* [Back to Fixes Hub](../README.md)
* [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
* [Back to Atlas Hub](../../README.md)
---
## 20. One-line validation summary 🌍
**Repair Validation Loop v1 defines how Atlas-based repair should be judged, accepted, revised, rolled back, or escalated after a repair action is proposed or applied.**

198
ProblemMap/Atlas/Fixes/auto-repair/rollback-policy-v1.md
View file

@ -1,6 +1,61 @@
# Rollback Policy v1
<!--
AI_NOTE_START
↩️ **Rollback Policy v1** defines when and how Atlas-based repair should back out of a proposed or applied repair action.
Document role:
This file defines the first formal rollback policy for the Auto Repair layer inside the Atlas Fixes package.
How to use this file:
1. Read this page when a proposed or applied repair may need to be backed out.
2. Use this page together with:
- [Auto Repair v1 README](./README.md)
- [Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Repair Action Schema v1](./repair-action-schema-v1.md)
- [Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
3. Use this page as the rollback policy contract for deciding what should be restored, how far rollback should go, and what the next safe step should be.
What this file is:
- The rollback policy page for Auto Repair v1
- A contract for backing out of harmful or unhelpful repair actions
- A stability-preserving decision layer after failed validation
What this file is not:
- Not full rollback automation
- Not a deployment-grade restoration engine
- Not proof that every rollback can be executed automatically
- Not a replacement for planner or validation logic
Reading discipline for AI:
- Treat rollback as a normal branch of the repair workflow, not as an embarrassment case.
- Keep rollback target, rollback reason, restore point, and next step visible.
- Prefer explicit safety and stability over rhetorical confidence.
- Distinguish clearly between rollback and escalation.
AI_NOTE_END
-->
# Rollback Policy v1 ↩️
## How Atlas-based repair should back out safely after harmful or unhelpful repair moves
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Open Repair Action Schema v1](./repair-action-schema-v1.md)
- [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Open Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Open Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
---
If the validation loop decides **whether a repair helped enough to keep**, this rollback policy defines **what should happen when the repair should not be kept**.
This document does **not** claim that full rollback automation already exists.
@ -9,12 +64,40 @@ Instead, it defines the first formal policy for a simple but critical requiremen
> if a repair makes the case worse,
> or repairs the wrong layer,
> or creates stronger collateral damage,
> the system must be able to stop, back out, and recover safely.
> the system must be able to stop, back out, and recover safely
Without rollback policy, Auto Repair becomes too fragile to trust.
---
## Quick start
### I want the shortest rollback reading
Use this path:
1. identify the failed or harmful repair action
2. identify the rollback reason
3. identify the restore point
4. choose rollback scope
5. decide the next step after rollback
### I want the stronger workflow reading
Use this page together with:
1. [Repair Validation Loop v1](./repair-validation-loop-v1.md)
2. [Repair Action Schema v1](./repair-action-schema-v1.md)
3. [Repair Planner Spec v1](./repair-planner-spec-v1.md)
Short version:
> detect the harm
> restore the safer prior state
> then revise or escalate
---
## 1. What this document is for
This file defines the rollback layer for Auto Repair v1.
@ -29,10 +112,10 @@ Its purpose is to explain:
This document should be read together with:
- `README.md`
- `auto-repair-architecture-v1.md`
- `repair-action-schema-v1.md`
- `repair-validation-loop-v1.md`
- [README](./README.md)
- [Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Repair Action Schema v1](./repair-action-schema-v1.md)
- [Repair Validation Loop v1](./repair-validation-loop-v1.md)
Together, those files define:
@ -89,7 +172,22 @@ This means:
---
## 4. Core rollback principle
## 4. Rollback quick map
| Rollback concern | Main question |
| -------------------- | ----------------------------------------------- |
| rollback target | what action or patch are we reversing |
| rollback reason | why is rollback necessary |
| rollback scope | how much of the change should be reversed |
| restore point | what prior state should we return to |
| post-rollback status | what state should exist after rollback |
| next step | what should happen after the rollback completes |
This page is the right place when the question is **how to back out safely from a bad repair move**, not how to validate the repair in the first place.
---
## 5. Core rollback principle
Rollback should answer one question clearly:
@ -108,7 +206,7 @@ Rollback is therefore a **stability-preserving operation**, not a victory condit
---
## 5. Minimal rollback contract
## 6. Minimal rollback contract
Every rollback decision in v1 should aim to produce these outputs.
@ -133,7 +231,7 @@ This creates a reusable rollback object for later planner and validator integrat
---
## 6. Field definitions
## 7. Field definitions
### `rollback_target`
@ -147,8 +245,6 @@ Examples:
This field ties rollback back to the repair action identity.
---
### `rollback_reason`
A short statement of why rollback is necessary.
@ -162,8 +258,6 @@ Examples:
This field should be explicit and local.
---
### `rollback_scope`
How much of the repair is being reversed.
@ -182,8 +276,6 @@ Examples:
* `last-step-only` when a multi-part repair should back out only its final move
* `planner-level-only` when the system should cancel the proposed action before execution
---
### `restore_point`
The state the rollback should attempt to return to.
@ -197,8 +289,6 @@ Examples:
This field is essential because rollback without a restore point becomes vague.
---
### `post_rollback_status`
A short summary of the expected state after rollback.
@ -212,8 +302,6 @@ Examples:
This field should describe the recovery target, not the entire system.
---
### `next_step`
What the system should do after rollback.
@ -227,11 +315,12 @@ Suggested values:
* `human review`
Rollback should never end in silence.
It should always lead to a clear next step.
---
## 7. When rollback should be considered
## 8. When rollback should be considered
Rollback should be considered whenever validation shows one or more of the following:
@ -246,7 +335,7 @@ These do not always force rollback, but they should trigger serious review.
---
## 8. When rollback should be required
## 9. When rollback should be required
Rollback should be treated as required in v1 when:
@ -287,12 +376,12 @@ The action enters a higher-risk region without sufficient justification or revie
This is especially important for:
* F6-heavy cases
* F5 / F6 edge cases
* F5 and F6 edge cases
* complex multi-family cases with weak evidence
---
## 9. Rollback is not failure by embarrassment
## 10. Rollback is not failure by embarrassment
Rollback must be treated as a normal and legitimate branch of the repair workflow.
@ -306,13 +395,13 @@ It does **not** mean:
It means:
> the proposed repair did not hold under validation,
> so the system preserved stability by backing out safely.
> so the system preserved stability by backing out safely
That is healthy behavior.
---
## 10. Relationship to validation
## 11. Relationship to validation
Validation and rollback are tightly linked.
@ -327,6 +416,7 @@ Rollback responds when the recommended outcome is:
* `rollback`
This means rollback is not an emotional judgment.
It is a policy response to failed or harmful repair validation.
In practical terms:
@ -337,7 +427,7 @@ In practical terms:
---
## 11. Relationship to escalation
## 12. Relationship to escalation
Rollback and escalation are different.
@ -363,7 +453,7 @@ This is common when the system learns that the current repair layer is not suffi
---
## 12. Recommended rollback sequence
## 13. Recommended rollback sequence
The recommended early rollback sequence is:
@ -378,11 +468,11 @@ This keeps rollback auditable and reusable.
---
## 13. Family-specific rollback examples
## 14. Family-specific rollback examples
Different families often need different rollback logic.
### F1 · Grounding & Evidence Integrity
### F1 · Grounding and Evidence Integrity
Common rollback targets:
@ -399,9 +489,7 @@ Typical next step:
* retry alternate grounding action
* re-check F1 versus F7 boundary
---
### F4 · Execution & Contract Integrity
### F4 · Execution and Contract Integrity
Common rollback targets:
@ -419,9 +507,7 @@ Typical next step:
* re-check F3 versus F4 cut
* escalate if workflow state is ambiguous
---
### F7 · Representation & Localization Integrity
### F7 · Representation and Localization Integrity
Common rollback targets:
@ -438,9 +524,7 @@ Typical next step:
* revise schema
* re-check F7 versus F1 or F2 boundary
---
### F5 · Observability & Diagnosability Integrity
### F5 · Observability and Diagnosability Integrity
Common rollback targets:
@ -457,9 +541,7 @@ Typical next step:
* redesign observability uplift
* narrow the probe target
---
### F6 · Boundary & Safety Integrity
### F6 · Boundary and Safety Integrity
Early rollback in F6 should be highly cautious.
@ -482,13 +564,13 @@ Typical next step:
---
## 14. Rollback and confidence discipline
## 15. Rollback and confidence discipline
Rollback decisions should also carry confidence discipline.
Confidence should be lower when:
* before / after comparison is weak
* before and after comparison is weak
* multiple families remain plausible
* restore point is unclear
* collateral damage is suspected but not well measured
@ -499,7 +581,7 @@ but the system should say so with appropriate caution.
---
## 15. Example rollback objects
## 16. Example rollback objects
### Example A · F1 rollback
@ -542,7 +624,7 @@ but the system should say so with appropriate caution.
---
## 16. What v1 does not yet include
## 17. What v1 does not yet include
Rollback Policy v1 does **not** yet include:
@ -559,11 +641,11 @@ v1 only aims to define the rollback logic clearly enough for safe staged growth.
---
## 17. Recommended next step
## 18. Recommended next step
Once this file exists, the next logical file is:
* `auto-repair-roadmap-v1.md`
* [Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
because the folder will then already contain:
@ -584,6 +666,24 @@ That roadmap will make the folder feel complete as a first-stage system.
---
## 18. One-line rollback summary
## 19. Next steps
After this page, most readers continue with:
1. [Open Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
2. [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
3. [Open Repair Planner Spec v1](./repair-planner-spec-v1.md)
4. [Back to Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
If you want the broader product surface:
* [Back to Auto Repair v1 README](./README.md)
* [Back to Fixes Hub](../README.md)
* [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
* [Back to Atlas Hub](../../README.md)
---
## 20. One-line rollback summary
**Rollback Policy v1 defines when Atlas-based repair should back out, what should be restored, and how the system should safely continue through revision or escalation.**

183
ProblemMap/Atlas/Fixes/auto-repair/safe-early-action-catalog-v1.md
View file

@ -1,33 +1,112 @@
# Safe Early Action Catalog v1
<!--
AI_NOTE_START
## 0. Document status
Document role:
This file defines the first small catalog of safe early repair actions for the Auto Repair layer inside the Atlas Fixes package.
This document defines the first small catalog of **safe early repair actions** for Atlas-based Auto Repair.
How to use this file:
1. Read this page when you want a controlled shelf of early repair actions that are suitable for planning, validation, demos, and later constrained semi-auto use.
2. Use this page together with:
- [Auto Repair v1 README](./README.md)
- [Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Repair Action Schema v1](./repair-action-schema-v1.md)
- [Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Rollback Policy v1](./rollback-policy-v1.md)
- [Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
What this file is:
- The first safe early action shelf for Auto Repair v1
- A practical catalog of local, inspectable, reversible, and validation-ready repair actions
- A bridge between planner logic and later constrained semi-auto behavior
What this file is not:
- Not the full repair library
- Not a broad multi-step execution pack
- Not proof that all families are equally ready for early semi-auto use
- Not a license to apply actions without validation or rollback discipline
Reading discipline for AI:
- Treat this catalog as an early controlled action shelf, not as the full repair universe.
- Prefer one action first, validate after each move, and keep rollback possible.
- Stay cautious near family boundaries, especially F1/F7, F3/F4, and F5/F6.
- Do not overread limited early F5 actions as permission for broad boundary-heavy intervention.
AI_NOTE_END
-->
# Safe Early Action Catalog v1 🧩
## The first controlled shelf of local, inspectable, reversible, and validation-ready repair actions
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Open Repair Action Schema v1](./repair-action-schema-v1.md)
- [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Open Rollback Policy v1](./rollback-policy-v1.md)
- [Open Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Open Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Open Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Open Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Open Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
---
If the planner layer decides **which first repair moves are plausible**, this catalog defines **which early actions are safe enough to put on the shelf for planning, validation, demos, and later constrained semi-auto use**. 🧭
Its purpose is practical:
> before building broader semi-auto repair behavior,
> define a small set of actions that are local, inspectable, reversible, and validation-friendly.
> before building broader semi-auto repair behavior,
> define a small set of actions that are local, inspectable, reversible, and validation-friendly
This document does **not** claim that the full repair library already exists.
It claims something narrower and more useful:
> the project now has a first controlled catalog of early repair actions
> that are suitable for planning, validation, demos, and later constrained semi-auto use.
> the project now has a first controlled catalog of early repair actions
> that are suitable for planning, validation, demos, and later constrained semi-auto use
This file should be read together with:
---
- `README.md`
- `auto-repair-architecture-v1.md`
- `repair-action-schema-v1.md`
- `repair-validation-loop-v1.md`
- `rollback-policy-v1.md`
- `auto-repair-roadmap-v1.md`
- `repair-planner-spec-v1.md`
- `repair-planner-prompt-v1.md`
- `repair-plan-schema-v1.json`
- `semi-auto-repair-scope-v1.md`
## Quick start 🚀
### I want the shortest catalog reading
Use this path:
1. read the catalog use rules
2. inspect the F1, F4, and F7 action groups first
3. check each action’s validation target and rollback hint
4. use only one action first
5. validate before moving to anything else
### I want the stronger system reading
Use this page together with:
1. [Repair Action Schema v1](./repair-action-schema-v1.md)
2. [Repair Validation Loop v1](./repair-validation-loop-v1.md)
3. [Rollback Policy v1](./rollback-policy-v1.md)
4. [Repair Planner Spec v1](./repair-planner-spec-v1.md)
5. [Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
Short version:
> keep the action local
> make validation clear
> keep rollback possible
> stay conservative near boundaries ✨
---
@ -44,8 +123,8 @@ The current Auto Repair layer already has:
But without a small action catalog, the system still lacks a practical middle layer between:
- abstract repair planning
and
- abstract repair planning
and
- actual candidate repair moves
This catalog fills that gap.
@ -59,7 +138,7 @@ It gives the system a first set of repair actions that are:
In short:
> this is the first usable action shelf for Auto Repair.
> this is the first usable action shelf for Auto Repair
---
@ -83,7 +162,20 @@ That is intentional.
---
## 3. Catalog structure
## 3. Catalog quick map 🗂️
| Family group | Why it appears early | Typical action style |
|---|---|---|
| F1 | concrete grounding fixes are easier to inspect and compare | re-grounding, anchor filtering, source re-check |
| F4 | workflow-structural fixes are often visible and testable | gate insertion, ordering correction, closure hardening |
| F7 | container-level fixes are often directly inspectable in outputs | schema tightening, descriptor repair, shell correction |
| F5 limited set | useful but should stay narrow and caution-heavy | trace exposure, local logging uplift |
This page is the right place when the question is **which early repair actions are safe enough to put into practical use first**, not how to build the full long-term repair library.
---
## 4. Catalog structure
Each action entry in this file follows the same compact structure:
@ -104,8 +196,8 @@ This is a practical catalog format, not a full schema file.
The full schema contract still lives in:
- `repair-action-schema-v1.md`
- `repair-plan-schema-v1.json`
- [Repair Action Schema v1](./repair-action-schema-v1.md)
- [Repair Plan Schema v1](./repair-plan-schema-v1.json)
---
@ -113,7 +205,7 @@ The full schema contract still lives in:
# F1 Safe Early Actions
These actions target **Grounding & Evidence Integrity**.
These actions target **Grounding and Evidence Integrity**.
They are usually good early candidates because they are concrete and comparatively easy to inspect.
@ -243,7 +335,7 @@ Do not use if the case has no inspectable source target.
# F4 Safe Early Actions
These actions target **Execution & Contract Integrity**.
These actions target **Execution and Contract Integrity**.
They are strong early candidates because the repair region is often workflow-visible.
@ -373,7 +465,7 @@ Do not use as an automatic first move in high-ambiguity institutional or boundar
# F7 Safe Early Actions
These actions target **Representation & Localization Integrity**.
These actions target **Representation and Localization Integrity**.
They are good early targets because the repaired region is often visible in the output container itself.
@ -477,7 +569,7 @@ F7_E01 Explanation Fidelity Distortion
shell correction
### Intended Effect
Repair broken object / array / field boundary so the output shell can hold the intended content correctly.
Repair broken object, array, or field boundary so the output shell can hold the intended content correctly.
### Allowed Scope
minimal
@ -591,38 +683,43 @@ Do not use as a blanket instrumentation move across the whole system.
# Part V
# Catalog use rules
# Catalog use rules 📌
This catalog should be used under the following rules.
## Rule 1
Prefer one action first.
Do not start by throwing multiple categories of repair at the case.
## Rule 2
Validate after each local action.
Do not assume that a seemingly reasonable repair already helped.
## Rule 3
Rollback must stay possible.
If rollback is unclear, the action should not be treated as safe early action.
## Rule 4
Do not treat this catalog as a full repair library.
This is an **early action catalog**, not the final repair universe.
## Rule 5
Use caution near family boundaries.
Especially:
- F1 / F7
- F3 / F4
- F5 / F6
- F1 and F7
- F3 and F4
- F5 and F6
The planner should remain conservative in these regions.
@ -657,12 +754,30 @@ Once this catalog exists, the next logical move is one of these:
The strongest immediate next step is probably:
> turn 2 or 3 of these actions into tiny repair planner examples and tiny validation examples.
> turn 2 or 3 of these actions into tiny repair planner examples and tiny validation examples
That would make the catalog feel operational very quickly.
---
## One-line summary
## Next steps ✨
After this page, most readers continue with:
1. [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
2. [Open Rollback Policy v1](./rollback-policy-v1.md)
3. [Open Planner Test Note v1](./planner-test-note-v1.md)
4. [Open Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
If you want the broader product surface:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to Atlas Hub](../../README.md)
---
## One-line summary 🌍
**Safe Early Action Catalog v1 defines the first controlled set of local, inspectable, reversible, and validation-ready repair actions for Atlas-based Auto Repair.**

264
ProblemMap/Atlas/Fixes/auto-repair/semi-auto-repair-scope-v1.md
View file

@ -1,31 +1,110 @@
# Semi-Auto Repair Scope v1
<!--
AI_NOTE_START
## 0. Document status
Document role:
This file defines the first formal scope boundary for semi-auto repair inside the Auto Repair layer of the Atlas Fixes package.
This document defines the first formal scope boundary for **semi-auto repair** inside the Atlas Auto Repair layer.
How to use this file:
1. Read this page when deciding whether a repair action is safe enough for early constrained semi-auto use.
2. Use this page together with:
- [Auto Repair v1 README](./README.md)
- [Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Repair Action Schema v1](./repair-action-schema-v1.md)
- [Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Rollback Policy v1](./rollback-policy-v1.md)
- [Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Repair Plan Schema v1](./repair-plan-schema-v1.json)
What this file is:
- The scope boundary page for early semi-auto repair
- A safety contract for deciding which actions may enter constrained semi-auto use
- A bridge between planner-only behavior and later bounded apply-and-check behavior
What this file is not:
- Not proof that broad autonomous repair is already available
- Not a permission slip for unrestricted repair execution
- Not a replacement for validation, rollback, or planner discipline
- Not the full long-term execution policy for all repair families
Reading discipline for AI:
- Treat this file as a boundary contract, not as a maturity claim about broad automation.
- Keep local scope, inspectability, reversibility, and validation-readiness visible.
- Prefer planner-only or review-bound handling when evidence is weak or family pressure is ambiguous.
- Stay especially cautious in F6-heavy, multi-family, or broad-mutation cases.
AI_NOTE_END
-->
# Semi-Auto Repair Scope v1 🛡️
## The first formal boundary for early constrained semi-auto repair
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Open Repair Action Schema v1](./repair-action-schema-v1.md)
- [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Open Rollback Policy v1](./rollback-policy-v1.md)
- [Open Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Open Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Open Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Open Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Open Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
---
If the planner layer decides **which repair move is plausible**, this scope document decides **which kinds of repair moves are safe enough to enter early semi-auto use**. 🧭
Its purpose is to answer one practical question:
> which repair actions are safe enough to be partially automated in early phases,
> which repair actions are safe enough to be partially automated in early phases,
> and which repair actions should remain planner-only, review-bound, or explicitly delayed?
This document does **not** claim that broad autonomous repair is already available.
It defines something narrower and safer:
> the first controlled scope for limited, auditable, reversible semi-auto repair.
> the first controlled scope for limited, auditable, reversible semi-auto repair
This file should be read together with:
---
- `README.md`
- `auto-repair-architecture-v1.md`
- `repair-action-schema-v1.md`
- `repair-validation-loop-v1.md`
- `rollback-policy-v1.md`
- `auto-repair-roadmap-v1.md`
- `repair-planner-spec-v1.md`
- `repair-planner-prompt-v1.md`
- `repair-plan-schema-v1.json`
## Quick start 🚀
### I want the shortest scope reading
Use this path:
1. check whether the case is already routed
2. check whether the action is local, inspectable, reversible, and validation-ready
3. check whether the action belongs to an allowed early category
4. check whether any stop condition is present
5. only then allow semi-auto apply-and-check behavior
### I want the stronger system reading
Use this page together with:
1. [Repair Planner Spec v1](./repair-planner-spec-v1.md)
2. [Repair Validation Loop v1](./repair-validation-loop-v1.md)
3. [Rollback Policy v1](./rollback-policy-v1.md)
4. [Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
Short version:
> route first
> keep the action small
> make validation explicit
> keep rollback possible
> stop early when boundary risk is high
---
@ -35,8 +114,8 @@ Semi-auto repair does **not** mean unrestricted self-directed repair.
It means:
> the system may generate, apply, or suggest a narrowly bounded repair action
> when the action is local, inspectable, reversible, and validation-ready.
> the system may generate, apply, or suggest a narrowly bounded repair action
> when the action is local, inspectable, reversible, and validation-ready
This is an intentionally limited concept.
@ -91,8 +170,8 @@ So this document exists to keep growth disciplined.
The scope rule is simple:
> only actions that are local, inspectable, reversible, and validation-ready
> may enter early semi-auto repair.
> only actions that are local, inspectable, reversible, and validation-ready
> may enter early semi-auto repair
If an action fails one or more of those tests, it should remain:
@ -105,7 +184,23 @@ This is the main protective rule for v1.
---
## 4. Semi-auto repair tiers
## 4. Scope quick map 🗂️
| Tier or region | Early reading |
|---|---|
| Tier 1 suggest-only | safest starting point |
| Tier 2 controlled apply-and-check | main early semi-auto target |
| Tier 3 bounded iterative repair | possible later, do not rush |
| F1 / F4 / F7 | best early family targets |
| F5 | limited and caution-heavy |
| F3 | possible but more subtle |
| F6-heavy cases | planner-only or review-bound |
This page is the right place when the question is **what may safely enter constrained semi-auto use now**, not whether the whole repair stack is ready for broad automation.
---
## 5. Semi-auto repair tiers
Semi-auto repair should be understood in three operational tiers.
@ -144,7 +239,7 @@ It requires stronger validation and rollback discipline.
---
## 5. What qualifies as in-scope for v1
## 6. What qualifies as in-scope for v1
A repair action is in scope for early semi-auto use when all of the following are true.
@ -176,7 +271,7 @@ The action must not require broad undefined system mutation.
### Condition 3 · Action is inspectable
The before/after difference must be understandable.
The before and after difference must be understandable.
If nobody can tell what changed, the action is too loose for early semi-auto use.
@ -201,11 +296,11 @@ If the validation target is vague, the action is too immature.
---
## 6. Best early family targets
## 7. Best early family targets
Not all families are equally suitable for early semi-auto work.
### F1 · Grounding & Evidence Integrity
### F1 · Grounding and Evidence Integrity
This is one of the best early targets.
@ -234,9 +329,7 @@ Good early rollback targets:
- restore previous evidence selection
- restore previous candidate set
---
### F4 · Execution & Contract Integrity
### F4 · Execution and Contract Integrity
This is also a strong early target.
@ -244,7 +337,7 @@ Why:
- workflow errors are often structurally visible
- gates and ordering logic can often be stated clearly
- before/after comparison is practical
- before and after comparison is practical
Good early examples:
@ -265,9 +358,7 @@ Good early rollback targets:
- remove inserted gate
- restore previous ordering rule
---
### F7 · Representation & Localization Integrity
### F7 · Representation and Localization Integrity
This is another excellent early target.
@ -282,7 +373,7 @@ Good early examples:
- tighten JSON schema
- correct field shell shape
- restore array/object boundary
- restore array or object boundary
- strengthen formal descriptor wording
Good early validation targets:
@ -299,11 +390,11 @@ Good early rollback targets:
---
## 7. Medium-scope families
## 8. Medium-scope families
Some families can support semi-auto work, but only carefully.
### F5 · Observability & Diagnosability Integrity
### F5 · Observability and Diagnosability Integrity
Possible early actions:
@ -328,9 +419,7 @@ Bad use mode:
- broad instrumentation without a narrow probe target
---
### F3 · State & Continuity Integrity
### F3 · State and Continuity Integrity
Possible early actions:
@ -357,7 +446,7 @@ Bad use mode:
---
## 8. Out of scope for early semi-auto use
## 9. Out of scope for early semi-auto use
The following areas should remain out of scope for v1 semi-auto execution.
@ -386,17 +475,15 @@ Not allowed early use:
- legitimacy or incentive restructuring
- unsafe autonomous boundary action
---
### Multi-family ambiguity under weak evidence
If the case is sitting in strong ambiguity, semi-auto execution should not proceed.
Examples:
- F1/F7 ambiguity under synthetic structure pressure
- F3/F4 ambiguity under workflow-memory interaction
- F5/F6 ambiguity under abstract governance pressure
- F1 and F7 ambiguity under synthetic structure pressure
- F3 and F4 ambiguity under workflow-memory interaction
- F5 and F6 ambiguity under abstract governance pressure
In such cases, the correct move is:
@ -405,8 +492,6 @@ In such cases, the correct move is:
- escalate
- stop and wait
---
### Broad system mutation
Actions that touch too much system surface at once are out of scope.
@ -422,11 +507,12 @@ These are too large for early semi-auto discipline.
---
## 9. Allowed early action categories
## 10. Allowed early action categories
The following action categories are good early semi-auto candidates.
### Category A · Evidence-local actions
Examples:
- re-ground evidence set
@ -435,6 +521,7 @@ Examples:
- narrow candidate evidence range
### Category B · Gate-local actions
Examples:
- insert readiness gate
@ -443,6 +530,7 @@ Examples:
- restore local ordering check
### Category C · Schema-local actions
Examples:
- tighten schema shell
@ -451,6 +539,7 @@ Examples:
- constrain a field structure
### Category D · Probe-local actions
Examples:
- add a local trace probe
@ -462,25 +551,29 @@ This category should remain more cautious than A, B, and C.
---
## 10. Disallowed early action categories
## 11. Disallowed early action categories
The following should remain outside early semi-auto scope.
### Category X · Full workflow redesign
Too broad.
### Category Y · High-abstraction policy intervention
Too risky.
### Category Z · Multi-step repair chains without checkpoints
Too hard to validate and rollback.
### Category W · Boundary-heavy autonomous intervention
Too dangerous for early phases.
---
## 11. Required safety checks before semi-auto apply
## 12. Required safety checks before semi-auto apply
Before any in-scope action is applied, the system should confirm:
@ -503,7 +596,7 @@ It should revert to:
---
## 12. Required stop conditions
## 13. Required stop conditions
Semi-auto repair should stop immediately when:
@ -517,18 +610,19 @@ Semi-auto repair should stop immediately when:
- the planner cannot distinguish between local gain and likely collateral damage
These conditions are not edge cases.
They are core protections.
---
## 13. Example in-scope actions
## 14. Example in-scope actions
### Example A · F1 local semi-auto action
Case:
Case:
retrieval anchor drift in a replayable benchmark case
Action:
Action:
replace evidence subset with a better-aligned subset
Why in scope:
@ -542,20 +636,18 @@ Recommended tier:
- Tier 2
---
### Example B · F4 local semi-auto action
Case:
Case:
downstream send step executes before upstream readiness is complete
Action:
Action:
insert a local readiness gate in the replay workflow
Why in scope:
- narrow workflow change
- visible before/after
- visible before and after
- rollback is clear
- validation target is explicit
@ -563,14 +655,12 @@ Recommended tier:
- Tier 2
---
### Example C · F7 local semi-auto action
Case:
Case:
output content is partially correct but the JSON shell is invalid
Action:
Action:
tighten schema shell and restore object boundary
Why in scope:
@ -586,14 +676,14 @@ Recommended tier:
---
## 14. Example out-of-scope actions
## 15. Example out-of-scope actions
### Example A · F6 boundary intervention
Case:
Case:
high-pressure alignment and legitimacy ambiguity
Action:
Action:
apply a strong autonomous stabilization rule
Why out of scope:
@ -602,14 +692,12 @@ Why out of scope:
- low tolerance for false confidence
- review and escalation are safer
---
### Example B · broad workflow rewrite
Case:
Case:
multi-step workflow occasionally fails under mixed memory and closure pressure
Action:
Action:
rewrite the whole workflow plan automatically
Why out of scope:
@ -618,14 +706,12 @@ Why out of scope:
- too hard to validate locally
- rollback would be unstable
---
### Example C · abstract coherence intervention
Case:
value / knowledge / probability coherence case under F5/F6 boundary pressure
Case:
value, knowledge, or probability coherence case under F5 and F6 boundary pressure
Action:
Action:
apply a strong abstract corrective rewrite
Why out of scope:
@ -636,7 +722,7 @@ Why out of scope:
---
## 15. Semi-auto success condition
## 16. Semi-auto success condition
Early semi-auto repair should be considered successful only when:
@ -657,12 +743,12 @@ Not:
---
## 16. Relationship to future phases
## 17. Relationship to future phases
This scope document is mainly for the transition between:
- Stage 1 · Repair planner
and
- Stage 1 · Repair planner
and
- Stage 2 · Constrained semi-auto repair
It should remain conservative until:
@ -678,11 +764,11 @@ It is the safe doorway into the next phase.
---
## 17. Recommended immediate next step
## 18. Recommended immediate next step
Once this file exists, the next useful step is likely one of these:
- create a small action catalog for F1 / F4 / F7
- create a small action catalog for F1, F4, and F7
- create one minimal semi-auto demo spec
- create one validator example pack for semi-auto cases
@ -694,6 +780,24 @@ That would make the semi-auto layer much more concrete.
---
## 18. One-line scope summary
## 19. Next steps ✨
After this page, most readers continue with:
1. [Open Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
2. [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
3. [Open Rollback Policy v1](./rollback-policy-v1.md)
4. [Open Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
If you want the broader product surface:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to Atlas Hub](../../README.md)
---
## 20. One-line scope summary 🌍
**Semi-Auto Repair Scope v1 defines which Atlas-based repair actions are safe enough for early constrained semi-auto use, and which actions must remain planner-only, review-bound, or delayed.**

227
ProblemMap/Atlas/Fixes/auto-repair/tiny-planner-output-examples-pack-v1.md
View file

@ -1,31 +1,111 @@
# Tiny Planner Output Examples Pack v1
<!--
AI_NOTE_START
## 0. Document status
Document role:
This file is the first compact positive example pack for the Atlas Auto Repair planner layer.
This document defines the first tiny output example pack for the Atlas Auto Repair planner layer.
How to use this file:
1. Read this page when you want concrete examples of what good planner output should look like after Atlas routing is already available.
2. Use this page together with:
- [Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Planner Test Note v1](./planner-test-note-v1.md)
- [Planner Review Checklist v1](./planner-review-checklist-v1.md)
- [Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
- [Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
3. Use this page for review calibration, onboarding, demo support, and future regression checks.
What this file is:
- A compact positive example pack for planner outputs
- A reference set for v1 planner style and structure
- A practical bridge between planner rules and visible sample outputs
What this file is not:
- Not a benchmark pack
- Not a complete planner corpus
- Not a failing-output pack
- Not proof that the planner is already production-complete
Reading discipline for AI:
- Treat these examples as style and quality references for first repair planning.
- Keep family alignment, action locality, validation target, misrepair warning, and next-step discipline visible.
- Do not overread these examples as evidence of full repair closure.
- Use them as small reusable references, not as universal templates for every case.
AI_NOTE_END
-->
# Tiny Planner Output Examples Pack v1 🧪
## The first compact positive reference pack for Atlas Auto Repair planner outputs
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Open Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Open Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Open Planner Test Note v1](./planner-test-note-v1.md)
- [Open Planner Review Checklist v1](./planner-review-checklist-v1.md)
- [Open Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Open Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
- [Open Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
- [Open Tiny Semi Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
---
If the planner spec explains **what good planner behavior should be**, this pack shows **what that behavior should actually look like in compact output form**. 🧭
Its purpose is practical:
> show a few compact examples of what good planner output should look like
> after Atlas routing is already available.
> show a few compact examples of what good planner output should look like
> after Atlas routing is already available
This file does **not** claim to be a benchmark pack or a complete planner corpus.
It claims something smaller and more useful:
> the project now has a first small set of concrete planner output examples
> that can be reused for review, onboarding, demos, and future tuning.
> the project now has a first small set of concrete planner output examples
> that can be reused for review, onboarding, demos, and future tuning
This document should be read together with:
---
- `repair-planner-spec-v1.md`
- `repair-planner-prompt-v1.md`
- `repair-plan-schema-v1.json`
- `planner-test-note-v1.md`
- `planner-review-checklist-v1.md`
- `safe-early-action-catalog-v1.md`
- `tiny-validation-examples-pack-v1.md`
- `tiny-rollback-examples-pack-v1.md`
## Quick start 🚀
### I want the shortest example reading
Use this path:
1. read one case summary
2. inspect the planner output object
3. read why it is a good example
4. compare it against the review checklist
5. use it as a reference, not as a universal script
### I want the stronger review path
Use this page together with:
1. [Repair Planner Spec v1](./repair-planner-spec-v1.md)
2. [Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
3. [Planner Review Checklist v1](./planner-review-checklist-v1.md)
4. [Planner Test Note v1](./planner-test-note-v1.md)
Short version:
> keep the family
> keep the action set small
> name validation clearly
> warn about the wrong path
> end with a usable next step ✨
---
@ -53,7 +133,7 @@ This pack fills that gap.
In short:
> this is the first tiny reference pack for planner output style and quality.
> this is the first tiny reference pack for planner output style and quality
---
@ -80,7 +160,20 @@ They are first reference samples.
---
## 3. Pack scope
## 3. Examples quick map 🗂️
| Example | Main teaching focus |
|---|---|
| F1 example | grounding-first planning should stay concrete and local |
| F4 example | workflow-first planning should stay on closure and ordering |
| F7 example | container-first planning should repair structure before abstract pressure |
| cautious F5 example | boundary-adjacent cases should narrow scope rather than overreach |
This page is the right place when the question is **what good planner output should look like in practice**, not whether the planner has been comprehensively benchmarked.
---
## 4. Pack scope
This v1 pack includes four tiny planner output examples:
@ -100,7 +193,7 @@ This is enough for a strong first sample set.
---
## 4. Standard output example format
## 5. Standard output example format
Each example follows the same shape:
@ -114,15 +207,13 @@ This keeps the pack compact and reusable.
---
# Example 1
## Example 1 · F1 Planner Output Example
# F1 Planner Output Example
## Example ID
### Example ID
`TPO_F1_001`
## Case summary
### Case summary
The case is already routed to F1.
@ -133,9 +224,9 @@ The routed diagnosis indicates:
- primary family: F1
- broken invariant: evidence-anchor integrity broken
- best current fit: Retrieval Anchor Drift
- fix surface direction: re-grounding / anchor re-check
- fix surface direction: re-grounding or anchor re-check
## Planner output object
### Planner output object
```json
{
@ -162,7 +253,7 @@ The routed diagnosis indicates:
}
````
## Why this is a good example
### Why this is a good example
This is a good example because:
@ -172,21 +263,19 @@ This is a good example because:
* the misrepair risk is real and relevant
* the next step is operational rather than vague
## Main teaching point
### Main teaching point
A good F1 planner output should feel concrete, local, and evidence-aware.
---
# Example 2
## Example 2 · F4 Planner Output Example
# F4 Planner Output Example
## Example ID
### Example ID
`TPO_F4_001`
## Case summary
### Case summary
The case is already routed to F4.
@ -198,9 +287,9 @@ The routed diagnosis indicates:
* secondary family: F3
* broken invariant: deployment liveness closure broken
* best current fit: Pre-Readiness Execution Failure
* fix surface direction: readiness audit / gate insertion
* fix surface direction: readiness audit or gate insertion
## Planner output object
### Planner output object
```json
{
@ -228,7 +317,7 @@ The routed diagnosis indicates:
}
```
## Why this is a good example
### Why this is a good example
This is a good example because:
@ -238,21 +327,19 @@ This is a good example because:
* it defines a validation target that matches the failure
* it gives a useful neighbor-family explanation
## Main teaching point
### Main teaching point
A good F4 planner output should repair workflow structure first, not throw more reasoning or instructions at the case.
---
# Example 3
## Example 3 · F7 Planner Output Example
# F7 Planner Output Example
## Example ID
### Example ID
`TPO_F7_001`
## Case summary
### Case summary
The case is already routed to F7.
@ -263,9 +350,9 @@ The routed diagnosis indicates:
* primary family: F7
* broken invariant: container fidelity broken
* best current fit: Symbolic Representation Fidelity Failure
* fix surface direction: schema tightening / shell correction
* fix surface direction: schema tightening or shell correction
## Planner output object
### Planner output object
```json
{
@ -292,7 +379,7 @@ The routed diagnosis indicates:
}
```
## Why this is a good example
### Why this is a good example
This is a good example because:
@ -301,21 +388,19 @@ This is a good example because:
* it defines a visible validation target
* it includes a realistic warning about false success
## Main teaching point
### Main teaching point
A good F7 planner output should repair the shell first and validate structure without pretending that structure alone guarantees truth.
---
# Example 4
## Example 4 · F5 Cautious Planner Output Example
# F5 Cautious Planner Output Example
## Example ID
### Example ID
`TPO_F5_001`
## Case summary
### Case summary
The case is already routed to F5 with some neighboring F6 pressure.
@ -327,9 +412,9 @@ The routed diagnosis indicates:
* secondary family: F6
* broken invariant: failure-path visibility broken
* best current fit: Failure Path Opacity
* fix surface direction: trace exposure / observability insertion
* fix surface direction: trace exposure or observability insertion
## Planner output object
### Planner output object
```json
{
@ -354,7 +439,7 @@ The routed diagnosis indicates:
}
```
## Why this is a good example
### Why this is a good example
This is a good example because:
@ -364,13 +449,13 @@ This is a good example because:
* it explains why F6 is not first
* it escalates rather than overreaching
## Main teaching point
### Main teaching point
A good F5 planner output near F6 pressure should become more careful, not more aggressive.
---
## 5. What these examples have in common
## 6. What these examples have in common
Across all four examples, good planner behavior shares the same core traits:
@ -385,7 +470,7 @@ These traits matter more than stylistic polish.
---
## 6. What bad examples would usually look like
## 7. What bad examples would usually look like
These examples also imply what weak planner output looks like.
@ -403,7 +488,7 @@ This pack should be used partly as a positive reference set and partly as a nega
---
## 7. How to use this pack
## 8. How to use this pack
This pack can be used in several practical ways.
@ -425,7 +510,7 @@ When planner behavior changes later, these examples can serve as a tiny stabilit
---
## 8. What this pack does not yet include
## 9. What this pack does not yet include
Tiny Planner Output Examples Pack v1 does **not** yet include:
@ -442,7 +527,7 @@ This pack is intentionally compact.
---
## 9. Recommended next step
## 10. Recommended next step
Once this pack exists, the next useful follow-up is one of these:
@ -458,6 +543,26 @@ That would take the planner layer one step closer to visible repair workflow dem
---
## 10. One-line summary
## 11. Next steps ✨
After this page, most readers continue with:
1. [Open Planner Review Checklist v1](./planner-review-checklist-v1.md)
2. [Open Planner Test Note v1](./planner-test-note-v1.md)
3. [Open Tiny Semi Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
4. [Open Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
5. [Open Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
If you want the broader product surface:
* [Back to Auto Repair v1 README](./README.md)
* [Back to Fixes Hub](../README.md)
* [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
* [Back to Atlas Hub](../../README.md)
---
## 12. One-line summary 🌍
**Tiny Planner Output Examples Pack v1 provides the first compact examples of what good Atlas Auto Repair planner output should look like across F1, F4, F7, and cautious F5 cases.**

286
ProblemMap/Atlas/Fixes/auto-repair/tiny-rollback-examples-pack-v1.md
View file

@ -1,36 +1,118 @@
# Tiny Rollback Examples Pack v1
<!--
AI_NOTE_START
## 0. Document status
Document role:
This file is the first compact rollback example pack for the Auto Repair layer inside the Atlas Fixes package.
This document defines the first tiny rollback example pack for Atlas-based Auto Repair.
How to use this file:
1. Read this page when you want concrete examples of how rollback should look after a harmful or misleading repair move.
2. Use this page together with:
- [Auto Repair v1 README](./README.md)
- [Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Repair Action Schema v1](./repair-action-schema-v1.md)
- [Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Rollback Policy v1](./rollback-policy-v1.md)
- [Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
- [Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
3. Use this page for onboarding, review calibration, demo support, and future rollback-aware semi-auto design.
What this file is:
- A compact rollback example pack
- A small evidence layer for rollback behavior
- A practical bridge between rollback policy rules and visible rollback cases
What this file is not:
- Not a full rollback benchmark set
- Not automated rollback execution
- Not proof that rollback is solved across all families
- Not a production-grade restoration test suite
Reading discipline for AI:
- Treat rollback as a normal branch of repair discipline, not as an embarrassment path.
- Keep rollback target, rollback reason, restore point, post-rollback state, and next step visible.
- Use these examples as small reference cases, not as universal templates for every repair failure.
- Stay especially cautious when extrapolating beyond F1, F4, F7, and limited F5.
AI_NOTE_END
-->
# Tiny Rollback Examples Pack v1 ↩️
## The first compact rollback reference pack for safe early Atlas-based repair actions
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Open Repair Action Schema v1](./repair-action-schema-v1.md)
- [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Open Rollback Policy v1](./rollback-policy-v1.md)
- [Open Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Open Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Open Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Open Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Open Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
- [Open Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Open Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
- [Open Planner Test Note v1](./planner-test-note-v1.md)
- [Open Tiny Semi Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
---
If the rollback policy explains **when rollback should happen**, this pack shows **what rollback should look like in small, concrete cases**. 🧭
Its purpose is simple:
> show a few minimal rollback cases
> so the Auto Repair layer can move from rollback policy rules
> to concrete, inspectable rollback behavior.
> show a few minimal rollback cases
> so the Auto Repair layer can move from rollback policy rules
> to concrete, inspectable rollback behavior
This file does **not** claim to be a full rollback benchmark set.
It claims something smaller and more useful:
> the project now has a first set of tiny rollback examples
> for safe early repair actions in F1, F4, and F7.
> the project now has a first set of tiny rollback examples
> for safe early repair actions in F1, F4, F7, and limited F5
This document should be read together with:
---
- `README.md`
- `auto-repair-architecture-v1.md`
- `repair-action-schema-v1.md`
- `repair-validation-loop-v1.md`
- `rollback-policy-v1.md`
- `auto-repair-roadmap-v1.md`
- `repair-planner-spec-v1.md`
- `repair-planner-prompt-v1.md`
- `repair-plan-schema-v1.json`
- `semi-auto-repair-scope-v1.md`
- `safe-early-action-catalog-v1.md`
- `tiny-validation-examples-pack-v1.md`
## Quick start 🚀
### I want the shortest rollback reading
Use this path:
1. read one example ID and its failed action
2. inspect the rollback reason
3. inspect the restore point
4. inspect the post-rollback state
5. inspect the next step
### I want the stronger rollback reading
Use this page together with:
1. [Rollback Policy v1](./rollback-policy-v1.md)
2. [Repair Validation Loop v1](./repair-validation-loop-v1.md)
3. [Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
Short version:
> see what failed
> see what gets restored
> see why rollback is correct
> see what happens next ✨
---
@ -59,7 +141,7 @@ It provides a few small examples that show:
In short:
> this pack is the first small evidence layer for rollback behavior.
> this pack is the first small evidence layer for rollback behavior
---
@ -85,13 +167,27 @@ That is already very valuable.
---
## 3. Pack scope
## 3. Rollback examples quick map 🗂️
This v1 pack includes three tiny rollback examples:
| Example | Main teaching focus |
|---|---|
| F1 example | rollback protects grounding truth when filtering over-prunes evidence |
| F4 example | rollback protects workflow usability when a gate becomes too restrictive |
| F7 example | rollback protects semantic fit when structure cleanup overshoots |
| limited F5 example | rollback protects diagnosability when visibility changes add noise instead of insight |
This page is the right place when the question is **what healthy rollback behavior looks like in practice**, not whether rollback has been fully automated.
---
## 4. Pack scope
This v1 pack includes four tiny rollback examples:
- one F1 example
- one F4 example
- one F7 example
- one limited F5 example
These were chosen because they are the best early families for:
@ -101,11 +197,12 @@ These were chosen because they are the best early families for:
- simple rollback explanations
This pack intentionally does **not** include F6-heavy rollback cases.
Those remain too risky and too abstract for early tiny rollback samples.
---
## 4. Standard tiny rollback format
## 5. Standard tiny rollback format
Each tiny rollback example uses the following structure:
@ -124,221 +221,206 @@ This format is intentionally small and reusable.
---
# Example 1
## Example 1 · F1 Tiny Rollback Example
# F1 Tiny Rollback Example
## Example ID
### Example ID
`TRE_F1_001`
## Family
### Family
F1 · Grounding & Evidence Integrity
F1 · Grounding and Evidence Integrity
## Failed or harmful repair action
### Failed or harmful repair action
`F1_AF_001`
Filter misleading adjacent anchors
## Rollback target
### Rollback target
`F1_AF_001`
## Rollback reason
### Rollback reason
The filtering step removed misleading anchors, but also removed the truly relevant source chunk.
The filtering step removed misleading anchors, but it also removed the truly relevant source chunk.
The repair made the evidence set look cleaner, but semantic alignment with the real source became worse.
## Restore point
### Restore point
prior candidate evidence pool
## Post-rollback state
### Post-rollback state
The earlier evidence pool is restored so the system no longer remains trapped in the over-pruned evidence state.
The grounding problem is still unresolved, but the case is no longer worse than before.
## Next step
### Next step
`retry-with-alternate-action`
## Why rollback is correct
### Why rollback is correct
Rollback is correct because the repair damaged the target layer more than it improved it.
The local repair goal was grounding improvement, but the real outcome was harmful over-pruning.
## Main teaching point
### Main teaching point
A grounding repair should be rolled back if it creates a cleaner-looking but less truthful evidence set.
---
# Example 2
## Example 2 · F4 Tiny Rollback Example
# F4 Tiny Rollback Example
## Example ID
### Example ID
`TRE_F4_001`
## Family
### Family
F4 · Execution & Contract Integrity
F4 · Execution and Contract Integrity
## Failed or harmful repair action
### Failed or harmful repair action
`F4_GT_001`
Insert readiness gate
## Rollback target
### Rollback target
`F4_GT_001`
## Rollback reason
### Rollback reason
The new readiness gate blocked the original premature execution, but it also blocked a valid downstream path that should have remained available.
The repair improved closure locally, but overshot the intended scope.
## Restore point
### Restore point
previous workflow gate configuration
## Post-rollback state
### Post-rollback state
The over-restrictive gate is removed and the workflow returns to the earlier configuration.
The system regains the previous valid path, while the closure issue remains available for a narrower future repair.
## Next step
### Next step
`revise`
## Why rollback is correct
### Why rollback is correct
Rollback is correct because the inserted gate created stronger collateral damage than the original local gain.
The target problem was premature execution, not total execution shutdown.
## Main teaching point
### Main teaching point
A closure repair should be rolled back if it blocks more than the failure it was meant to stop.
---
# Example 3
## Example 3 · F7 Tiny Rollback Example
# F7 Tiny Rollback Example
## Example ID
### Example ID
`TRE_F7_001`
## Family
### Family
F7 · Representation & Localization Integrity
F7 · Representation and Localization Integrity
## Failed or harmful repair action
### Failed or harmful repair action
`F7_SC_001`
Tighten output schema
## Rollback target
### Rollback target
`F7_SC_001`
## Rollback reason
### Rollback reason
The schema tightening produced a valid structure, but semantic task fit degraded enough that the output became less useful.
The shell improved, but the content quality dropped too much.
## Restore point
### Restore point
prior schema version
## Post-rollback state
### Post-rollback state
The earlier schema shell is restored so the case no longer remains trapped in a structurally valid but semantically degraded state.
The original representation issue is still present, but the system returns to the less harmful baseline.
## Next step
### Next step
`re-check family fit`
## Why rollback is correct
### Why rollback is correct
Rollback is correct because the repair improved one visible dimension while worsening a more important functional dimension.
The action oversolved structure at the cost of task fidelity.
## Main teaching point
### Main teaching point
A container repair should be rolled back if structural cleanliness comes at too high a semantic cost.
---
## 5. Optional mixed rollback example
## Example 4 · Limited F5 Tiny Rollback Example
This extra example shows that rollback is not always triggered by catastrophic failure.
Sometimes rollback is the right move because the repair attacked the wrong layer first.
---
# Example 4
# F5 Tiny Rollback Example
## Example ID
### Example ID
`TRE_F5_001`
## Family
### Family
F5 · Observability & Diagnosability Integrity
F5 · Observability and Diagnosability Integrity
## Failed or harmful repair action
### Failed or harmful repair action
`F5_LU_001`
Add local logging uplift
## Rollback target
### Rollback target
`F5_LU_001`
## Rollback reason
### Rollback reason
The additional logging exposed more detail, but it made the workflow noisier without improving actual diagnosability.
The repair increased visibility volume without improving failure-path clarity.
## Restore point
### Restore point
pre-observability patch state
## Post-rollback state
### Post-rollback state
The added noisy logging layer is removed and the workflow returns to its prior signal level.
The case still needs observability work, but the system is no longer buried under low-value trace noise.
## Next step
### Next step
`revise`
## Why rollback is correct
### Why rollback is correct
Rollback is correct because the repair improved information quantity but degraded practical diagnosability.
The problem was not only missing visibility.
The problem was not only missing visibility.
It was missing useful visibility.
## Main teaching point
### Main teaching point
An observability repair should be rolled back if it adds noise faster than it adds insight.
@ -350,7 +432,7 @@ Taken together, these tiny rollback examples teach four important lessons.
### Lesson 1
Rollback is not an embarrassment branch.
Rollback is not an embarrassment branch.
It is a normal part of repair discipline.
### Lesson 2
@ -416,10 +498,28 @@ Once this pack exists, the next useful follow-up is one of these:
The strongest immediate next step is probably:
> create a planner test note that shows how the planner, validation, and rollback layers connect on the same small cases.
> create a planner test note that shows how the planner, validation, and rollback layers connect on the same small cases
---
## 10. One-line summary
## 10. Next steps ✨
After this page, most readers continue with:
1. [Open Planner Test Note v1](./planner-test-note-v1.md)
2. [Open Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
3. [Open Tiny Semi Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
4. [Open Rollback Policy v1](./rollback-policy-v1.md)
If you want the broader product surface:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to Atlas Hub](../../README.md)
---
## 11. One-line summary 🌍
**Tiny Rollback Examples Pack v1 provides the first small rollback examples for safe early Atlas-based repair actions in F1, F4, F7, and limited F5.**

305
ProblemMap/Atlas/Fixes/auto-repair/tiny-semi-auto-demo-pack-v1.md
View file

@ -1,40 +1,131 @@
# Tiny Semi-Auto Demo Pack v1
<!--
AI_NOTE_START
## 0. Document status
Document role:
This file is the first compact semi-auto demo pack for the Auto Repair layer inside the Atlas Fixes package.
This document defines the first tiny semi-auto demo pack for the Atlas Auto Repair layer.
How to use this file:
1. Read this page when you want small visible examples of the Atlas → Auto Repair micro-workflow in motion.
2. Use this page together with:
- [Auto Repair v1 README](./README.md)
- [Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Repair Action Schema v1](./repair-action-schema-v1.md)
- [Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Rollback Policy v1](./rollback-policy-v1.md)
- [Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
- [Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
- [Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
- [Planner Test Note v1](./planner-test-note-v1.md)
- [Planner Review Checklist v1](./planner-review-checklist-v1.md)
- [Tiny Planner Output Examples Pack v1](./tiny-planner-output-examples-pack-v1.md)
- [Tiny Semi Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
- [Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
3. Use this page for demo support, onboarding, review calibration, and future replay or notebook-oriented demo expansion.
What this file is:
- A compact semi-auto demo pack
- The first visible sample layer for bounded local repair workflows
- A practical bridge between planner output, local action, validation, rollback readiness, and deeper continuation decisions
What this file is not:
- Not a production repair suite
- Not a benchmark pack
- Not unrestricted self-repair
- Not proof that broad autonomous repair is already available
Reading discipline for AI:
- Treat each demo as a bounded local workflow sample, not as proof of full repair autonomy.
- Keep routed diagnosis, selected action, validation result, rollback readiness, and deeper continuation decision visible.
- Do not overread small local success as total closure.
- Preserve the layer distinction between Atlas routing, Auto Repair local action, and deeper WFGY continuation.
AI_NOTE_END
-->
# Tiny Semi-Auto Demo Pack v1 🧪
## The first compact visible demo layer for Atlas-based semi-auto repair
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Open Repair Action Schema v1](./repair-action-schema-v1.md)
- [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Open Rollback Policy v1](./rollback-policy-v1.md)
- [Open Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Open Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Open Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Open Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Open Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
- [Open Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Open Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
- [Open Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
- [Open Planner Test Note v1](./planner-test-note-v1.md)
- [Open Planner Review Checklist v1](./planner-review-checklist-v1.md)
- [Open Tiny Planner Output Examples Pack v1](./tiny-planner-output-examples-pack-v1.md)
- [Open Tiny Semi Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
- [Open Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
- [Open Worked Escalation Example v1](./worked-escalation-example-v1.md)
---
If the demo spec explains **how a tiny semi-auto demo should be structured**, this pack shows **what a few compact demos actually look like when the workflow runs end to end**. 🧭
Its purpose is practical:
> provide a first compact set of semi-auto repair demos
> that make the Auto Repair workflow visible, testable, and teachable.
> that make the Auto Repair workflow visible, testable, and teachable
This file does **not** claim to be a production repair suite.
It claims something smaller and more useful:
> the project now has a first tiny pack of local, validation-aware, rollback-aware, WFGY-aware semi-auto repair demos.
> the project now has a first tiny pack of local, validation-aware, rollback-aware, WFGY-aware semi-auto repair demos
This document should be read together with:
---
- `README.md`
- `auto-repair-architecture-v1.md`
- `repair-action-schema-v1.md`
- `repair-validation-loop-v1.md`
- `rollback-policy-v1.md`
- `auto-repair-roadmap-v1.md`
- `repair-planner-spec-v1.md`
- `repair-planner-prompt-v1.md`
- `repair-plan-schema-v1.json`
- `semi-auto-repair-scope-v1.md`
- `safe-early-action-catalog-v1.md`
- `tiny-validation-examples-pack-v1.md`
- `tiny-rollback-examples-pack-v1.md`
- `planner-test-note-v1.md`
- `planner-review-checklist-v1.md`
- `tiny-planner-output-examples-pack-v1.md`
- `tiny-semi-auto-demo-spec-v1.md`
- `atlas-auto-repair-to-wfgy-bridge-v1.md`
## Quick start 🚀
### I want the shortest demo reading
Use this path:
1. read one demo ID and case summary
2. inspect the routed diagnosis
3. inspect the planner output
4. inspect the selected action
5. inspect the validation result
6. inspect the final outcome and deeper continuation note
### I want the stronger workflow reading
Use this page together with:
1. [Tiny Semi Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
2. [Tiny Planner Output Examples Pack v1](./tiny-planner-output-examples-pack-v1.md)
3. [Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
4. [Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
5. [Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
Short version:
> route the case
> pick one safe local action
> validate the result
> keep rollback visible
> decide whether local repair is enough ✨
---
@ -73,7 +164,7 @@ It provides the first compact set of demo cases that show:
In short:
> this pack is the first visible semi-auto repair sample layer.
> this pack is the first visible semi-auto repair sample layer
---
@ -100,7 +191,19 @@ That is already enough for a strong first demo pack.
---
## 3. Pack composition
## 3. Demo quick map 🗂️
| Demo | Main teaching focus |
|---|---|
| F1 demo | grounding-first repair can succeed through a single local evidence action |
| F4 demo | execution-first repair can succeed through a narrow closure fix |
| F7 demo | structure-first repair can improve the container while still ending in `revise` |
This page is the right place when the question is **what a small bounded semi-auto workflow should look like in practice**, not whether the full repair stack is production-ready.
---
## 4. Pack composition
This v1 pack includes three tiny semi-auto demos:
@ -127,7 +230,7 @@ Those belong to later stages.
---
## 4. Standard demo format
## 5. Standard demo format
Each demo in this pack follows the same structure:
@ -155,19 +258,17 @@ This format is compact enough for:
---
# Demo 1
## Demo 1 · F1 Tiny Semi-Auto Demo
# F1 Tiny Semi-Auto Demo
## Demo ID
### Demo ID
`TSAD_F1_001`
## Family
### Family
F1 · Grounding & Evidence Integrity
F1 · Grounding and Evidence Integrity
## Case summary
### Case summary
A response is fluent and plausible, but it is grounded in a semantically adjacent source chunk rather than the intended evidence source.
@ -175,17 +276,17 @@ The failure is not primarily stylistic and not primarily representational.
It is a grounding-first case.
## Routed diagnosis
### Routed diagnosis
- primary family: F1
- secondary family: F7
- broken invariant: evidence-anchor integrity broken
- best current fit: `F1_N01 Retrieval Anchor Drift`
- fix surface direction: re-grounding / anchor re-check
- fix surface direction: re-grounding or anchor re-check
- confidence: medium
- evidence sufficiency: medium
## Planner output
### Planner output
```json
{
@ -207,26 +308,26 @@ It is a grounding-first case.
}
````
## Selected action
### Selected action
`F1_RG_001`
Re-ground evidence set
## Before state
### Before state
* answer appears coherent
* cited or implied source support is nearby but wrong
* semantic target fit is weaker than it first appears
* evidence anchor is not the intended one
## After state
### After state
* evidence set is replaced with a better-aligned source set
* answer is now tied more directly to the intended source target
* local grounding quality improves
* no visible container damage is introduced
## Validation result
### Validation result
```json
{
@ -240,42 +341,40 @@ Re-ground evidence set
}
```
## Final outcome
### Final outcome
`accept`
## Rollback readiness
### Rollback readiness
* rollback ready: true
* restore point: prior evidence set
## Deeper continuation
### Deeper continuation
`local repair sufficient`
### WFGY continuation note
#### WFGY continuation note
No deeper WFGY 3.0 continuation is needed for this tiny demo because the local grounding repair is already sufficient at the Atlas / Auto Repair layer.
No deeper WFGY 3.0 continuation is needed for this tiny demo because the local grounding repair is already sufficient at the Atlas and Auto Repair layer.
## Why this demo matters
### Why this demo matters
This demo shows that a grounding-first case can be improved through a small local repair without pretending that all plausible-looking failures are reasoning failures.
---
# Demo 2
## Demo 2 · F4 Tiny Semi-Auto Demo
# F4 Tiny Semi-Auto Demo
## Demo ID
### Demo ID
`TSAD_F4_001`
## Family
### Family
F4 · Execution & Contract Integrity
F4 · Execution and Contract Integrity
## Case summary
### Case summary
A downstream action executes before approval and readiness are complete.
@ -283,17 +382,17 @@ The workflow is not primarily broken because of memory loss or weak reasoning.
It is a closure-first case.
## Routed diagnosis
### Routed diagnosis
* primary family: F4
* secondary family: F3
* broken invariant: deployment liveness closure broken
* best current fit: `F4_N03 Pre-Readiness Execution Failure`
* fix surface direction: readiness audit / gate insertion
* fix surface direction: readiness audit or gate insertion
* confidence: medium
* evidence sufficiency: medium
## Planner output
### Planner output
```json
{
@ -316,26 +415,26 @@ It is a closure-first case.
}
```
## Selected action
### Selected action
`F4_GT_001`
Insert readiness gate
## Before state
### Before state
* downstream action is available
* readiness is incomplete
* execution still moves forward
* workflow closure is too weak
## After state
### After state
* a local readiness gate is inserted
* downstream action is blocked until readiness is satisfied
* closure integrity improves
* the workflow becomes more structurally disciplined
## Validation result
### Validation result
```json
{
@ -349,43 +448,42 @@ Insert readiness gate
}
```
## Final outcome
### Final outcome
`accept`
## Rollback readiness
### Rollback readiness
* rollback ready: true
* restore point: previous workflow gate configuration
## Deeper continuation
### Deeper continuation
`local repair sufficient`
### WFGY continuation note
#### WFGY continuation note
No deeper WFGY 3.0 continuation is needed for this tiny demo because the local closure repair is sufficient and the workflow state becomes stable under bounded intervention.
## Why this demo matters
### Why this demo matters
This demo shows that not every system failure needs more intelligence pressure.
Some failures need execution skeleton repair first.
---
# Demo 3
## Demo 3 · F7 Tiny Semi-Auto Demo
# F7 Tiny Semi-Auto Demo
## Demo ID
### Demo ID
`TSAD_F7_001`
## Family
### Family
F7 · Representation & Localization Integrity
F7 · Representation and Localization Integrity
## Case summary
### Case summary
The content is partly correct, but the structured shell is broken and cannot be reliably consumed downstream.
@ -393,17 +491,17 @@ The main problem is not primarily reasoning progression.
It is a container-first case.
## Routed diagnosis
### Routed diagnosis
* primary family: F7
* secondary family: F2
* broken invariant: representation container fidelity broken
* best current fit: `F7_N01 Symbolic Representation Fidelity Failure`
* fix surface direction: schema tightening / shell correction
* fix surface direction: schema tightening or shell correction
* confidence: medium
* evidence sufficiency: medium
## Planner output
### Planner output
```json
{
@ -425,26 +523,26 @@ It is a container-first case.
}
```
## Selected action
### Selected action
`F7_SC_001`
Tighten output schema
## Before state
### Before state
* output content is partially useful
* object or field boundaries are broken
* downstream consumption is unreliable
* structural shell is invalid
## After state
### After state
* schema shell is tightened
* field boundaries are restored
* downstream consumption becomes possible
* structure becomes cleaner and more stable
## Validation result
### Validation result
```json
{
@ -458,30 +556,28 @@ Tighten output schema
}
```
## Final outcome
### Final outcome
`revise`
## Rollback readiness
### Rollback readiness
* rollback ready: true
* restore point: prior schema version
## Deeper continuation
### Deeper continuation
`local repair partially useful, deeper continuation optional`
### WFGY continuation note
#### WFGY continuation note
The local Atlas-level repair improves container fidelity, but deeper WFGY 3.0 continuation may still be useful if semantic fit remains unstable or if the representational encoding itself is still too weak.
Official TXT:
```text
https://raw.githubusercontent.com/onestardao/WFGY/refs/heads/main/TensionUniverse/WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt
```
* [WFGY 3.0 Singularity Demo TXT](https://raw.githubusercontent.com/onestardao/WFGY/refs/heads/main/TensionUniverse/WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt)
## Why this demo matters
### Why this demo matters
This demo shows that a repair can improve one dimension without justifying a fake full success claim.
@ -489,7 +585,7 @@ That is exactly why `revise` exists.
---
## 5. What this pack teaches
## 6. What this pack teaches
Taken together, these three tiny demos teach several important lessons.
@ -517,7 +613,7 @@ Sometimes the right outcome is `revise`, and sometimes deeper WFGY 3.0 continuat
---
## 6. Why this pack is useful
## 7. Why this pack is useful
This pack is useful for at least five reasons.
@ -531,7 +627,7 @@ It gives the planner concrete output targets.
### C. Validation support
It shows what compact before / after validation should look like.
It shows what compact before and after validation should look like.
### D. Rollback support
@ -543,13 +639,13 @@ It demonstrates that local Atlas repair and deeper WFGY continuation belong to t
---
## 7. What this pack does not yet include
## 8. What this pack does not yet include
Tiny Semi-Auto Demo Pack v1 does **not** yet include:
* F6-heavy intervention demos
* full notebook implementations
* replay/live orchestration code
* replay or live orchestration code
* large benchmark demo suites
* multi-step repair chains
* full WFGY continuation walkthroughs
@ -560,7 +656,7 @@ This pack is intentionally small and disciplined.
---
## 8. Recommended next step
## 9. Recommended next step
Once this pack exists, the next useful follow-up is probably one of these:
@ -576,6 +672,25 @@ because that would make the Atlas → Auto Repair → WFGY 3.0 bridge even more
---
## 9. One-line summary
## 10. Next steps ✨
After this page, most readers continue with:
1. [Open Tiny Semi Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
2. [Open Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
3. [Open Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
4. [Open Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
5. [Open Worked Escalation Example v1](./worked-escalation-example-v1.md)
If you want the broader product surface:
* [Back to Auto Repair v1 README](./README.md)
* [Back to Fixes Hub](../README.md)
* [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
* [Back to Atlas Hub](../../README.md)
---
## 11. One-line summary 🌍
**Tiny Semi-Auto Demo Pack v1 provides the first compact F1, F4, and F7 semi-auto repair demos that show planner output, bounded local action, validation, final outcome, and possible WFGY 3.0 continuation.**

244
ProblemMap/Atlas/Fixes/auto-repair/tiny-semi-auto-demo-spec-v1.md
View file

@ -1,40 +1,131 @@
# Tiny Semi-Auto Demo Spec v1
<!--
AI_NOTE_START
## 0. Document status
Document role:
This file defines the first formal tiny semi-auto demo specification for the Auto Repair layer inside the Atlas Fixes package.
This document defines the first tiny semi-auto demo specification for the Atlas Auto Repair layer.
How to use this file:
1. Read this page when you want to design a small, bounded, demo-ready semi-auto repair flow.
2. Use this page together with:
- [Auto Repair v1 README](./README.md)
- [Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Repair Action Schema v1](./repair-action-schema-v1.md)
- [Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Rollback Policy v1](./rollback-policy-v1.md)
- [Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
- [Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
- [Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
- [Planner Test Note v1](./planner-test-note-v1.md)
- [Planner Review Checklist v1](./planner-review-checklist-v1.md)
- [Tiny Planner Output Examples Pack v1](./tiny-planner-output-examples-pack-v1.md)
- [Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
3. Use this page as the structure contract for tiny semi-auto demos, not as proof of a production repair engine.
What this file is:
- The first demo specification for tiny semi-auto repair
- A structure contract for bounded local repair demos
- A bridge between planner output, local action, validation, rollback readiness, and deeper continuation
What this file is not:
- Not a production repair engine
- Not a full replay or notebook implementation
- Not a benchmark orchestration spec
- Not proof that broad autonomous repair already exists
Reading discipline for AI:
- Keep the demo local, visible, validation-aware, rollback-aware, and explicit about final outcome.
- Do not hide broad mutation behind small demo language.
- Do not claim full closure when the correct outcome is revise, rollback, or escalate.
- If deeper WFGY continuation is needed, say so explicitly and briefly explain why.
AI_NOTE_END
-->
# Tiny Semi-Auto Demo Spec v1 🧪
## How a small, bounded, validation-aware semi-auto repair demo should be structured
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Open Repair Action Schema v1](./repair-action-schema-v1.md)
- [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Open Rollback Policy v1](./rollback-policy-v1.md)
- [Open Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Open Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Open Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Open Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Open Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
- [Open Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Open Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
- [Open Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
- [Open Planner Test Note v1](./planner-test-note-v1.md)
- [Open Planner Review Checklist v1](./planner-review-checklist-v1.md)
- [Open Tiny Planner Output Examples Pack v1](./tiny-planner-output-examples-pack-v1.md)
- [Open Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
- [Open Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
---
If the planner spec explains **how a routed case becomes a first repair plan**, this file explains **how that plan should be shown as a small visible semi-auto demo**.
Its purpose is practical:
> show how a very small, controlled, semi-auto repair flow should work
> without pretending that full autonomous repair already exists.
> without pretending that full autonomous repair already exists
This file does **not** define a production repair engine.
It defines something much narrower and safer:
> a first demo-ready specification for local, inspectable, reversible,
> validation-aware, rollback-aware semi-auto repair behavior.
> validation-aware, rollback-aware semi-auto repair behavior
This document should be read together with:
---
- `README.md`
- `auto-repair-architecture-v1.md`
- `repair-action-schema-v1.md`
- `repair-validation-loop-v1.md`
- `rollback-policy-v1.md`
- `auto-repair-roadmap-v1.md`
- `repair-planner-spec-v1.md`
- `repair-planner-prompt-v1.md`
- `repair-plan-schema-v1.json`
- `semi-auto-repair-scope-v1.md`
- `safe-early-action-catalog-v1.md`
- `tiny-validation-examples-pack-v1.md`
- `tiny-rollback-examples-pack-v1.md`
- `planner-test-note-v1.md`
- `planner-review-checklist-v1.md`
- `tiny-planner-output-examples-pack-v1.md`
- `atlas-auto-repair-to-wfgy-bridge-v1.md`
## Quick start 🚀
### I want the shortest demo-spec reading
Use this path:
1. start from a routed case
2. show one planner output
3. choose one safe early action
4. show one before state and one after state
5. show one validation result
6. end with one explicit final outcome
7. state clearly whether deeper WFGY continuation is needed
### I want the stronger design reading
Use this page together with:
1. [Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
2. [Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
3. [Repair Validation Loop v1](./repair-validation-loop-v1.md)
4. [Rollback Policy v1](./rollback-policy-v1.md)
5. [Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
Short version:
> start from a routed case
> pick one safe local action
> validate the result
> keep rollback visible
> end with a clear outcome
---
@ -55,8 +146,8 @@ The Auto Repair layer already has:
But there is still a missing bridge between:
- planner output
- and
- planner output
and
- visible semi-auto repair behavior
This spec fills that gap.
@ -72,7 +163,7 @@ It defines how a tiny semi-auto demo should be structured so that the system can
In short:
> this is the first small demo contract for semi-auto repair.
> this is the first small demo contract for semi-auto repair
---
@ -124,7 +215,23 @@ The point is to show a trustworthy micro-workflow.
---
## 4. Recommended demo families
## 4. Demo spec quick map 🗂️
| Demo block | Main job |
|---|---|
| routed case | establish the bounded input |
| planner output | show the first repair plan explicitly |
| selected action | show one safe early action only |
| before and after | make the local change visible |
| validation result | justify the outcome |
| final outcome | end in accept, revise, rollback, or escalate |
| deeper continuation | clarify whether Atlas-level repair is enough |
This page is the right place when the question is **how a tiny semi-auto demo should be structured**, not whether the whole repair stack is production-ready.
---
## 5. Recommended demo families
The first tiny semi-auto demos should come from the safest early family set.
@ -155,7 +262,7 @@ Those are better left for later stages.
---
## 5. Minimal demo workflow
## 6. Minimal demo workflow
The smallest acceptable semi-auto demo workflow is:
@ -181,7 +288,7 @@ If the demo does not reach one of these outcomes explicitly, it is incomplete.
---
## 6. Required demo blocks
## 7. Required demo blocks
Each tiny semi-auto demo should contain the following blocks.
@ -200,9 +307,8 @@ Minimum case elements:
* evidence sufficiency
The demo should not spend most of its time re-explaining routing.
Routing is assumed as input.
---
Routing is assumed as input.
### Block B · Planner output
@ -219,8 +325,6 @@ Minimum required planner fields:
The planner output should be shown explicitly, not only described in prose.
---
### Block C · Selected semi-auto action
The demo must choose one action from the planner result.
@ -236,8 +340,6 @@ Only one action should be applied in the smallest v1 demo.
This keeps the demo honest and easy to inspect.
---
### Block D · Before state
The demo must show a small, explicit before state.
@ -250,8 +352,6 @@ Examples:
This before state should be local and concrete.
---
### Block E · After state
The demo must show the after state produced by the bounded action.
@ -263,9 +363,8 @@ Examples:
* repaired output shell
The after state must remain local.
It should not claim broad unseen system repair.
---
It should not claim broad unseen system repair.
### Block F · Validation result
@ -284,8 +383,6 @@ This is the heart of the demo.
Without this block, the demo is only action theatre.
---
### Block G · Final outcome
The demo must end with one explicit verdict:
@ -297,8 +394,6 @@ The demo must end with one explicit verdict:
That outcome must be justified by the validation result.
---
### Block H · Deeper continuation
The demo should include a short continuation note.
@ -319,7 +414,7 @@ This block is very important because it keeps the relationship between Atlas and
---
## 7. Required safety rules
## 8. Required safety rules
Every tiny semi-auto demo in v1 should obey these safety rules.
@ -339,7 +434,7 @@ Every relevant change should be visible in the demo.
Validation is mandatory.
The demo must not end at “action applied.”
The demo must not end at `action applied`.
### Rule 4
@ -367,7 +462,7 @@ If the demo points to deeper WFGY 3.0 continuation, it must say so explicitly an
---
## 8. Recommended demo variants
## 9. Recommended demo variants
The strongest first spec includes three small variants.
@ -397,7 +492,7 @@ These three variants together already make the semi-auto layer look much more re
---
## 9. Recommended first demo candidates
## 10. Recommended first demo candidates
### F1 candidate
@ -419,8 +514,6 @@ Possible deeper continuation:
* only if local re-grounding still leaves the effective-layer representation too weak
---
### F4 candidate
Use:
@ -429,7 +522,7 @@ Use:
Why strong:
* workflow before/after is visible
* workflow before and after is visible
* closure is easy to explain
* rollback is understandable
@ -439,9 +532,7 @@ Expected likely outcome:
Possible deeper continuation:
* if local closure repair is still too shallow and the workflow needs deeper rule / encoding redesign
---
* if local closure repair is still too shallow and the workflow needs deeper rule or encoding redesign
### F7 candidate
@ -465,7 +556,7 @@ Possible deeper continuation:
---
## 10. Suggested demo object format
## 11. Suggested demo object format
A tiny semi-auto demo object should ideally contain:
@ -499,7 +590,7 @@ This format is enough for:
---
## 11. Example tiny demo outline
## 12. Example tiny demo outline
### Example
@ -547,7 +638,7 @@ This is the kind of compact demo object that v1 should aim for.
---
## 12. Suggested WFGY continuation note pattern
## 13. Suggested WFGY continuation note pattern
When deeper continuation is needed, a compact note like this is enough:
@ -556,14 +647,14 @@ Local Atlas-level repair was not sufficient.
Escalate to WFGY 3.0 for deeper repair grammar, including possible encoding redesign, stronger observables, experiment redesign, or cross-domain structural continuation.
Official TXT:
https://raw.githubusercontent.com/onestardao/WFGY/refs/heads/main/TensionUniverse/WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt
[WFGY 3.0 Singularity Demo TXT](https://raw.githubusercontent.com/onestardao/WFGY/refs/heads/main/TensionUniverse/WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt)
```
This keeps the relationship practical and explicit.
---
## 13. Suggested user instruction pattern
## 14. Suggested user instruction pattern
A simple usage pattern for AI systems is:
@ -577,7 +668,7 @@ This is enough for first-stage public or internal use.
---
## 14. What counts as a good tiny semi-auto demo
## 15. What counts as a good tiny semi-auto demo
A good demo should make it easy to see:
@ -594,7 +685,7 @@ The clarity should come from the structure.
---
## 15. What counts as a weak tiny semi-auto demo
## 16. What counts as a weak tiny semi-auto demo
A weak demo usually has one or more of these problems:
@ -613,12 +704,12 @@ This spec exists partly to prevent those problems.
---
## 16. What this spec does not yet include
## 17. What this spec does not yet include
Tiny Semi-Auto Demo Spec v1 does **not** yet include:
* full notebook implementation
* full replay/live infrastructure
* full replay or live infrastructure
* multi-step repair loops
* family-wide demo coverage
* benchmark automation
@ -631,22 +722,41 @@ This file only defines the first clean demo specification.
---
## 17. Recommended next step
## 18. Recommended next step
Once this spec exists, the next useful follow-up is probably one of these:
1. create `tiny-semi-auto-demo-pack-v1.md`
2. create one small JSON demo pack for F1 / F4 / F7
1. create [Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
2. create one small JSON demo pack for F1, F4, and F7
3. create one notebook-oriented replay spec for a tiny semi-auto case
The strongest immediate next step is probably:
> create a tiny semi-auto demo pack with 2 to 3 compact cases.
> create a tiny semi-auto demo pack with 2 to 3 compact cases
That would turn this spec into something even more visibly usable.
---
## 18. One-line summary
## 19. Next steps ✨
After this page, most readers continue with:
1. [Open Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
2. [Open Tiny Validation Examples Pack v1](./tiny-validation-examples-pack-v1.md)
3. [Open Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
4. [Open Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
5. [Open Worked Escalation Example v1](./worked-escalation-example-v1.md)
If you want the broader product surface:
* [Back to Auto Repair v1 README](./README.md)
* [Back to Fixes Hub](../README.md)
* [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
* [Back to Atlas Hub](../../README.md)
---
## 20. One-line summary 🌍
**Tiny Semi-Auto Demo Spec v1 defines how a first local, validation-aware, rollback-aware, WFGY-aware semi-auto repair demo should be structured for Atlas-based Auto Repair.**

290
ProblemMap/Atlas/Fixes/auto-repair/tiny-validation-examples-pack-v1.md
View file

@ -1,35 +1,119 @@
# Tiny Validation Examples Pack v1
<!--
AI_NOTE_START
## 0. Document status
Document role:
This file is the first compact validation example pack for the Auto Repair layer inside the Atlas Fixes package.
This document defines the first tiny validation example pack for Atlas-based Auto Repair.
How to use this file:
1. Read this page when you want small concrete examples of how Atlas-based repair should be validated after a local action.
2. Use this page together with:
- [Auto Repair v1 README](./README.md)
- [Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Repair Action Schema v1](./repair-action-schema-v1.md)
- [Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Rollback Policy v1](./rollback-policy-v1.md)
- [Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
- [Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
3. Use this page for onboarding, planner calibration, demo support, and future validator-oriented review.
What this file is:
- A compact validation example pack
- A small evidence layer for before-and-after repair validation
- A practical bridge between validation rules and visible validation behavior
What this file is not:
- Not a full benchmark set
- Not automated validator code
- Not a full repair benchmark corpus
- Not proof that every repair action is already validated at scale
Reading discipline for AI:
- Treat these examples as local validation references, not as universal templates for all repair cases.
- Keep target action, validation target, before state, after state, verdict, and rationale visible.
- Prefer concrete before-and-after reasoning over vague success language.
- Distinguish clearly between accept-style and revise-style validation outcomes.
AI_NOTE_END
-->
# Tiny Validation Examples Pack v1 🔍
## The first compact before-and-after validation reference pack for Atlas-based repair
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Auto Repair Architecture v1](./auto-repair-architecture-v1.md)
- [Open Repair Action Schema v1](./repair-action-schema-v1.md)
- [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Open Rollback Policy v1](./rollback-policy-v1.md)
- [Open Auto Repair Roadmap v1](./auto-repair-roadmap-v1.md)
- [Open Repair Planner Spec v1](./repair-planner-spec-v1.md)
- [Open Repair Planner Prompt v1](./repair-planner-prompt-v1.md)
- [Open Repair Plan Schema v1](./repair-plan-schema-v1.json)
- [Open Semi Auto Repair Scope v1](./semi-auto-repair-scope-v1.md)
- [Open Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Open Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
- [Open Planner Test Note v1](./planner-test-note-v1.md)
- [Open Tiny Semi-Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
- [Open Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
---
If the validation loop explains **how repair should be judged**, this pack shows **what a few compact validation judgments should actually look like in practice**. 🧭
Its purpose is simple:
> show a few minimal before/after validation examples
> so the Auto Repair layer can move from abstract rules
> to concrete, inspectable validation behavior.
> show a few minimal before/after validation examples
> so the Auto Repair layer can move from abstract rules
> to concrete, inspectable validation behavior
This file does **not** claim to be a full benchmark set.
It claims something smaller and more useful:
> the project now has a first set of tiny validation examples
> for safe early repair actions in F1, F4, and F7.
> the project now has a first set of tiny validation examples
> for safe early repair actions in F1, F4, F7, and one cautious F7 revise case
This document should be read together with:
---
- `README.md`
- `auto-repair-architecture-v1.md`
- `repair-action-schema-v1.md`
- `repair-validation-loop-v1.md`
- `rollback-policy-v1.md`
- `auto-repair-roadmap-v1.md`
- `repair-planner-spec-v1.md`
- `repair-planner-prompt-v1.md`
- `repair-plan-schema-v1.json`
- `semi-auto-repair-scope-v1.md`
- `safe-early-action-catalog-v1.md`
## Quick start 🚀
### I want the shortest validation reading
Use this path:
1. read one example ID
2. inspect the target action and validation target
3. compare the before state and after state
4. inspect the validation verdict
5. read why the verdict is correct
### I want the stronger validation reading
Use this page together with:
1. [Repair Validation Loop v1](./repair-validation-loop-v1.md)
2. [Repair Action Schema v1](./repair-action-schema-v1.md)
3. [Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
4. [Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
Short version:
> check what action was tried
> check what changed
> check what the verdict is
> check why that verdict makes sense ✨
---
@ -59,7 +143,7 @@ It provides a few small examples that show:
In short:
> this pack is the first small evidence layer for Auto Repair validation.
> this pack is the first small evidence layer for Auto Repair validation
---
@ -77,7 +161,7 @@ They are meant to prove something narrower:
1. a small repair action can be selected cleanly
2. a clear validation target can be named
3. before/after states can be compared
3. before and after states can be compared
4. the system can produce a usable verdict
5. the repair logic can be explained without ambiguity
@ -85,13 +169,27 @@ That is already very valuable.
---
## 3. Pack scope
## 3. Validation examples quick map 🗂️
This v1 pack includes three tiny examples:
| Example | Main teaching focus |
|---|---|
| F1 example | grounding repair should be judged by anchor alignment |
| F4 example | execution repair should be judged by closure correctness |
| F7 accept-style example | structure repair can earn accept when local container fidelity clearly improves |
| F7 revise-style example | cleaner structure does not always justify full accept |
This page is the right place when the question is **what small good validation examples should look like**, not whether the whole repair layer is already benchmarked.
---
## 4. Pack scope
This v1 pack includes four tiny examples:
- one F1 example
- one F4 example
- one F7 example
- one F7 accept-style example
- one F7 revise-style example
These were chosen because they are the best early families for:
@ -101,11 +199,12 @@ These were chosen because they are the best early families for:
- reversible repair moves
This pack intentionally does **not** include F6-heavy examples.
Those remain too risky for early tiny validation samples.
---
## 4. Standard tiny example format
## 5. Standard tiny example format
Each tiny validation example uses the following structure:
@ -123,28 +222,26 @@ This format is intentionally small and reusable.
---
# Example 1
## Example 1 · F1 Tiny Validation Example
# F1 Tiny Validation Example
## Example ID
### Example ID
`TVE_F1_001`
## Family
### Family
F1 · Grounding & Evidence Integrity
F1 · Grounding and Evidence Integrity
## Target action
### Target action
`F1_RG_001`
Re-ground evidence set
## Validation target
### Validation target
anchor alignment
## Before state
### Before state
The answer is fluent and plausible, but it is grounded in a semantically adjacent source chunk rather than the intended source.
@ -154,7 +251,7 @@ The local failure looks like:
- wording looks reasonable
- source alignment is wrong
## After state
### After state
The evidence set is replaced with a better-aligned source group.
@ -166,11 +263,11 @@ The local state now looks like:
- source alignment improves
- answer is more tightly attached to the right support
## Validation verdict
### Validation verdict
`accept`
## Why this verdict is correct
### Why this verdict is correct
The target invariant improved:
@ -178,34 +275,32 @@ The target invariant improved:
- no meaningful collateral damage is visible
- the action remained local and reversible
## Main teaching point
### Main teaching point
A grounding repair should be judged by **anchor alignment**, not by style or fluency alone.
---
# Example 2
## Example 2 · F4 Tiny Validation Example
# F4 Tiny Validation Example
## Example ID
### Example ID
`TVE_F4_001`
## Family
### Family
F4 · Execution & Contract Integrity
F4 · Execution and Contract Integrity
## Target action
### Target action
`F4_GT_001`
Insert readiness gate
## Validation target
### Validation target
readiness state
## Before state
### Before state
A downstream action is available and is executed before upstream readiness is complete.
@ -215,7 +310,7 @@ The local failure looks like:
- approval is incomplete
- execution still moves forward
## After state
### After state
A local readiness gate is inserted.
@ -227,11 +322,11 @@ The local state now looks like:
- the workflow respects readiness order
- closure becomes more stable
## Validation verdict
### Validation verdict
`accept`
## Why this verdict is correct
### Why this verdict is correct
The target invariant improved:
@ -239,34 +334,32 @@ The target invariant improved:
- premature execution is prevented
- rollback remains clear because the gate can be removed if needed
## Main teaching point
### Main teaching point
Execution repair should be judged by **closure correctness**, not by whether the system appears more active.
---
# Example 3
## Example 3 · F7 Tiny Validation Example
# F7 Tiny Validation Example
## Example ID
### Example ID
`TVE_F7_001`
## Family
### Family
F7 · Representation & Localization Integrity
F7 · Representation and Localization Integrity
## Target action
### Target action
`F7_SC_001`
Tighten output schema
## Validation target
### Validation target
schema validity
## Before state
### Before state
The content is partly correct, but the structured shell is broken.
@ -276,7 +369,7 @@ The local failure looks like:
- object shape is invalid
- output cannot be reliably consumed downstream
## After state
### After state
The schema shell is tightened and the output boundary is restored.
@ -286,11 +379,11 @@ The local state now looks like:
- field boundaries hold
- downstream consumption becomes possible
## Validation verdict
### Validation verdict
`accept`
## Why this verdict is correct
### Why this verdict is correct
The target invariant improved:
@ -298,58 +391,48 @@ The target invariant improved:
- the repaired structure is clearly more usable
- the change is inspectable and reversible
## Main teaching point
### Main teaching point
A container repair should be judged by **structural validity**, not by content plausibility alone.
---
## 5. Optional partial or revise-style example
## Example 4 · F7 Partial Validation Example
The pack should also show that not every repair becomes an immediate accept.
This small example is useful for teaching cautious validation.
---
# Example 4
# F7 Partial Validation Example
## Example ID
### Example ID
`TVE_F7_002`
## Family
### Family
F7 · Representation & Localization Integrity
F7 · Representation and Localization Integrity
## Target action
### Target action
`F7_DR_001`
Repair descriptor shell
## Validation target
### Validation target
descriptor fidelity
## Before state
### Before state
The output task descriptor is weak and under-specified.
This causes unstable structured output.
## After state
### After state
The descriptor becomes stricter and the structure becomes cleaner.
However, the semantic fit to the original task appears weaker.
## Validation verdict
### Validation verdict
`revise`
## Why this verdict is correct
### Why this verdict is correct
The repair improved one dimension:
@ -361,9 +444,9 @@ But it also introduced possible collateral damage:
So the right early verdict is not full accept.
It is revise.
It is `revise`.
## Main teaching point
### Main teaching point
A cleaner container is not always a fully successful repair if semantic fit drops.
@ -401,7 +484,7 @@ They help test whether a repair planner is choosing actions that can actually be
### B. Validation support
They show what before/after validation is supposed to look like.
They show what before and after validation is supposed to look like.
### C. Demo support
@ -422,7 +505,7 @@ Tiny Validation Examples Pack v1 does **not** yet include:
- F6-heavy intervention examples
- benchmark-scale scoring
- automated validator code
- rollback case examples as a separate pack
- full rollback examples in the same file
Those can come later.
@ -434,9 +517,9 @@ This pack is intentionally minimal.
Once this pack exists, the next useful follow-up is one of these:
1. create a tiny rollback examples pack
2. create a planner test note using these examples
3. create one tiny semi-auto demo spec that consumes these examples
1. create [Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
2. create [Planner Test Note v1](./planner-test-note-v1.md) using these examples
3. create [Tiny Semi-Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md) that consumes these examples
The strongest immediate next step is probably:
@ -446,6 +529,25 @@ because validation and rollback naturally belong close together.
---
## 10. One-line summary
## 10. Next steps ✨
After this page, most readers continue with:
1. [Open Tiny Rollback Examples Pack v1](./tiny-rollback-examples-pack-v1.md)
2. [Open Planner Test Note v1](./planner-test-note-v1.md)
3. [Open Tiny Semi-Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
4. [Open Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
If you want the broader product surface:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to Atlas Hub](../../README.md)
---
## 11. One-line summary 🌍
**Tiny Validation Examples Pack v1 provides the first small before-and-after validation examples for safe early Atlas-based repair actions in F1, F4, and F7.**
**Tiny Validation Examples Pack v1 provides the first small before/after validation examples for safe early Atlas-based repair actions in F1, F4, and F7.**

203
ProblemMap/Atlas/Fixes/auto-repair/wfgy-3-0-deeper-continuation-quickstart-v1.md
View file

@ -1,36 +1,104 @@
# WFGY 3.0 Deeper Continuation Quickstart v1
<!--
AI_NOTE_START
## 0. Document status
Document role:
This file is the first quickstart guide for continuing a case from Atlas diagnosis and Auto Repair local action into WFGY 3.0 deeper continuation.
This document provides the first quickstart guide for continuing a case from:
How to use this file:
1. Read this page when Atlas routing and one local Auto Repair move have already happened, but the case still needs deeper structural work.
2. Use this page together with:
- [Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
- [Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
- [Worked Escalation Example v1](./worked-escalation-example-v1.md)
- [Worked Escalation Example F4 v1](./worked-escalation-example-f4-v1.md)
- [Auto Repair Integrated Handoff v1](./auto-repair-integrated-handoff-v1.md)
3. Use this page as a practical handoff guide for deeper continuation, not as a full explanation of the entire WFGY 3.0 system.
- Atlas diagnosis
- and Auto Repair local action
What this file is:
- A quickstart for deeper continuation after Atlas and Auto Repair
- A practical handoff guide for what to give the AI next
- A bridge document for moving from local repair into deeper WFGY 3.0 work
into:
What this file is not:
- Not the full WFGY 3.0 manual
- Not a claim that every case should escalate
- Not a replacement for Atlas routing or Auto Repair
- Not proof that deeper continuation always solves the case
- WFGY 3.0 deeper continuation
Reading discipline for AI:
- Preserve the layer split between Atlas, Auto Repair, and WFGY 3.0.
- Do not restart the case from scratch unless stronger reframing is clearly justified.
- Treat the local repair result as real signal, not as disposable noise.
- Use WFGY 3.0 only when local repair is useful but insufficient.
AI_NOTE_END
-->
# WFGY 3.0 Deeper Continuation Quickstart v1 🌊
## How to continue safely when Atlas-level local repair is useful but not enough
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
- [Open Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
- [Open Worked Escalation Example v1](./worked-escalation-example-v1.md)
- [Open Worked Escalation Example F4 v1](./worked-escalation-example-f4-v1.md)
- [Open Auto Repair Integrated Handoff v1](./auto-repair-integrated-handoff-v1.md)
---
If the bridge document explains **why WFGY 3.0 belongs after Atlas and Auto Repair**, this page explains **how to continue in the simplest practical way once local repair is no longer enough**. 🧭
Its purpose is practical:
> when local Atlas-level repair is useful but not sufficient,
> show users the simplest way to continue with WFGY 3.0.
> when local Atlas-level repair is useful but not sufficient,
> show users the simplest way to continue with WFGY 3.0
This file does **not** explain the full WFGY 3.0 system.
It explains something narrower and more useful:
> when to use WFGY 3.0 next,
> what to give the AI,
> and what kind of continuation to ask for.
> when to use WFGY 3.0 next,
> what to give the AI,
> and what kind of continuation to ask for
This document should be read together with:
---
- `atlas-auto-repair-to-wfgy-bridge-v1.md`
- `tiny-semi-auto-demo-pack-v1.md`
- `worked-escalation-example-v1.md`
- `worked-escalation-example-f4-v1.md`
- `auto-repair-integrated-handoff-v1.md`
## Quick start 🚀
### I want the shortest continuation path
Use this path:
1. route the case with Atlas
2. try one local Auto Repair move
3. validate the local result
4. if the result is only partial, stalled, or structurally shallow, attach the WFGY 3.0 TXT
5. ask the AI to continue from the deeper repair layer instead of restarting from scratch
### I want the stronger handoff path
Prepare a small bundle with:
1. Atlas result
2. local repair action
3. validation result
4. what still remains unresolved
5. the official WFGY 3.0 TXT
Short version:
> Atlas finds the region
> Auto Repair tries the first move
> WFGY 3.0 continues when deeper structure still needs work ✨
---
@ -56,6 +124,7 @@ This quickstart answers that question.
The clean role split is:
### Atlas
Use Atlas for:
- failure routing
@ -64,6 +133,7 @@ Use Atlas for:
- first repair direction
### Auto Repair
Use Auto Repair for:
- first controlled repair planning
@ -72,6 +142,7 @@ Use Auto Repair for:
- deciding whether local repair is enough
### WFGY 3.0
Use WFGY 3.0 for:
- deeper repair grammar
@ -89,7 +160,21 @@ Short version:
---
## 3. When to escalate to WFGY 3.0
## 3. Continuation quick map 🗂️
| Situation after local repair | Better next move |
|---|---|
| local repair clearly solved the issue | stay at Atlas and Auto Repair |
| local repair helped only partially | continue with WFGY 3.0 |
| local repair keeps ending in revise | continue with WFGY 3.0 |
| rollback repeats or local moves stay shallow | continue with WFGY 3.0 |
| routing is still weak or basic fix is still likely enough | do not escalate yet |
This page is the right place when the question is **how to hand the case into deeper continuation**, not whether WFGY 3.0 should replace the earlier layers.
---
## 4. When to escalate to WFGY 3.0
WFGY 3.0 should usually be used **after** Atlas and Auto Repair, not instead of them.
@ -130,11 +215,11 @@ Examples:
---
## 4. When not to escalate yet
## 5. When not to escalate yet
Do **not** jump into WFGY 3.0 too early.
Stay at the Atlas / Auto Repair layer first when:
Stay at the Atlas and Auto Repair layer first when:
- the case is still not cleanly routed
- a simple F1 repair is still likely enough
@ -149,19 +234,17 @@ Short version:
---
## 5. Official WFGY 3.0 TXT
## 6. Official WFGY 3.0 TXT
Use this official TXT as the deeper continuation asset:
```text
https://raw.githubusercontent.com/onestardao/WFGY/refs/heads/main/TensionUniverse/WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt
````
- [WFGY 3.0 Singularity Demo TXT](https://raw.githubusercontent.com/onestardao/WFGY/refs/heads/main/TensionUniverse/WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt)
This is the simplest official continuation object to hand to another AI system.
---
## 6. Minimum input bundle for continuation
## 7. Minimum input bundle for continuation
Before continuing into WFGY 3.0, prepare a small bundle with these parts.
@ -169,35 +252,35 @@ Before continuing into WFGY 3.0, prepare a small bundle with these parts.
Include:
* primary family
* secondary family
* broken invariant
* best current fit
* why primary not secondary
- primary family
- secondary family
- broken invariant
- best current fit
- why primary not secondary
### Part B · Auto Repair action
Include:
* action used
* what changed locally
* validation target
* validation result
* final local outcome
- action used
- what changed locally
- validation target
- validation result
- final local outcome
### Part C · Remaining problem
Include:
* what is still unresolved
* why local repair is not enough
* what kind of deeper issue seems to remain
- what is still unresolved
- why local repair is not enough
- what kind of deeper issue seems to remain
This is enough for a strong handoff.
---
## 7. Simplest user workflow
## 8. Simplest user workflow
The simplest workflow is:
@ -225,7 +308,7 @@ That is the cleanest usage pattern.
---
## 8. Short prompt for normal users
## 9. Short prompt for normal users
Use this when you want the simplest possible continuation prompt.
@ -247,11 +330,11 @@ Your task:
2. identify the deeper structural weakness,
3. suggest what stronger observables, encoding changes, mismatch logic, or experiment framing should be considered next,
4. keep the explanation structured and practical.
```
````
---
## 9. Slightly stronger prompt for advanced users
## 10. Slightly stronger prompt for advanced users
Use this when you want the AI to behave in a more disciplined bridge-aware way.
@ -273,7 +356,7 @@ Your job:
---
## 10. Recommended system prompt
## 11. Recommended system prompt
Use this when you want a reusable deeper-continuation system prompt.
@ -309,7 +392,7 @@ Your rules:
---
## 11. Recommended output structure
## 12. Recommended output structure
When asking the AI to continue with WFGY 3.0, it is useful to ask for this output shape:
@ -331,7 +414,7 @@ This output structure prevents the continuation from becoming vague.
---
## 12. Example continuation note
## 13. Example continuation note
A compact continuation note can look like this:
@ -350,7 +433,7 @@ This is often enough.
---
## 13. Best current use cases
## 14. Best current use cases
WFGY 3.0 deeper continuation is especially useful when the remaining problem looks like:
@ -366,7 +449,7 @@ That is where the bridge becomes most valuable.
---
## 14. What this quickstart does not claim
## 15. What this quickstart does not claim
This quickstart does **not** claim:
@ -382,7 +465,7 @@ It only claims:
---
## 15. Recommended next step
## 16. Recommended next step
Once this file exists, the next useful follow-up is probably one of these:
@ -398,7 +481,25 @@ because that will make the whole stack feel more unified for first-time readers.
---
## 16. One-line summary
## 17. Next steps ✨
After this page, most readers continue with:
1. [Open Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
2. [Open Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
3. [Open Worked Escalation Example v1](./worked-escalation-example-v1.md)
4. [Open Worked Escalation Example F4 v1](./worked-escalation-example-f4-v1.md)
5. [Open Auto Repair Integrated Handoff v1](./auto-repair-integrated-handoff-v1.md)
If you want the broader product surface:
* [Back to Auto Repair v1 README](./README.md)
* [Back to Fixes Hub](../README.md)
* [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
* [Back to Atlas Hub](../../README.md)
---
## 18. One-line summary 🌍
**WFGY 3.0 Deeper Continuation Quickstart v1 explains when local Atlas-level repair is not enough, what to hand to the AI next, and how to continue safely with WFGY 3.0.**

197
ProblemMap/Atlas/Fixes/auto-repair/worked-escalation-example-f4-v1.md
View file

@ -1,37 +1,115 @@
# Worked Escalation Example F4 v1
<!--
AI_NOTE_START
## 0. Document status
Document role:
This file provides the first F4-oriented worked escalation example for the Auto Repair layer inside the Atlas Fixes package.
This document defines the first F4-oriented worked escalation example for the Atlas Auto Repair layer.
How to use this file:
1. Read this page when you want to see a concrete case where Atlas routing and one local F4 repair move are both useful, but still not sufficient.
2. Use this page together with:
- [Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
- [Tiny Semi-Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
- [Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
- [Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Rollback Policy v1](./rollback-policy-v1.md)
- [Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Worked Escalation Example v1](./worked-escalation-example-v1.md)
3. Use this page as a worked escalation reference, not as a claim that every F4 case should escalate.
What this file is:
- A worked escalation example centered on an F4-first case
- A concrete bridge example from local closure repair into deeper WFGY continuation
- A reference case for explaining why local workflow repair can be real but still incomplete
What this file is not:
- Not a claim that all F4 cases need WFGY 3.0
- Not a replacement for Atlas routing
- Not proof that local closure repair is unimportant
- Not proof that WFGY 3.0 guarantees final success
Reading discipline for AI:
- Preserve the sequence Atlas first, Auto Repair second, WFGY 3.0 third.
- Treat the local F4 repair gain as real signal, not as disposable noise.
- Only escalate because the unresolved remainder is deeper than a local gate or closure patch.
- Keep the distinction clear between partial improvement and true structural stabilization.
AI_NOTE_END
-->
# Worked Escalation Example F4 v1 🧭
## A concrete F4-first case where local closure repair helps, but deeper continuation is still justified
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
- [Open WFGY 3.0 Deeper Continuation Quickstart v1](./wfgy-3-0-deeper-continuation-quickstart-v1.md)
- [Open Tiny Semi-Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
- [Open Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
- [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Open Rollback Policy v1](./rollback-policy-v1.md)
- [Open Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Open Worked Escalation Example v1](./worked-escalation-example-v1.md)
- [Open Auto Repair Integrated Handoff v1](./auto-repair-integrated-handoff-v1.md)
---
If the bridge document explains **why WFGY 3.0 belongs after Atlas and Auto Repair**, this page shows **what that transition looks like in one real F4-first worked example**.
Its purpose is specific:
> show one case where Atlas routing and a local F4 repair move are useful,
> but not sufficient,
> and where deeper continuation into WFGY 3.0 becomes justified.
> show one case where Atlas routing and a local F4 repair move are useful,
> but not sufficient,
> and where deeper continuation into WFGY 3.0 becomes justified
This file does **not** claim that every F4 case needs escalation.
It claims something narrower and more useful:
> some execution and contract failures can be improved locally first,
> but still require deeper structural continuation when local closure repair does not fully stabilize the case.
> some execution and contract failures can be improved locally first,
> but still require deeper structural continuation when local closure repair does not fully stabilize the case
This document should be read together with:
---
- `atlas-auto-repair-to-wfgy-bridge-v1.md`
- `tiny-semi-auto-demo-spec-v1.md`
- `tiny-semi-auto-demo-pack-v1.md`
- `repair-validation-loop-v1.md`
- `rollback-policy-v1.md`
- `safe-early-action-catalog-v1.md`
- `worked-escalation-example-v1.md`
## Quick start 🚀
### I want the shortest reading
Use this path:
1. read the case summary
2. inspect the Atlas routing
3. inspect the local planner output and selected F4 action
4. inspect the validation result
5. inspect why the final local outcome becomes `escalate`
### I want the stronger bridge reading
Use this page together with:
1. [Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
2. [WFGY 3.0 Deeper Continuation Quickstart v1](./wfgy-3-0-deeper-continuation-quickstart-v1.md)
3. [Worked Escalation Example v1](./worked-escalation-example-v1.md)
Short version:
> Atlas got the family right
> local F4 repair really helped
> validation showed that help was only partial
> the unresolved remainder now belongs to deeper continuation
---
## 1. Why this example exists
The current bridge already shows one worked escalation example centered on F7-like representational pressure.
The current bridge already shows one worked escalation example centered on more representational pressure.
That is useful, but incomplete.
@ -44,17 +122,31 @@ That reading would be too shallow.
This document exists to show a different but equally important pattern:
> Atlas and Auto Repair can improve execution closure locally,
> but some workflow failures still require deeper WFGY 3.0 continuation
> when the underlying rule system, observables, or effective-layer commitments remain structurally weak.
> Atlas and Auto Repair can improve execution closure locally,
> but some workflow failures still require deeper WFGY 3.0 continuation
> when the underlying rule system, observables, or effective-layer commitments remain structurally weak
In short:
> this is the first concrete example of why WFGY 3.0 matters after an F4-first local repair has already helped.
> this is the first concrete example of why WFGY 3.0 matters after an F4-first local repair has already helped
---
## 2. Escalation principle for F4
## 2. Worked escalation quick map 🗂️
| Layer | What happens in this example |
|---|---|
| Atlas | correctly routes the case into F4 first |
| Auto Repair | chooses a real local closure move that genuinely helps |
| Validation | shows the gain is only partial, not fake success |
| Escalation decision | concludes the unresolved remainder is deeper than a local gate problem |
| WFGY 3.0 | becomes the correct next layer for readiness, approval, obligation, and enforcement redesign |
This page is the right place when the question is **what an honest F4 escalation should look like**, not whether all workflow failures are secretly the same kind of case.
---
## 3. Escalation principle for F4
A good F4 worked escalation example should show all four of these:
@ -67,7 +159,7 @@ That is the standard for this file.
---
## 3. Chosen example
## 4. Chosen example
This example uses an F4-first case with neighboring F6 and F3 pressure.
@ -82,7 +174,7 @@ This makes the transition to WFGY 3.0 very clear.
---
## 4. Case summary
## 5. Case summary
### Case ID
@ -107,7 +199,7 @@ That is exactly the kind of case where escalation should become explicit.
---
## 5. Atlas routing layer
## 6. Atlas routing layer
### Routed diagnosis
@ -117,7 +209,7 @@ That is exactly the kind of case where escalation should become explicit.
- broken invariant: execution skeleton closure broken
- best current fit: `F4_E01 Institutional Enforcement Drift`
- local repair fit: `F4_GT_001` or `F4_CL_001`
- fix surface direction: readiness gate / closure hardening / rule-to-action trace
- fix surface direction: readiness gate, closure hardening, rule-to-action trace
- confidence: medium
- evidence sufficiency: medium
@ -137,7 +229,7 @@ That matters, because escalation into WFGY 3.0 should happen **after** correct f
---
## 6. Auto Repair planner layer
## 7. Auto Repair planner layer
### Planner output
@ -180,7 +272,7 @@ This is exactly what Auto Repair is supposed to do.
---
## 7. Local action layer
## 8. Local action layer
### Selected action
@ -214,7 +306,7 @@ It means the local move was **insufficient**.
---
## 8. Validation layer
## 9. Validation layer
### Validation result
@ -251,7 +343,7 @@ That is exactly where deeper continuation becomes rational.
---
## 9. Why local repair is not enough
## 10. Why local repair is not enough
This is the most important section in the file.
@ -277,7 +369,7 @@ That is the reason to escalate.
---
## 10. Escalation decision
## 11. Escalation decision
### Final local outcome
@ -299,7 +391,7 @@ It is escalation because the local repair layer has reached its honest limit.
---
## 11. WFGY 3.0 continuation rationale
## 12. WFGY 3.0 continuation rationale
At this point, WFGY 3.0 becomes the correct continuation layer because the remaining problem is no longer only:
@ -328,19 +420,17 @@ That is classic WFGY territory.
---
## 12. Official WFGY 3.0 continuation asset
## 13. Official WFGY 3.0 continuation asset
### Official TXT
```text
https://raw.githubusercontent.com/onestardao/WFGY/refs/heads/main/TensionUniverse/WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt
```
* [WFGY 3.0 Singularity Demo TXT](https://raw.githubusercontent.com/onestardao/WFGY/refs/heads/main/TensionUniverse/WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt)
This TXT should be treated as the official deeper continuation pack.
---
## 13. Recommended escalation handoff prompt
## 14. Recommended escalation handoff prompt
Use the following handoff pattern when escalating this case.
@ -375,7 +465,7 @@ This keeps the transition disciplined.
---
## 14. Recommended system prompt for escalation mode
## 15. Recommended system prompt for escalation mode
Use this if you want the AI to operate in a bridge-aware escalation mode for F4-like cases.
@ -400,7 +490,7 @@ Rules:
---
## 15. Worked escalation object
## 16. Worked escalation object
For compact reuse, the whole escalation can be summarized like this:
@ -430,7 +520,7 @@ For compact reuse, the whole escalation can be summarized like this:
---
## 16. Why this example matters
## 17. Why this example matters
This worked escalation example matters because it proves five things at once.
@ -459,7 +549,7 @@ This is extremely important for the overall architecture.
---
## 17. What this example does not claim
## 18. What this example does not claim
This example does **not** claim:
@ -471,13 +561,13 @@ This example does **not** claim:
It only claims:
> this is a case where local F4 repair was real, but deeper continuation was still justified.
> this is a case where local F4 repair was real, but deeper continuation was still justified
That is the correct scope.
---
## 18. Recommended next step
## 19. Recommended next step
Once this file exists, the next useful follow-up is probably one of these:
@ -493,6 +583,25 @@ because that would make the Atlas → Auto Repair → WFGY 3.0 bridge easier for
---
## 19. One-line summary
## 20. Next steps ✨
After this page, most readers continue with:
1. [Open WFGY 3.0 Deeper Continuation Quickstart v1](./wfgy-3-0-deeper-continuation-quickstart-v1.md)
2. [Open Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
3. [Open Worked Escalation Example v1](./worked-escalation-example-v1.md)
4. [Open Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
5. [Open Auto Repair Integrated Handoff v1](./auto-repair-integrated-handoff-v1.md)
If you want the broader product surface:
* [Back to Auto Repair v1 README](./README.md)
* [Back to Fixes Hub](../README.md)
* [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
* [Back to Atlas Hub](../../README.md)
---
## 21. One-line summary 🌍
**Worked Escalation Example F4 v1 shows how Atlas routing and local F4 repair can create a real local gain, while WFGY 3.0 becomes the correct deeper continuation layer when closure improvement remains structurally incomplete.**

202
ProblemMap/Atlas/Fixes/auto-repair/worked-escalation-example-v1.md
View file

@ -1,31 +1,108 @@
# Worked Escalation Example v1
<!--
AI_NOTE_START
## 0. Document status
Document role:
This file provides the first general worked escalation example for the Auto Repair layer inside the Atlas Fixes package.
This document defines the first worked escalation example for the Atlas Auto Repair layer.
How to use this file:
1. Read this page when you want one concrete case where Atlas routing and one local Auto Repair move are both useful, but still not sufficient.
2. Use this page together with:
- [Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
- [Tiny Semi-Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
- [Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
- [Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Rollback Policy v1](./rollback-policy-v1.md)
- [Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
3. Use this page as a worked escalation reference, not as a claim that every difficult case should escalate.
What this file is:
- The first general worked escalation example for Atlas → Auto Repair → WFGY 3.0
- A concrete bridge example from local repair into deeper continuation
- A reference case for showing why local repair can be real but still structurally incomplete
What this file is not:
- Not a claim that every difficult case must escalate
- Not a replacement for Atlas routing
- Not proof that local repair is weak or unimportant
- Not proof that WFGY 3.0 guarantees final closure
Reading discipline for AI:
- Preserve the sequence Atlas first, Auto Repair second, WFGY 3.0 third.
- Treat the local repair gain as real signal, not as disposable noise.
- Only escalate because the unresolved remainder is deeper than the first local repair layer.
- Keep the distinction clear between partial improvement and true structural stabilization.
AI_NOTE_END
-->
# Worked Escalation Example v1 🧭
## A concrete case where local repair helps, but deeper continuation is still justified
Quick links:
- [Back to Auto Repair v1 README](./README.md)
- [Back to Fixes Hub](../README.md)
- [Back to Official Fixes](../official/README.md)
- [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
- [Back to AI Eval Evidence](../../ai-eval-evidence.md)
- [Back to Atlas Hub](../../README.md)
- [Get the Atlas Router TXT](../../troubleshooting-atlas-router-v1.txt)
- [Open Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
- [Open WFGY 3.0 Deeper Continuation Quickstart v1](./wfgy-3-0-deeper-continuation-quickstart-v1.md)
- [Open Tiny Semi-Auto Demo Spec v1](./tiny-semi-auto-demo-spec-v1.md)
- [Open Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
- [Open Repair Validation Loop v1](./repair-validation-loop-v1.md)
- [Open Rollback Policy v1](./rollback-policy-v1.md)
- [Open Safe Early Action Catalog v1](./safe-early-action-catalog-v1.md)
- [Open Worked Escalation Example F4 v1](./worked-escalation-example-f4-v1.md)
---
If the bridge document explains **why WFGY 3.0 belongs after Atlas and Auto Repair**, this page shows **what that transition looks like in one concrete worked case**.
Its purpose is very specific:
> show one case where Atlas routing and a local Auto Repair move are useful,
> but not sufficient,
> and where deeper continuation into WFGY 3.0 becomes justified.
> show one case where Atlas routing and a local Auto Repair move are useful,
> but not sufficient,
> and where deeper continuation into WFGY 3.0 becomes justified
This document does **not** claim that every difficult case must escalate to WFGY 3.0.
It claims something narrower and more useful:
> some cases can be improved locally first,
> but still require deeper encoding, experiment, or structural continuation.
> some cases can be improved locally first,
> but still require deeper encoding, experiment, or structural continuation.
> This is where WFGY 3.0 becomes the correct next layer.
This document should be read together with:
---
- `atlas-auto-repair-to-wfgy-bridge-v1.md`
- `tiny-semi-auto-demo-spec-v1.md`
- `tiny-semi-auto-demo-pack-v1.md`
- `repair-validation-loop-v1.md`
- `rollback-policy-v1.md`
- `safe-early-action-catalog-v1.md`
## Quick start 🚀
### I want the shortest reading
Use this path:
1. read the case summary
2. inspect the Atlas routing
3. inspect the local planner output and selected action
4. inspect the validation result
5. inspect why the final local outcome becomes `escalate`
### I want the stronger bridge reading
Use this page together with:
1. [Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
2. [WFGY 3.0 Deeper Continuation Quickstart v1](./wfgy-3-0-deeper-continuation-quickstart-v1.md)
3. [Worked Escalation Example F4 v1](./worked-escalation-example-f4-v1.md)
Short version:
> Atlas got the first layer right
> local repair created a real gain
> validation showed that gain was only partial
> the unresolved remainder now belongs to deeper continuation
---
@ -41,31 +118,45 @@ The Atlas stack already shows:
But one crucial system question still remains:
> what does a real escalation look like
> what does a real escalation look like
> when local repair helps, but does not actually close the case?
This file exists to answer that.
In short:
> this is the first concrete example of why WFGY 3.0 matters after Atlas and Auto Repair have already done useful work.
> this is the first concrete example of why WFGY 3.0 matters after Atlas and Auto Repair have already done useful work
---
## 2. Escalation principle
## 2. Worked escalation quick map 🗂️
| Layer | What happens in this example |
|---|---|
| Atlas | correctly routes the case into F7 first |
| Auto Repair | chooses a real local shell repair that genuinely helps |
| Validation | shows the gain is only partial, not fake success |
| Escalation decision | concludes the unresolved remainder is deeper than a local shell fix |
| WFGY 3.0 | becomes the correct next layer for deeper representational and encoding continuation |
This page is the right place when the question is **what an honest escalation should look like**, not whether all difficult cases should automatically jump into WFGY 3.0.
---
## 3. Escalation principle
A worked escalation example should show all four of these:
1. Atlas routing was useful
2. Local repair was useful
3. Local repair was not enough
2. local repair was useful
3. local repair was not enough
4. WFGY 3.0 becomes justified for deeper continuation
If any of those four pieces are missing, the example is incomplete.
---
## 3. Chosen example
## 4. Chosen example
This first worked escalation example uses an F7-first case with neighboring F1 pressure.
@ -80,7 +171,7 @@ This makes the transition to WFGY 3.0 very clear.
---
## 4. Case summary
## 5. Case summary
### Case ID
@ -103,7 +194,7 @@ That is exactly the kind of case where escalation should be explicit.
---
## 5. Atlas routing layer
## 6. Atlas routing layer
### Routed diagnosis
@ -127,7 +218,7 @@ This is important, because escalation to WFGY 3.0 should happen **after correct
---
## 6. Auto Repair planner layer
## 7. Auto Repair planner layer
### Planner output
@ -164,7 +255,7 @@ This is exactly what Auto Repair is supposed to do.
---
## 7. Local action layer
## 8. Local action layer
### Selected action
@ -197,11 +288,11 @@ It means the local repair was **insufficient**.
---
## 8. Validation layer
## 9. Validation layer
### Validation result
```json id="jp7uw0"
```json id="njlwm7"
{
"validation_target": "schema validity",
"before_state_summary": "output structure was unstable and could not be consumed reliably",
@ -234,11 +325,11 @@ This is the exact kind of situation where a deeper continuation layer becomes me
---
## 9. Why local repair is not enough
## 10. Why local repair is not enough
This is the most important section in the whole example.
The local Atlas / Auto Repair action improved the shell.
The local Atlas and Auto Repair action improved the shell.
But the case still shows signs that the problem is deeper than shell repair alone.
@ -260,7 +351,7 @@ That is the reason to escalate.
---
## 10. Escalation decision
## 11. Escalation decision
### Final local outcome
@ -276,13 +367,13 @@ Escalation is correct because:
4. the unresolved remainder points to deeper structural inadequacy
5. further progress now benefits from WFGY 3.0 rather than repeated shallow shell edits
This is not escalation because the case is “interesting.”
This is not escalation because the case is interesting.
It is escalation because the local repair layer has reached its limit.
It is escalation because the local repair layer has reached its honest limit.
---
## 11. WFGY 3.0 continuation rationale
## 12. WFGY 3.0 continuation rationale
At this point, WFGY 3.0 becomes the correct continuation layer because the remaining problem is no longer only:
@ -311,23 +402,21 @@ That is classic WFGY territory.
---
## 12. Official WFGY 3.0 continuation asset
## 13. Official WFGY 3.0 continuation asset
### Official TXT
```text
https://raw.githubusercontent.com/onestardao/WFGY/refs/heads/main/TensionUniverse/WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt
```
* [WFGY 3.0 Singularity Demo TXT](https://raw.githubusercontent.com/onestardao/WFGY/refs/heads/main/TensionUniverse/WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt)
This TXT should be treated as the official deeper continuation pack.
---
## 13. Recommended escalation handoff prompt
## 14. Recommended escalation handoff prompt
Use the following handoff pattern when escalating this case.
```text id="0z7k4i"
```text id="vpkfj6"
The case below has already been routed through Problem Map 3.0 Troubleshooting Atlas.
Atlas result:
@ -359,11 +448,11 @@ This keeps the transition disciplined.
---
## 14. Recommended system prompt for escalation mode
## 15. Recommended system prompt for escalation mode
Use this if you want the AI to operate in a bridge-aware escalation mode.
```text id="brjlwm"
```text id="nk7w49"
You are continuing a case that has already passed through Atlas diagnosis and one local Auto Repair attempt.
Your job is not to redo Atlas from scratch.
@ -384,11 +473,11 @@ Rules:
---
## 15. Worked escalation object
## 16. Worked escalation object
For compact reuse, the whole escalation can be summarized like this:
```json id="4h83xa"
```json id="4zkjlwm"
{
"example_id": "WEE_F7_001",
"atlas_result": {
@ -414,7 +503,7 @@ For compact reuse, the whole escalation can be summarized like this:
---
## 16. Why this example matters
## 17. Why this example matters
This worked escalation example matters because it proves five things at once.
@ -442,7 +531,7 @@ That last point is especially important.
---
## 17. What this example does not claim
## 18. What this example does not claim
This example does **not** claim:
@ -460,7 +549,7 @@ That is the correct scope.
---
## 18. Recommended next step
## 19. Recommended next step
Once this file exists, the next useful follow-up is probably one of these:
@ -476,6 +565,25 @@ because that would show the bridge is not only about F7-style representational c
---
## 19. One-line summary
## 20. Next steps ✨
After this page, most readers continue with:
1. [Open Worked Escalation Example F4 v1](./worked-escalation-example-f4-v1.md)
2. [Open WFGY 3.0 Deeper Continuation Quickstart v1](./wfgy-3-0-deeper-continuation-quickstart-v1.md)
3. [Open Atlas Auto Repair to WFGY Bridge v1](./atlas-auto-repair-to-wfgy-bridge-v1.md)
4. [Open Tiny Semi-Auto Demo Pack v1](./tiny-semi-auto-demo-pack-v1.md)
5. [Open Auto Repair Integrated Handoff v1](./auto-repair-integrated-handoff-v1.md)
If you want the broader product surface:
* [Back to Auto Repair v1 README](./README.md)
* [Back to Fixes Hub](../README.md)
* [Back to Atlas landing page](../../../wfgy-ai-problem-map-troubleshooting-atlas.md)
* [Back to Atlas Hub](../../README.md)
---
## 21. One-line summary 🌍
**Worked Escalation Example v1 shows how Atlas routing and local Auto Repair can create a real local gain, while WFGY 3.0 becomes the correct deeper continuation layer when that local gain is still not enough.**