add disciplines

Author: karaposu

agent/README.md

@@ -54,37 +54,32 @@ Each of the six agents operates at one layer, in one intent mode, at one autonom
 
 ## The Problem
 
-Every AI coding tool today is essentially a single agent operating at one layer (Action-Set) in one mode (a degraded Alignment). "Given this context, generate this code." They have some workspace awareness (codebase indexing) but almost no task depth checking, no coherence monitoring, and no outcome verification. And critically — no mode awareness at all.
-
-This works when:
-- Tasks are small and self-contained
-- A human reviews every output
-- Mistakes are cheap to fix
-
-This fails when:
-- Tasks are complex and span multiple modules
-- The AI works autonomously for extended periods
-- Mistakes compound silently
-- The situation requires a different posture than "generate code"
-
-The failure modes are predictable because they map to unmonitored layers AND missing modes:
-
-**Layer failures:**
-- AI breaks existing features → no coherence monitoring (layer 5)
-- AI builds the wrong thing → no task depth understanding (layer 2)
-- AI picks a bad approach → no action-space evaluation (layer 3)
-- AI generates code in a stale context → no workspace monitoring (layer 1)
-- AI finishes but the result doesn't match intent → no outcome verification (layer 6)
-
-**Mode failures:**
-- AI builds on a codebase it doesn't understand → should be in Exploration, locked in Alignment
-- AI force-fits a known pattern when the problem needs a novel approach → should be in Innovation, locked in Alignment
-- AI keeps building after something broke → should be in Diagnostic, locked in Alignment
-- AI never stops to reflect on what was accomplished → no Reflection mode at all
-- AI lets documentation rot → no Maintenance mode at all
+Current AI coding tools are not lacking in capability. They can explore codebases, generate plans, write code, and sometimes check for issues. The raw ability is there. What's missing is **a philosophy of what development actually is** — a structural understanding of the dimensions, modes, and transitions that make development work.
+
+Without this philosophy, tools operate ad-hoc. They explore when they happen to, plan when prompted, check coherence sometimes, and never reflect. They have workspace awareness (codebase indexing) but no methodology for when to use it. They can generate code but have no model for when generation is the wrong posture — when exploration, innovation, diagnosis, or reflection is what the situation actually demands.
+
+The problem is not missing capabilities. It's **missing structure and methodology.** The same tools, guided by a structural understanding of development, would behave fundamentally differently.
+
+This is the thesis AlignStack is built on: as AI capabilities converge, the differentiator shifts from raw ability to the methodology that guides it. Current tools have the ability. They lack the framework.
+
+**What this looks like in practice:**
+
+Layer-level failures (the tool has the capability but doesn't apply it systematically):
+- AI breaks existing features → coherence checking exists but isn't continuous (layer 5)
+- AI builds the wrong thing → task understanding is shallow, no depth/scope model (layer 2)
+- AI picks a bad approach → approach evaluation is ad-hoc, not structured (layer 3)
+- AI generates code in a stale context → workspace awareness exists but isn't monitored (layer 1)
+- AI finishes but the result doesn't match intent → no systematic outcome verification (layer 6)
+
+Mode-level failures (the tool has no concept of modes at all):
+- AI builds on a codebase it doesn't understand → should be in Exploration, defaults to Alignment
+- AI force-fits a known pattern when the problem needs a novel approach → should be in Innovation, stuck in Alignment
+- AI keeps building after something broke → should be in Diagnostic, stuck in Alignment
+- AI never stops to reflect on what was accomplished → no Reflection mode
+- AI lets documentation rot → no Maintenance mode
 - AI diagnoses problems but can't fix them → no Recovery mode
 
-The pattern: current tools are **mode-blind**. They operate in one mode regardless of what the situation demands. This is as limiting as being layer-blind.
+The pattern: current tools are **mode-blind and methodology-free**. They have capabilities across multiple layers but no structured philosophy for when and how to apply them. They operate in one posture regardless of what the situation demands. AlignStack Agent provides the missing structure.
 
 ---
 

agent/frameworklist.md

@@ -0,0 +1,181 @@
+# AlignStack Thinking Disciplines
+
+Thinking Disciplines are natural cognitive operations — borrowed from how humans actually think — formalized into repeatable structures with defined components, processes, and failure modes. They are domain-agnostic: each one works for coding, business, design, research, or any field where that type of thinking is needed.
+
+They are not frameworks (too generic), not tools (too mechanical), not tips (too shallow). They are practiced methodologies for specific cognitive tasks — like martial arts disciplines are practiced methodologies for specific physical situations. You study them, use them, and get better at them over time.
+
+Each thinking discipline has: a philosophy/definition, structural components, a process, failure modes, and a coverage or quality strategy. Each one transforms a specific cognitive state into another.
+
+---
+
+## Built
+
+### 1. Structural Sensemaking
+
+**Transform:** Ambiguity → Stable understanding
+
+**What it is:** A systematic process for constructing stable meaning from vague, ambiguous, or complex input. Works by organizing cognitive anchors into constrained conceptual structures through perspective integration, ambiguity collapse, and degrees-of-freedom reduction.
+
+**Components:** Cognitive anchors (constraints, insights, structural points, principles, meaning-nodes), boundary construction operations (perspective checking, ambiguity collapse, degrees-of-freedom reduction), six progressive Sense Versions (SV1–SV6).
+
+**Command:** `/sense-making`
+**Files:** `commands/sense-making.md`
+
+---
+
+### 2. Structural Innovation
+
+**Transform:** Seed → Novel viable ideas
+
+**What it is:** A framework for producing novelty through systematic mechanism application. Seven mechanisms (4 Generators + 3 Framers) cover the innovation space. Intuition provides direction, mechanisms provide coverage, testing catches blind spots of both.
+
+**Components:** Intuition (context, valuation, motivation), seeds, seven mechanisms (Lens Shifting, Combination, Inversion, Constraint Manipulation, Absence Recognition, Domain Transfer, Extrapolation), Generator/Framer split, five testing criteria, six failure modes.
+
+**Command:** `/innovate`
+**Files:** `commands/innovate.md`, `devdocs/inno/innovaiton_framework.md`, `devdocs/inno/intuiton.md`
+
+---
+
+## To Build
+
+### 3. Structural Critique
+
+**Transform:** Plan or idea → Identified risks, errors, and conflicts
+
+**What it is:** A framework for systematically evaluating plans, designs, and ideas to find what could go wrong. Not nitpicking — finding the risks that actually matter. The `/critic` and `/critic-d` commands already do this but have no formal framework defining what good critique IS, what its failure modes are, or how to ensure coverage.
+
+**Components to define:**
+- What are the dimensions of critique? (correctness, coherence, feasibility, completeness, security, performance — are there others?)
+- What's the coverage strategy? (how do you know you've checked enough dimensions?)
+- What's the severity model? (how to distinguish noise from real risks)
+- What are the failure modes of bad critique? (rubber-stamping, nitpicking, missing systemic risks, severity inflation, checking the plan instead of the assumptions behind the plan)
+
+**Existing commands:** `/critic`, `/critic-d`
+**Priority:** High — used constantly, currently ad-hoc
+
+---
+
+### 4. Structural Decomposition
+
+**Transform:** Complex whole → Manageable independent parts
+
+**What it is:** A framework for breaking complex tasks, systems, or problems into pieces that can be worked on independently. The #1 bottleneck for long autonomous tasks — bad decomposition means pieces that can't be implemented independently, hidden dependencies that surface mid-build, and compounding errors across subtasks.
+
+**Components to define:**
+- How to detect natural boundaries (where does one piece end and another begin?)
+- How to verify independence (can piece A be built without piece B existing?)
+- How to map dependencies (what ordering constraints exist?)
+- How to size pieces (when is a piece too big? too small?)
+- What are the failure modes? (premature decomposition before understanding, splitting at the wrong boundaries, hidden coupling between "independent" pieces, uniform sizing that ignores natural complexity variation)
+
+**Existing commands:** `/decompose` (planned, not yet built)
+**Priority:** High — the bottleneck for every complex task
+
+---
+
+### 5. Structural Diagnosis
+
+**Transform:** Failure → Root cause localization
+
+**What it is:** A framework for systematically finding where and why things went wrong. Not "what broke" but "why it broke, at which layer, through what causal chain." Every debugging session needs this — currently it's pure intuition and grep.
+
+**Components to define:**
+- Symptom detection (what's the observable failure?)
+- Hypothesis generation (what could cause this?)
+- Hypothesis testing (how to confirm or eliminate each hypothesis?)
+- Root cause isolation (distinguishing symptoms from causes, proximate causes from root causes)
+- Layer attribution (which alignment layer did the failure originate at?)
+- What are the failure modes? (treating symptoms not causes, stopping at the first explanation, misattributing the layer, confirmation bias toward familiar bugs, assuming the most recent change is the cause)
+
+**Existing commands:** `/verify`, `/probe` (planned)
+**Priority:** High — every debugging session, currently unstructured
+
+---
+
+### 6. Structural Exploration
+
+**Transform:** Unknown territory → Mapped understanding
+
+**What it is:** A framework for systematically mapping unfamiliar territory — codebases, domains, problem spaces. Different from Sensemaking (which clarifies what's ambiguous) — Exploration maps what's unknown. You don't know what you don't know; the framework gives you a method for discovering it.
+
+**Components to define:**
+- Breadth-first scan (what exists at the surface level?)
+- Depth probes (where should we go deeper?)
+- Boundary detection (where does this territory end?)
+- Knowledge gap identification (what do we NOT know after scanning?)
+- Confidence mapping (what are we sure about, what's uncertain, what's unknown?)
+- What are the failure modes? (exploring too deep before scanning breadth, mistaking surface understanding for deep understanding, stopping exploration when it feels "enough" rather than when gaps are closed)
+
+**Existing commands:** `/arch-small-summary`, `/arch-intro`, `/arch-traces`, `/arch-traces-2`
+**Priority:** Medium — the archaeology commands work well, but a framework would make them more principled
+
+---
+
+### 7. Structural Reflection
+
+**Transform:** Completed work → Extracted patterns and insights
+
+**What it is:** A framework for learning from what was done. Not just "what happened" (that's a report) but "what does it mean, what patterns emerged, what should change going forward." The meta-process that makes all other processes improve over time.
+
+**Components to define:**
+- Timeline reconstruction (what actually happened, in what order?)
+- Pattern extraction (what repeated? what was surprising? what was predicted correctly/incorrectly?)
+- Decision evaluation (which decisions were good? which looked good but weren't? which looked bad but were right?)
+- Trajectory identification (where is the project heading based on the arc of work, not just the latest commit?)
+- What are the failure modes? (recency bias, success bias, confusing activity with progress, reflecting on what was done instead of what was learned)
+
+**Existing commands:** `/overview-report`, `/compare-intent` (planned)
+**Priority:** Medium — valuable but less frequently needed than critique, decomposition, diagnosis
+
+---
+
+### 8. Structural Recovery
+
+**Transform:** Broken state → Restored function
+
+**What it is:** A framework for systematically getting back to a known-good state after a failure. Where Diagnosis finds the problem, Recovery fixes it — with minimum collateral damage and maximum confidence that the fix is complete.
+
+**Components to define:**
+- Damage assessment (what exactly is broken? what still works?)
+- Known-good state identification (what are we restoring TO?)
+- Rollback vs forward-fix decision (revert or patch?)
+- Minimal fix path (smallest change that restores function)
+- Verification of restoration (how do we confirm it's actually fixed?)
+- What are the failure modes? (incomplete recovery, fixing the symptom not the cause, introducing new problems during recovery, restoring to a state that was already degraded)
+
+**Existing commands:** None — identified gap
+**Priority:** Lower — important but more operational than philosophical
+
+---
+
+### 9. Structural Evaluation
+
+**Transform:** Output → Intent comparison
+
+**What it is:** A framework for verifying that what was built matches what was intended. Not "does it work?" (that's testing) but "does it do what was asked for?" Catches the case where implementation is correct but doesn't match intent — the right code for the wrong problem.
+
+**Components to define:**
+- Intent extraction (what was actually asked for? success criteria, implied requirements, unstated expectations)
+- Output mapping (what was actually built? what does it do?)
+- Gap analysis (what was asked but not built? what was built but not asked?)
+- Alignment scoring (what percentage of intent is fulfilled?)
+- What are the failure modes? (vague intent making comparison impossible, measuring what's easy instead of what matters, confusing "working" with "correct")
+
+**Existing commands:** `/compare-intent` (planned)
+**Priority:** Medium — narrow scope, partially covered by critique
+
+---
+
+## Discipline Relationships
+
+```
+Exploration → Sensemaking → Innovation
+                               ↓
+                          Decomposition → Critique → (implement) → Evaluation
+                                                                       ↓
+                                                         Diagnosis → Recovery
+
+Reflection spans all — it operates on the output of any framework
+```
+
+Each discipline is standalone and domain-agnostic. Together they cover the cognitive operations that development requires. The AlignStack Agent uses them as the methodology behind its seven modes.

commands/arch-traces-2.md

@@ -64,8 +64,9 @@ Assessment sections (each must include an ELI15 explanation, an Impact field, an
       - An ELI15 (plain-language or very soft technical explanation)
       - Impact of it to the codebase and overall logic
       - Robust Fixes / Best Practices (how to address it properly)
-      - Architectural Fix if it exists. 
+      - Architectural Fix if it exists (also mention that if this solution is overkill or not for this codebase in the end of the architectural fix. )
       - Speculative defence (if this is a weird error/design use the codebase context to speculate then why not it wasnt solved such way, what was the reason?)
+      - is this 
 
 
 ### Output

commands/critic-d.md

@@ -56,6 +56,7 @@ Document:
 - if any near future requirements are in your context regarding codebase, use them to show better alternative approaches too. But explicitylu state that they are better in the future context only. 
 - Don't just patch the plan — question whether the plan's assumptions are correct.
 
+Also check if plan is detailed enough, if any step's implementation is too high level compared to complexity of the relevant code section and concepts, mention that as a Medium risk. 
 
 Rate each risk (severity) as: Low/Medium/High
 For each Medium/High risk, suggest three levels of mitigation :