Change requests

Requirements change after work has started. A new constraint lands, a story gets cut, a flow is rethought. A change request lets you revise an initiative's requirements safely — Liddr shows you exactly what the revision does to the existing plan, guards against quietly breaking work that's already in flight, and checks that the new dependency structure can still be built.

Why change requests exist

Editing requirements in place is risky once Build has started. A removed or rewritten story might be one a developer agent has already implemented; a reworked dependency chain might become impossible to sequence. A change request makes the revision reviewable before it's applied: you see the diff, the impact, and any blockers, then approve or reject.

The flow

1. Draft. Provide your feedback on what should change. Liddr regenerates the requirements draft and computes a story-level diff — what was added, removed, modified, or left unchanged — against the current requirements.
2. Analyze impact. Liddr annotates the diff with each affected story's current build status and flags any change that touches in-flight work as protected.
3. Check dependencies. The proposed revision is validated for dependency cycles before it can be applied.
4. Review. You see a one-line summary (for example, +3 added, -1 removed, ~2 modified), the full diff, and any warnings.
5. Apply or reject. Approving applies the revision to the initiative's requirements; rejecting discards it. The current requirements are untouched until you apply.

Drift guarding

The "drift" a change request guards against is the gap between the requirements and the work already built from them. When the impact analysis runs, each removed or modified story is matched to its current build status. A story that a developer has already built — or partially built — is marked protected.

If a change request would remove or modify a protected story, applying it is blocked. The summary calls this out explicitly:

+2 added, -1 removed, ~1 modified — ⚠ 1 in-flight story affected

You can still proceed when you genuinely intend to — applying with force overrides the protection — but the default refusal ensures you never silently invalidate work that's already in progress.

Forcing past protection

Forcing a change request through means a story someone has already built may no longer match the requirements. Use it deliberately, and expect to re-run or rework the affected build.

Story dependency-cycle detection

Stories can declare that they require other stories. Those requires relationships form a dependency graph, and that graph must be acyclic to be buildable — a circular chain (A needs B, B needs C, C needs A) can never be sequenced.

Whenever a change request is drafted, Liddr builds the dependency graph from the proposed requirements and checks it:

• If it finds a cycle, the change request surfaces the cycle rendered with human-readable story titles so you can see exactly which stories form the loop and break it.
• If the graph is acyclic, Liddr derives a build order — grouping independent stories into waves so work that doesn't depend on anything else can proceed in parallel.

References to external services or tickets are ignored for cycle purposes; only story-to-story dependencies are checked.

Fix cycles in the requirements, not the build

A dependency cycle means the plan itself can't be sequenced. Resolve it by editing the requires relationships in the proposed requirements before applying the change request — don't push it down to Build.

When to use a change request

Reach for a change request whenever an initiative's requirements need to change after the requirements stage has been approved — especially once Build has started. It is the safe path for:

• Adding, removing, or rewriting stories on an in-flight initiative.
• Reworking story dependencies without risking an unbuildable plan.
• Understanding the blast radius of a requirements change before committing to it.

Related

• Forge
• Know
• The knowledge graph