P P P P Project M M M M Management

Every feature begins with a measurable goal tied to a business outcome. This step forces clarity before any design or code: what problem are we solving, for whom, and how will we know it worked? The goal becomes the anchor — if a later decision doesn't serve it, the decision is wrong.

Who interacts with this feature? Actors are not just "users" — they include administrators, API consumers, CI pipelines, and the AI agent itself. Mapping actors early prevents the most expensive kind of bug: building the right thing for the wrong audience. Each actor gets explicit capabilities and constraints.

Each story follows a structured narrative: "As [actor], I want [capability], so that [business value]." This is not a ticket description — it is a behavioral contract. Stories are linked to the goal and to specific actors, creating the first link in the traceability chain that runs all the way through to deployment.

Given/When/Then scenarios turn abstract stories into concrete behaviors. Each scenario captures a specific interaction path, including the edge cases that usually surface three weeks after launch. A story without scenarios is a wish; a story with scenarios is a specification.

Scenarios describe behavior in words; fixtures describe it in data. This step extracts concrete input/output pairs from each scenario — the exact values that tests will assert against. When fixtures are defined before code, the team agrees on what "correct" looks like before anyone writes a function.

Define the module boundary: which functions are exported, what types they accept and return, and how they compose with existing packages. This step prevents the proliferation of ad-hoc utilities by making every public interface intentional. If it is not in the package model, it does not get exported.

For UI features: which routes exist, what data each page needs, and where that data comes from (server load vs. client fetch). The page model catches data-fetching mistakes before they become waterfall requests in production. It also defines the component hierarchy so designers and engineers share the same vocabulary.

Database schemas, migration strategy, and repository interfaces. This step ensures that data shape decisions happen before implementation, not during it. Every table, column, and index traces back to a user story requirement. Schema changes ship as versioned migrations with rollback capability.

What services does this feature need? Docker configuration, environment variables, port allocations, and external service dependencies. Infrastructure decisions made during coding are infrastructure decisions made under pressure — this step moves them to design time where they belong.

The approval gate between design and implementation. A consolidated plan presents the goal, stories, scenarios, fixtures, package model, and infrastructure requirements in one document. The team reviews this checkpoint before any code is written — changes at this stage cost minutes, not days. No plan approval, no implementation.

Compile every affected package and application, verify the build exits zero with no warnings promoted to errors. This catches type mismatches, missing imports, and compilation failures before they reach any reviewer or deployment pipeline. A feature that does not compile is not a feature.

Run the complete test suite — unit tests, integration tests, and end-to-end tests. Not just the tests for the new feature, but every test in every affected package. This step verifies that the new work does not break existing functionality. A passing feature that breaks another feature is a net negative.

Automated visual regression: Playwright scripts navigate every affected route, take screenshots, and compare against baseline images. This catches the category of bugs that pass all tests but look wrong — misaligned elements, missing content, broken responsive layouts. Humans notice these instantly; automated tests miss them entirely.

The strictest gate in the pipeline: verify that every exported function traces to a user story, that package models match their implementations, and that no code exists outside the defined scope. This gate blocks — it does not warn. Code without a story has no reason to exist and cannot ship.

Walk the full traceability chain: user story → scenario → fixture → test → function → package → application. Any gap is a defect. A function without a test is untested. A test without a scenario is testing the wrong thing. A scenario without a story is solving a problem nobody asked for.

Update all knowledge artifacts affected by this feature: solution code-snippets, package models, architecture diagrams, and API documentation. This step prevents documentation drift — the moment code changes and docs do not, the docs become a liability. Artifacts are versioned alongside code, not maintained separately.

Commit with governance metadata: task ID trailer, co-author attribution, and scope classification. Push the feature branch and open a pull request with a structured body linking back to the goal, stories, and test results. The PR is not a description of what changed — it is proof that the pipeline was followed.

After review approval, merge the pull request using merge commit (no squash, no rebase — the commit history is the audit trail). Close the SDLC task, update the session log, and verify the merge did not introduce conflicts. The feature is now part of the product, traceable from goal to deployment.