How the ADHD Reframe Phase Handles Real Constraints vs Incidental Anchors

The reframe phase in ADHD strips incidental anchors like current tech stacks while preserving essential constraints such as compliance rules and budgets, ensuring divergent ideation focuses on genuine problem limits rather than arbitrary implementation details.

The reframe phase is the first transformation applied to user-supplied problems in the UditAkhourii/adhd repository. This critical step distinguishes between real constraints that must govern any solution and incidental anchors that unnecessarily limit creative exploration. According to the source code in src/types.ts, the system explicitly categorizes problem elements to prevent implementation bias from restricting the divergent thinking process.

Distinguishing Real Constraints from Incidental Anchors

The reframe logic operates on a strict dichotomy that determines which elements survive the transformation.

Real Constraints (Hard Limits)

Real constraints represent immutable boundaries that any valid solution must respect. These include compliance requirements like GDPR data-retention policies, physical limitations, regulatory restrictions, and explicit budget ceilings. According to src/types.ts (lines 57-60), these constraints are preserved unchanged during the reframe phase because they constitute genuine problem domain limits that downstream frames must acknowledge.

Incidental Anchors (Implementation Bias)

Incidental anchors comprise convenient but non-essential artifacts such as current technology stacks, specific tool names, or obvious implementation details that merely reflect existing habits rather than true requirements. The source code explicitly removes these elements during reframing to prevent the LLM from biasing subsequent frame generation toward familiar but potentially suboptimal solutions. For example, mentioning "React+Redux" when the actual requirement is simply "web dashboard" constitutes an anchor that limits creative exploration unnecessarily.

Implementation in the Engine

The core reframe logic resides in src/engine.ts within the reframeProblem function (lines 123-140). This function sends the original problem statement to the LLM with a specific prompt instructing it to "strip incidental anchors" while preserving real constraints.

The implementation follows this sequence:

1. Schema Definition: Lines 56-64 define the JSON schema expecting a reframed text field and a boolean changed flag.
2. LLM Processing: The function submits the problem plus optional context to the language model.
3. Fallback Handling: If the LLM fails or returns malformed data, the system falls back to the original problem and sets changed: false.
4. Result Consumption: Lines 339-346 consume the result, using the reframed text (divergeProblem) only when changed === true.

In src/types.ts, the RunOptions interface includes the stripAnchors boolean (defaulting to true) that controls whether this transformation occurs.

Practical Code Example

The following TypeScript implementation demonstrates how the reframe phase processes mixed constraint types:

import { run } from "adhd/src/engine";
import { RunOptions } from "adhd/src/types";

/* Example: a problem with both real constraints and incidental anchors */
const opts: RunOptions = {
  problem: `
    Build a web dashboard for real-time analytics.
    Must run on the existing React+Redux stack (incidental anchor).
    Must comply with GDPR data-retention policy (real constraint).
    Budget ≤ $5,000 (real constraint).
  `,
  stripAnchors: true,   // default – removes the "React+Redux" mention
  // other options omitted for brevity
};

run(opts).then(result => {
  console.log("Reframed problem:", result.reframe);
  // → "Build a web dashboard for real-time analytics.
  //    Must comply with GDPR data-retention policy.
  //    Budget ≤ $5,000"
});

This example illustrates how the React+Redux anchor is stripped while GDPR compliance and budget limits persist, creating a cleaner problem statement for frame generation.

Downstream Effects on Frame Generation

After successful reframing, the engine emits a { kind: "reframe:done", changed: true } event and substitutes the original problem with divergeProblem for all subsequent frame generation. As implemented in src/engine.ts (lines 341-346), this ensures that divergent frames explore solution spaces free from anchor-induced bias while maintaining strict adherence to genuine constraints.

If the reframe phase determines no anchors exist (changed: false), the engine proceeds with the original problem text unchanged, avoiding unnecessary transformation overhead. The CLI provides user feedback via src/cli.ts (line 122), printing notifications such as "↺ anchors stripped from problem" when the phase modifies the input.

Summary

• The reframe phase acts as a guardrail that eliminates noise from problem statements before divergent ideation begins.
• Real constraints (compliance, budgets, regulations) are preserved unchanged in src/types.ts and remain visible to all downstream frames.
• Incidental anchors (tech stacks, tool names) are removed by the reframeProblem function in src/engine.ts to prevent implementation bias.
• The system uses a changed boolean flag to determine whether to use the reframed text or the original problem for subsequent processing.
• When enabled via stripAnchors: true, this phase ensures creative frames explore solution spaces without arbitrary technological constraints.

Frequently Asked Questions

What qualifies as an incidental anchor in ADHD?

Incidental anchors include specific technology mentions (React, Redux, AWS), current implementation details, or convenience-based requirements that reflect existing habits rather than genuine problem constraints. According to src/types.ts, these differ from real constraints because they describe "conveniences rather than true limits" and are candidates for removal during reframing.

How does the reframe phase handle LLM failures?

When the LLM fails to return valid JSON or encounters an error, the reframeProblem function falls back to the original problem statement and sets changed: false. This safety mechanism ensures that temporary API issues do not block the ideation pipeline, as implemented in src/engine.ts lines 123-140.

Can I disable anchor stripping in the reframe phase?

Yes. Set stripAnchors: false in your RunOptions configuration passed to the engine. When disabled, the reframe phase bypasses the LLM transformation and retains all original problem elements, though it still initializes the changed: false state for downstream compatibility.

Where does the reframe phase fit in the ADHD pipeline?

The reframe phase executes before any divergent frame generation occurs. According to src/engine.ts, it represents the first transformation in the run pipeline, feeding its output (divergeProblem) directly into the frame generation logic that produces creative solution variants.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}