Part 10. Project Replanning

After the first feature, you want to start building the next one right away. In SDD, it's better to pause. Replanning is the moment when you update project documents while the deviation is still small. The faster the agent writes code, the more important it is to regularly return to project rules.

Replanning answers the questions:

• what did we learn after the previous phase;
• does the technology stack need updating;
• is the roadmap outdated;
• which checks should become mandatory;
• is there a repeatable process worth automating.

Example of Replanning After Hello Hono

After the first feature, you might realize:

• Vitest is needed for verification;
• responsive design is needed as a project rule;
• CHANGELOG.md is needed;
• the roadmap is too fragmented or, conversely, too large;
• the request to Qwen Code for feature specification repeats and begs to become a skill.

Create a branch:

git checkout -b replanning-after-hello-hono

Request:

/clear
Read @specs/mission.md, @specs/tech-stack.md, @specs/roadmap.md
and the completed Hello Hono feature specification.

We are conducting a replanning phase.
Do not implement new product features.
Propose changes for:

1. testing policy with Vitest;
2. responsive design as a general product requirement;
3. maintaining a change log;
4. phase sizes in the roadmap.

Before editing, list the proposed file changes.

Updating tech-stack.md

Add a testing policy:

## Testing

- Vitest verifies routes, components, and database.
- `npm test` must launch `vitest run`.
- Feature verification files must name mandatory automated checks.

Add a constraint for the interface:

## Interface

- HTML is rendered on the server via Hono JSX.
- Plain CSS, unless a new dependency is explicitly approved.
- Pages must work at mobile width 375px and desktop width 1280px.

Updating Old Specifications

When project rules change, old feature specifications may become incomplete. Ask Qwen Code:

Update existing feature specifications to match the new testing policy
and responsive design.
Do not change the implementation yet, unless the updated check requires it.
Before editing, show a brief summary.

This is important: the specification history must explain which rules were in effect at the time of implementation.

Changelog as Communication

CHANGELOG.md is useful not only for humans. The agent can also read it as a brief project history.

Example:

# Changelog

## 2026-05-01

- Added project constitution for SDD.
- Implemented basic Hello Hono feature.
- Added layout, static CSS, and strict TypeScript checking.

Request:

Create or update @CHANGELOG.md.
Use date headings.
Rely on Git history and changes in the current branch.
Write briefly and clearly for interested stakeholders.

Changing Phase Sizes in the Roadmap

Bad roadmap:

## Phase 2: build all application features

Too broad. The agent will make many changes, and it will be hard for a human to verify.

Bad roadmap:

## Phase 2: add one CSS margin

Too small. More overhead than value.

Good roadmap:

## Phase 2: Agents and Ailments

Goal: add basic domain model and read-only pages.

- [ ] Add SQLite schema for agents and ailments.
- [ ] Add initial seed data.
- [ ] Add /agents and /ailments pages.
- [ ] Add route and component tests.

Codification Step: What to Turn Into a Rule

Replanning is the moment when you turn one-time observations into permanent rules. If you don't do this, each subsequent feature will repeat the same mistake, and the agent will guess anew every time.

Codification is recording an observation as one of four artifacts:

• **Rule in QWEN.md.** Fits when the observation concerns agent behavior: "never change tsconfig.json without confirmation", "always show the list of changed files before writing".
• **Decision in tech-stack.md.** Fits when the observation concerns a long-term technical choice: "we use Vitest for all tests", "no ORM in early phases", "all tables get created_at".
• **Template in validation.md.** Fits when the observation concerns the form of verification: "for a route, check both 200 and 404", "for a migration, check idempotency by running twice".
• Hook, skill, or prompt. Fits when the observation repeats mechanically and is easier to automate (see parts 14 and 17).

A simple request for the codification step at the end of the replanning branch:

Based on the Hello Hono feature and the completed replanning, propose

a list of changes to QWEN.md, tech-stack.md, validation.md template,
and the set of hooks/skills. For each item, specify:
1. the observation that led to it;
2. the proposed rule or artifact;
3. which file to add it to;
4. why it shouldn't be kept only in chat.
Do not change files yet.

If the list is longer than 5–7 items, don't try to implement everything at once — pick the two or three most frequent observations, record them, and leave the rest for the next replanning.

Feedback Flywheel: Signal → What to Update

To keep codification from becoming a big ritual, keep at hand a short mapping of "signal → what to update". It's convenient to think of this as a flywheel: each observation from the last feature triggers an update that reduces the chance of the same problem in the next one.

The list does not claim to be complete. Its purpose is to show that for every noticed failure, there is a permanent place to record the response. If a place cannot be found, that's a signal that the project structure lacks a section, and it's worth creating one.

Replanning Commit

npm test
npm run typecheck
git add specs CHANGELOG.md package.json package-lock.json vitest.config.ts tests
git commit -m "Replan workflow after first feature"
git checkout main
git merge replanning-after-hello-hono
git branch -d replanning-after-hello-hono

Practice

1. Create a branch for replanning.
2. Update the testing policy.

1. Add the responsive design requirement.
2. Create a changelog.
3. Refine the roadmap.
4. Commit and merge.

Review Questions

1. Why should replanning be between features, not inside implementation?
2. Which changes belong to project rules, and which to feature specification?
3. How does the changelog help the agent?