@rudinmax87/united-we-stand 0.1.0 → 0.1.2

package/.united-we-stand/README.md

@@ -171,6 +171,8 @@ How chat usage works:
 - broad start-of-work prompts should also default to `1-initializer` unless you explicitly ask for a later stage
 - if branch memory does not exist yet and you ask for direct code changes, the AI should warn that united-we-stand is not initialized and ask whether to proceed outside the framework for the current chat
 - once you confirm outside-framework work for the current chat, the AI should not ask that same confirmation again unless you later return to framework mode
+- when initialization is requested, the AI should always do a fresh live check of the current git branch before creating branch memory
+- it should not reuse an earlier branch check, earlier status output, or remembered branch context from the same chat as the initialization target
 - if the current branch is the detected default branch, initialization should warn and ask for confirmation before creating branch memory unless you explicitly use `--force`
 
 The workflow is mainly used in chat after installation:
@@ -283,7 +285,7 @@ Optional framework stages:
 - while workflow is active, `Current stage` should match the highest created numbered stage file in `.spec-driven/<branch-folder>/` among `01-init.md` through `06-finalization.md`; after explicit finalizer approval, closed workflow may use `Current stage = none`
 - if you ask to change planning, init, design, review, or finalization content, the AI should update that stage in place without creating the next stage
 - if you ask for earlier-stage work after the workflow has already moved forward, the AI should do that work without regressing `Current stage`, `Completed steps`, or `Incompleted stages`; it should record the stale downstream impact in status metadata instead
-- if a request could be interpreted as advancing through two or more phases at once, the AI should ask for confirmation first and explicitly list the phases it would run together
+- if a request could be interpreted as advancing through two or more phases at once, the AI should explain that united-we-stand only runs one stage at a time, suggest the next recommended numbered stage first, and ask the user to confirm one single stage
 - for branch-scoped work, the AI should stay inside `.spec-driven/<branch-folder>/` by default and update specs first unless you explicitly say otherwise
 - later stage files should be created when those stages are actually started or explicitly amended
 - `4-implementer` is the first framework stage allowed to change code

package/.united-we-stand/agents/0-status-checker.md

@@ -28,7 +28,7 @@ Establish reliable branch state and route the next action.
 - For stage amendment requests, preserve the anchored `Current stage` unless the user explicitly asks to advance, skip, or bypass.
 - If a lower stage was amended, do not treat that amendment as permission to create or populate a later stage.
 - If earlier-stage work was changed after the workflow had already moved forward, report the stale downstream areas in status output without regressing workflow metadata.
-- If a request could be interpreted as advancing through multiple stages at once, stop and ask for confirmation while naming the exact stages that would be run together.
+- If a request could be interpreted as advancing through multiple stages at once, stop, explain that united-we-stand only runs one stage at a time, and ask the user to confirm one single stage while suggesting the next recommended stage first.
 - Perform deterministic auto-correction for status contradictions when safe.
 - If auto-correction is made in `00-current-status.md`, include a brief note to user explaining what was corrected.
 

package/.united-we-stand/agents/1-initializer.md

@@ -23,6 +23,8 @@ None.
 - Convert user idea into initial branch definition.
 - Capture scope boundaries, assumptions, questions, and success criteria.
 - Capture out-of-scope explicitly to reduce downstream ambiguity.
+- When initialization is requested, always perform a fresh live check of the current git branch before creating or updating branch memory.
+- Do not rely on a previous branch check, previous status output, or remembered branch context from earlier in the same chat.
 - If branch memory does not exist yet and the user explicitly asks to initialize or init the work, create the branch spec for `1-initializer`.
 - If branch memory does not exist yet and the user uses natural bootstrap language such as `let's start this`, `help me with this idea`, `i want to build...`, or `let's work on...`, treat that as initialization intent by default.
 - If the current branch is detected as the repository default branch and branch memory does not exist yet, warn about default-branch risks and ask for confirmation before creating the branch spec unless the user explicitly used `--force` or equivalent force/bypass wording.
@@ -30,7 +32,7 @@ None.
 - If the user asks to modify initializer content, update `01-init.md` in place and keep `Current stage = 1-initializer` unless the user explicitly advances.
 - Do not create or populate planning content just because initializer content now looks complete.
 - Do not create `02-plan.md`, `03-design.md`, or any later-stage file from an initialization request alone.
-- If a user request could be interpreted as asking for initialization plus later stages in the same pass, ask for confirmation first and name the exact stages that would be executed.
+- If a user request could be interpreted as asking for initialization plus later stages in the same pass, do only `1-initializer`. Explain that united-we-stand only runs one stage at a time and ask the user to confirm a single later stage separately if they want to move on after initialization.
 
 ## Required Output (`01-init.md`)
 

package/.united-we-stand/agents/2-planner.md

@@ -23,6 +23,7 @@ Turn initialized intent into an actionable sequence.
 
 - Produce ordered plan, dependencies, and risk visibility.
 - Define suggested execution order and critical blockers.
+- Finish the planning step by reviewing and updating the full task list so it captures all work that still needs to be done.
 - Do not implement code.
 - If code/spec drift is observed, apply canonical conflict policy.
 - If the user asks to add or modify planning content, update `02-plan.md` in place.
@@ -32,10 +33,11 @@ Turn initialized intent into an actionable sequence.
 ## Required Output (`02-plan.md`)
 
 - Objectives
-- High-level task breakdown
 - Dependencies
 - Risks / unknowns
 - Suggested execution order
+- Detailed task list
+- Status
 
 ## Next-Step Status Rules
 

package/.united-we-stand/agents-md-block.md

@@ -29,11 +29,13 @@ This repository uses **united-we-stand**, a spec-driven AI workflow framework th
 - While workflow is active, `Current stage` must match the highest created numbered stage file present in `.spec-driven/<branch>/` among `01-init.md` through `06-finalization.md`; after explicit finalizer approval, closed workflow state may use `Current stage = none`.
 - Avoid deadlocks: when user intent is clear (`continue`, `implement`, `fix`, `review`), take the nearest safe action and keep status traceability updated.
 - Do not create, populate, or complete a higher-numbered stage just because the user amended the current stage.
-- If a request could reasonably mean advancing through two or more phases at once, do not infer permission. Ask for confirmation first and name the exact phases you would execute together, for example `1-initializer -> 2-planner -> 3-designer`.
+- If a request could reasonably mean advancing through two or more phases at once, do not infer permission and do not execute multiple stages. Explain that united-we-stand only runs one stage at a time, suggest the next recommended numbered stage first, and ask the user to confirm one single stage to run now.
 - Do not assume missing stage files are completed.
 - Do not create branch state folders preemptively; `branch-init` or an explicit user initialization request should create them.
 - If branch memory does not exist yet, natural start-of-work requests such as `let's start this`, `help me with this idea`, or `i want to build...` should default to `1-initializer`.
 - If branch memory does not exist yet, explicit init requests such as `init the following`, `initialize this`, `let's init this`, `help me with the following idea, i want...`, `let's start building this`, `i want to build...`, `i want to create...`, or `let's work on...` should be treated as permission to create the branch spec and start `1-initializer`.
+- When initialization is requested, always perform a fresh live check of the current git branch before creating branch memory.
+- Never reuse an earlier branch check, earlier status output, or remembered branch context from the same chat as the initialization target.
 - If branch memory does not exist yet and the user asks for concrete code changes or other persistent repo work without explicitly asking to initialize, warn that united-we-stand is not initialized for the branch and ask whether to proceed outside the framework instead of inferring a numbered stage.
 - If the user confirms outside-framework work, continue outside the framework for the rest of the current chat and do not ask for the same confirmation again unless the user later asks to initialize or return to normal framework flow.
 - If branch memory does not exist yet and the current branch is detected as the repository default branch, explicit init requests must warn about default-branch risks and ask for confirmation before creating `.spec-driven/...` files unless the user explicitly uses `--force`.

package/.united-we-stand/antigravity-workflow.md

@@ -10,6 +10,8 @@ Before acting:
 
 If branch memory does not exist yet and the user asks for concrete code changes or other persistent repo work without explicitly asking to initialize the framework, warn that united-we-stand is not initialized for the branch and ask whether to proceed outside the framework for the current chat.
 
+When initialization is requested, always perform a fresh live check of the current git branch before creating branch memory. Do not rely on a previous branch check, previous status output, or remembered branch context from earlier in the same chat.
+
 If branch memory does not exist yet and the current branch is detected as the repository default branch, explicit init requests must warn about default-branch risks and ask for confirmation before creating `.spec-driven/...` files unless the user explicitly uses `--force`.
 
 For the most reliable natural-language initialization when branch memory does not exist yet, reference any installed united-we-stand file together with the init request, for example `AGENTS.md initialize this`.

package/.united-we-stand/copilot-instructions.md

@@ -10,6 +10,8 @@ Before acting:
 
 If branch memory does not exist yet and the user asks for concrete code changes or other persistent repo work without explicitly asking to initialize the framework, warn that united-we-stand is not initialized for the branch and ask whether to proceed outside the framework for the current chat.
 
+When initialization is requested, always perform a fresh live check of the current git branch before creating branch memory. Do not rely on a previous branch check, previous status output, or remembered branch context from earlier in the same chat.
+
 If branch memory does not exist yet and the current branch is detected as the repository default branch, explicit init requests must warn about default-branch risks and ask for confirmation before creating `.spec-driven/...` files unless the user explicitly uses `--force`.
 
 For the most reliable natural-language initialization when branch memory does not exist yet, reference any installed united-we-stand file together with the init request, for example `AGENTS.md initialize this`.

package/.united-we-stand/cursor-rule.mdc

@@ -13,6 +13,8 @@ Before acting:
 
 If branch memory does not exist yet and the user asks for concrete code changes or other persistent repo work without explicitly asking to initialize the framework, warn that united-we-stand is not initialized for the branch and ask whether to proceed outside the framework for the current chat.
 
+When initialization is requested, always perform a fresh live check of the current git branch before creating branch memory. Do not rely on a previous branch check, previous status output, or remembered branch context from earlier in the same chat.
+
 If branch memory does not exist yet and the current branch is detected as the repository default branch, explicit init requests must warn about default-branch risks and ask for confirmation before creating `.spec-driven/...` files unless the user explicitly uses `--force`.
 
 For the most reliable natural-language initialization when branch memory does not exist yet, reference any installed united-we-stand file together with the init request, for example `AGENTS.md initialize this`.

package/.united-we-stand/framework/01-core-rules.md

@@ -4,91 +4,94 @@ This file is the canonical source for global framework invariants.
 
 ## Non-Negotiable Rules
 
-1. **Spec-driven development**  
+1. **Spec-driven development**
    Branch specs are authoritative working memory for workflow state.
 
-2. **User intent precedence (User is King and Spec is Truth)**  
+2. **User intent precedence (User is King and Spec is Truth)**
    Latest confirmed user intent has highest authority. When intent changes direction, update relevant specs first, then update code if role allows.
 
-3. **Branch-aware operation**  
+3. **Branch-aware operation**
    All framework work is branch-aware and uses `.spec-driven/<sanitized-current-branch>/`.
 
-4. **Persistent context over chat memory**  
+4. **Persistent context over chat memory**
    Persisted framework files outrank remembered chat state when conflict exists.
 
-5. **No silent stage jumps**  
+5. **No silent stage jumps**
    Respect prerequisites and anchored stage model. Optional stages may be skipped only with explicit user instruction or `--force` behavior.
 
-6. **No hallucinated completion**  
+6. **No hallucinated completion**
    Missing stage files are not proof of completed work.
 
-7. **Role-scoped edits only**  
+7. **Role-scoped edits only**
    Agents may edit only files allowed by role scope and explicit user instruction.
 
-8. **Spec first, then code**  
+8. **Spec first, then code**
    If user changes intent, update spec context first, then code.
 
-9. **No autonomous git operations**  
+9. **No autonomous git operations**
    Never run `git add`, `git commit`, `git push`, `git rebase`, `git reset`, or branch-switch operations unless user explicitly requests it.
 
-10. **Status-first resumption**  
+10. **Status-first resumption**
     Resumed chats must consult `00-current-status.md` before deciding the next action.
 
-11. **Deterministic routing**  
+11. **Initialization requires a fresh live branch check**
+    When the user asks to initialize, always perform a fresh live check of the current git branch at that moment. Do not rely on a previous branch check, previous status output, or remembered chat context from earlier in the same chat.
+
+12. **Deterministic routing**
     Natural-language command routing must follow `04-command-routing.md`.
 
-12. **Runtime memory isolation**  
+13. **Runtime memory isolation**
     Treat `.united-we-stand/` as installed framework content. Runtime branch memory writes must target `.spec-driven/` only.
 
-13. **Detached HEAD safety**  
+14. **Detached HEAD safety**
     Never attach branch memory to `head`. If branch detection is detached/ambiguous, require an explicit branch name before writing branch memory.
 
-14. **Branch-folder collision safety**  
+15. **Branch-folder collision safety**
     When creating new branch memory, if target folder already exists and is not already linked to the same branch, require explicit user confirmation or a different folder name.
 
-15. **Branch exception routing**  
+16. **Branch exception routing**
     If a branch uses a non-default memory folder, persist that exception in `.spec-driven/.branch-routing.json` and use it for subsequent branch-folder resolution.
 
-16. **No implicit advancement from edit requests**  
+17. **No implicit advancement from edit requests**
     Requests to add, modify, remove, clarify, or fix content inside a stage are amendment requests for that stage unless the user explicitly asks to advance, skip, or bypass.
 
-17. **No downstream stage creation from in-stage amendments**  
+18. **No downstream stage creation from in-stage amendments**
     Editing one stage must not create, complete, or populate a higher-numbered stage unless the user explicitly requests that higher stage or explicitly advances the workflow.
 
-18. **Branch-scoped work stays in spec by default**  
+19. **Branch-scoped work stays in spec by default**
     If a request is branch-scoped and requires persistent work, operate through `.spec-driven/<branch>/` by default. Read and update the relevant spec files first unless the user explicitly says not to, or the request is unrelated, informational only, or does not require repository/spec changes.
 
-19. **Never auto-advance stages**  
-    Never advance from one stage to the next automatically. A stage may become complete, but it must remain anchored until the user explicitly advances or explicitly confirms a bypass.
+20. **Never auto-advance stages**
+    Never advance from one stage to the next automatically. A stage may become complete, but it must remain anchored until the user explicitly advances or explicitly confirms a bypass to one specific stage.
 
-20. **Multi-stage advancement requires confirmation**  
-    If a request could reasonably be interpreted as advancing through two or more stages in one go, do not proceed on inference alone. Ask for confirmation first and explicitly name the stages that would be run in the same pass.
+21. **Only one framework stage may run at a time**
+    Never execute, advance, skip across, or initialize multiple framework stages in the same pass. If a request could reasonably be interpreted as involving two or more stages, explain the one-stage-at-a-time rule and ask the user to confirm one single stage, suggesting the next recommended numbered stage first.
 
-21. **No backward stage regression**  
+22. **No backward stage regression**
     `Current stage` is a monotonic workflow progress tracker. Earlier-stage work may be amended later, but `Current stage`, `Completed steps`, and `Incompleted stages` must not move backward to an earlier numbered stage.
 
-22. **Backward work must be recorded, not re-anchored**  
+23. **Backward work must be recorded, not re-anchored**
     If the user requests planning, design, or implementation work after the workflow has already advanced past that stage, perform the requested work, update the relevant earlier stage files in place, and preserve the later `Current stage`. Record the impact in status metadata so downstream stale work is visible.
 
-23. **Stage metadata must match created stage files**  
+24. **Stage metadata must match created stage files**
     Workflow metadata is not independent from the branch folder contents. `Current stage` must always match the highest existing numbered stage file among `01-init.md` through `06-finalization.md`, and status checks must validate that alignment.
 
-24. **No implicit framework entry when branch memory is missing**  
+25. **No implicit framework entry when branch memory is missing**
     If branch memory does not exist yet and the user requests concrete code changes or other persistent work without explicitly asking to initialize the framework, do not silently enter a numbered framework stage. Warn that united-we-stand is not initialized for the branch and ask whether to proceed outside the framework.
 
-25. **Outside-framework confirmation is sticky for the current chat**  
+26. **Outside-framework confirmation is sticky for the current chat**
     If the user confirms that the work should continue outside the framework, continue helping outside the framework for the rest of the current chat without asking for the same confirmation again unless the user later asks to initialize or return to normal framework flow.
 
-26. **Finalizer requires explicit closure confirmation**  
+27. **Finalizer requires explicit closure confirmation**
     `6-finalizer` never treats itself as definitively done on its own. It must surface final observations, ask the user to confirm that the final state is acceptable, and only then close the workflow.
 
-27. **Closed workflow uses `Current stage = none`**  
+28. **Closed workflow uses `Current stage = none`**
     After explicit user closure confirmation, the branch workflow becomes closed rather than anchored to an active numbered stage. In that closed state, `Current stage = none`, `Next recommended step = none`, and `6-finalizer` is recorded as completed.
 
-28. **Post-closure work reopens finalizer**  
+29. **Post-closure work reopens finalizer**
     If the workflow was explicitly closed and the user later requests more branch changes, reopen `6-finalizer` as the current stage, clear closed/finalized state, and require finalization approval again after the new work is incorporated.
 
-29. **Default-branch initialization requires confirmation**  
+30. **Default-branch initialization requires confirmation**
     If the current branch is detected as the repository default branch and branch memory does not yet exist, explicit initialization requests must warn about default-branch risks and ask for confirmation before creating `.spec-driven/...` files. Explicit `--force` semantics are the only bypass for that confirmation.
 
 ## Stage Mandatory Set

package/.united-we-stand/framework/02-state-model.md

@@ -68,12 +68,13 @@
   - keep any earlier explicitly used stages in `Completed steps` if they were already completed and are no longer current
   - ensure every recorded completed or incompleted stage has its corresponding stage document present in `.spec-driven/<branch>/`
 
-## Multi-Stage Advancement Confirmation Rule
+## One-Stage-At-A-Time Rule
 
 - Never infer permission to cross two or more stages from broad outcome wording alone.
-- If a request could mean "do planning, design, and implementation" or any other multi-stage jump, pause and ask for confirmation before changing stage state or creating later-stage files.
-- The confirmation must name the exact stages that would be advanced or executed in the same pass.
-- Without that confirmation, keep `Current stage` anchored and perform only the nearest safe in-stage work.
+- If a request could mean `do planning, design, and implementation` or any other multi-stage jump, do not run multiple stages.
+- Explain that united-we-stand only runs one stage at a time.
+- Ask the user to confirm one single stage, suggesting the next recommended numbered stage first.
+- Without that single-stage confirmation, keep `Current stage` anchored and perform only the nearest safe in-stage work.
 
 ## Category Invariants
 

package/.united-we-stand/framework/03-stage-lifecycle.md

@@ -51,9 +51,11 @@ Explicit user closure confirmation after `6-finalizer` is the trigger that moves
 ## Multi-Stage Requests
 
 - Never auto-advance, even if the next stage seems obvious.
-- If a request could be read as advancing through two or more stages at once, ask for confirmation before proceeding.
-- The confirmation must list the exact stages to be executed together.
-- Until the user confirms, keep the workflow anchored in the current stage.
+- If a request could be read as advancing through two or more stages at once, do not run multiple stages.
+- Explain that united-we-stand only runs one stage at a time.
+- Suggest the next recommended numbered stage first.
+- Ask the user to confirm one single stage to run now.
+- Until the user confirms that single stage, keep the workflow anchored in the current stage.
 
 ## Resumption Inputs
 

package/.united-we-stand/framework/04-command-routing.md

@@ -45,7 +45,7 @@ Route to `0-status-checker`.
 2. If current stage completed and prerequisites pass: advance to next numbered stage.
 3. If current stage unfinished: report blocker unless user explicitly skips or uses force semantics.
 
-Progression commands move only one stage at a time unless the user explicitly confirms a broader bypass.
+Progression commands move only one stage at a time.
 
 ## Stage Amendment Commands
 
@@ -117,11 +117,13 @@ Examples:
 
 If the user explicitly asks to initialize or init the work and branch memory does not exist yet:
 
-1. Treat that as explicit permission to create the branch spec under `.spec-driven/<branch>/`.
-2. Create or initialize the branch runtime files needed for `1-initializer`.
-3. Capture the user-provided intent in `01-init.md`.
-4. Keep the workflow anchored in `1-initializer` unless the user explicitly advances.
-5. Still enforce detached HEAD safety and branch-folder collision safety.
+1. Perform a fresh live check of the current git branch at the moment initialization is requested.
+2. Do not rely on a previous branch check, previous status output, or remembered chat context from earlier in the same chat.
+3. Treat that live branch result as the explicit target for `.spec-driven/<branch>/`.
+4. Create or initialize the branch runtime files needed for `1-initializer`.
+5. Capture the user-provided intent in `01-init.md`.
+6. Keep the workflow anchored in `1-initializer` unless the user explicitly advances.
+7. Still enforce detached HEAD safety and branch-folder collision safety.
 
 Initialization bootstrap does not grant permission to pre-create or populate planning, design, implementation, review, or finalization files.
 
@@ -167,7 +169,7 @@ If branch memory does not exist yet and the user requests concrete code changes
 3. ask whether to proceed outside the framework for the current chat
 4. if the user confirms outside-framework work, continue normally outside the framework and do not repeat the same confirmation again in that chat unless the user later asks to initialize or return to framework mode
 5. if the user explicitly asks to initialize instead, create branch memory and start `1-initializer`
-6. if the user explicitly asks to start the framework from a later stage or uses force/bypass semantics, require confirmation of the exact stage path before proceeding
+6. if the user explicitly asks to start the framework from a later stage or uses force/bypass semantics, require confirmation of one exact target stage before proceeding
 
 This one-time outside-framework confirmation stays sticky on the default branch too. Do not keep re-asking in the same chat once the user already chose to continue outside the framework.
 
@@ -213,16 +215,17 @@ When branch memory exists and user requests implementation and stages `2-planner
 - ask confirmation before direct implementation
 - proceed only with explicit user confirmation or force bypass semantics
 
-## Multi-Stage Confirmation Rule
+## Multi-Stage Request Rule
 
 If a request could reasonably be interpreted as advancing or executing two or more stages in one pass:
 
 1. do not proceed on interpretation alone
-2. ask for confirmation first
-3. list the exact stages that would be run together
-4. proceed only after the user confirms that grouped phase execution
+2. explain that united-we-stand only runs one stage at a time
+3. suggest the next recommended numbered stage first
+4. ask the user to confirm one single stage to run now, or to name another single stage to force
+5. do not run grouped phase execution even if the original request names multiple stages
 
-Examples that require confirmation when they would skip across multiple stages:
+Examples that require single-stage clarification:
 
 - `leave everything ready to start testing`
 - `take this from init all the way to implementation`
@@ -246,6 +249,7 @@ If a user says short commands such as `continue`, `fix it`, `implement this`, or
 - perform the nearest safe action for the active/target stage
 - update status fields so the workflow remains traceable
 - ask for explicit confirmation when bypassing prerequisites, when a request could jump across two or more stages, or when making risky/destructive changes
+- when such a request implies multiple stages, ask for one single stage only and suggest the next recommended numbered stage first
 - do not treat `fix this in planning`, `update init`, or similar stage amendment requests as permission to advance stages
 - do not treat an earlier-stage direct command from a later stage as permission to regress workflow metadata
 

package/.united-we-stand/framework/06-spec-writing-standard.md

@@ -57,10 +57,11 @@ Required fields:
 ### `02-plan.md`
 
 - Objectives
-- High-level task breakdown
 - Dependencies
 - Risks / unknowns
 - Suggested execution order
+- Detailed task list
+- Status
 
 ### `03-design.md`
 

package/.united-we-stand/framework/08-skip-force-policy.md

@@ -9,7 +9,7 @@ Follow stages in order unless user explicitly requests skip/bypass.
 `--force` means explicit override of normal prerequisite/progression behavior.
 
 Force/bypass must never be inferred from broad delivery language alone.
-If a request could imply skipping or combining two or more stages, require explicit confirmation and name the affected stages before proceeding.
+If a request could imply skipping or combining two or more stages, explain the one-stage-at-a-time rule and require the user to confirm one exact target stage before proceeding.
 
 When force/bypass is applied:
 

package/.united-we-stand/spec-driven/branch-template/02-plan.md

@@ -6,9 +6,6 @@ Turn the initialized idea into an ordered execution plan.
 ## Objectives
 TBD
 
-## High-level task breakdown
-TBD
-
 ## Dependencies
 TBD
 
@@ -16,4 +13,10 @@ TBD
 TBD
 
 ## Suggested execution order
-TBD
+TBD
+
+## Detailed task list
+TBD
+
+## Status
+TBD