IT'S ALL ABOUT PROGRAMMING

Introduction: From Governance to Daily Execution

In Part 3 of this series, I discussed how governance gives agentic delivery an operating model. It makes ownership, approval points, model choices, exceptions, and evidence expectations visible. The next question is more practical: what does that governance change when a developer and a coding agent begin working on an actual feature?

This is where an implementation pattern becomes important. A gate has little value if it is only a label in a process diagram. It becomes useful when it changes the input an agent receives, the size of the work it can attempt, the evidence it must return, and the conditions for moving forward.

For this article, I use one compact feature throughout: add manager approval when an expense exceeds a configurable threshold, retain an audit trail for the decision, and produce validation evidence. The feature is familiar enough to understand quickly, but it still contains business rules, authorization, configuration, state changes, and non-functional concerns. That makes it a useful way to see how SpecNexus moves work through DEFINE -> IMPLEMENT -> VALIDATE -> ASSURE without turning the article into a copy of the repository documentation.

The objective is not to show every prompt or command. It is to understand what enters each phase, which decisions belong there, what evidence comes out, what the team should observe, and why the boundary is useful.

Background: Why Implementation Patterns Matter

A one-shot agentic request often combines several kinds of work. The agent must interpret an incomplete feature, inspect a repository, choose an architecture, infer contracts, write code, generate tests, and decide whether the result is complete. Even when each activity is individually reasonable, placing all of them in one broad context creates a weak delivery boundary.

Consider the expense request. Who owns the threshold configuration? Is the threshold evaluated when an expense is submitted or again when it is approved? Can any manager approve, or only the submitter’s manager? Must both approval and rejection be audited? What happens at exactly the threshold value? None of these questions is answered by the sentence “add manager approval above a configurable threshold.”

If implementation starts immediately, the code will still contain answers. They will simply be inferred answers. Reviewers then discover the ambiguity after it has become an API shape, database state, UI behavior, or test expectation. The apparent speed at the beginning returns as rework later.

SpecNexus addresses this by separating delivery questions into phases and carrying traceable evidence between them. When state tracking is requested or work spans multiple turns, it also persists resumable delivery state in pipeline-state/<feature-slug>/state.json. It is important to place SpecNexus correctly in the toolchain: SpecNexus complements OpenSpec and Spec Kit; it does not replace either framework. OpenSpec or Spec Kit remains the framework-native specification layer. SpecNexus provides the orchestration, gates, capability mapping, slices, and evidence path around that layer, with persisted state when those tracking conditions apply. The maintained framework-output guidance explains how those outputs are organized without requiring the article to reproduce their file inventories.

Complete Execution Map: One Feature, Four Different Questions

Before examining each phase, it helps to see the full movement of the feature. DEFINE asks whether the work is understood and ready. IMPLEMENT asks whether one approved outcome slice has been built against its contracts and constraints. VALIDATE asks whether the intended behavior and relevant non-functional requirements have been proved. ASSURE asks whether the complete evidence supports a release-readiness decision.

The output of one phase becomes controlled input to the next. Clarified intent becomes a framework-native specification and approved slices. One approved slice becomes bounded implementation work. The changed files and testable behavior become validation input. The specification, diff, tests, and coverage become an assurance package, together with persisted state when tracking is active. This continuity is the central pattern.

Figure 1: The complete SpecNexus execution map from feature input to PR-ready evidence.

For the running example, the feature does not enter IMPLEMENT as an informal paragraph. It arrives with confirmed rules, capability anchors, slice boundaries, acceptance criteria, security expectations, and visible unresolved items. It does not enter ASSURE because an agent says the tests look good. It arrives with recorded validation evidence and any uncovered scenarios. The VS Code usage guide provides the maintained operating steps; here the focus remains on the engineering pattern behind them.

DEFINE: Turn Incomplete Intent into Bounded Work

The input to DEFINE can be a ticket, meeting notes, a source file, product documentation, or a combination of those materials. Inside an existing codebase, repository context is also part of the input. Existing specifications, contracts, tests, security conventions, CI configuration, and nearby implementation patterns may constrain the feature more strongly than the ticket does.

For the expense example, the initial statement establishes an outcome but not enough rules. DEFINE should ask only material questions that can change correctness, architecture, security, data, tests, rollout, or visible behavior. A compact clarification set might establish that a finance administrator owns the threshold, approval is required only when the amount is strictly greater than the value at submission time, only the submitter’s assigned manager can decide, and both approval and rejection create immutable audit records. These are illustrative decisions for the pattern, not claims about a production system.

The phase then confirms the selected framework and enforces or reuses the required session model confirmation. Execution-environment constraints are confirmed separately where applicable. DEFINE also classifies the active delivery lanes and examines DevSecOps and NFR impact. In this example, authorization and audit integrity are clearly relevant. The team may also need to decide whether threshold changes require configuration history, whether concurrent decisions must be prevented, and which observability evidence is needed for failed authorization attempts.

Now the question arises: why derive capabilities before delivery slices? Capabilities are specification anchors; outcome slices are delivery boundaries. A capability describes a stable business or technical outcome that needs a framework-native specification target, such as expense approval. A SLICE-n describes a shippable implementation and validation increment. It can cross UI, API, service, data, security, and QA lanes when those changes are needed to deliver one observable outcome.

For example, the capability might be CAP-1 Expense Approval. One slice could make an above-threshold submission enter a pending state with a visible audit entry. A second slice could let the assigned manager approve or reject it and record the decision. This is different from creating a frontend slice, a backend slice, and a database slice. Technical-layer slices may organize tasks, but none delivers a usable outcome by itself.

DEFINE produces framework-native specification output, mapped requirements and acceptance criteria, outcome-based slices, and estimates with assumptions where requested. It also records blockers instead of hiding them. When state tracking is requested or work spans multiple turns, DEFINE creates or updates resumable phase state in pipeline-state/<feature-slug>/state.json. A slice is ready only when its scope, dependencies, evidence needs, and gate status support implementation.

Figure 2: DEFINE turns source and repository context into clarified, framework-native, slice-ready work.

The observation at this point is simple: the active context and implementation boundary are smaller, while the feature itself is clearer and bounded because uncertainty has been converted into decisions. The benefit is less ambiguity and less implementation rework. Readers who want to inspect complete output structures can use the repository’s worked examples rather than treating this compact example as a full template.

IMPLEMENT: Build One Outcome Slice at a Time

IMPLEMENT begins with one approved SLICE-n, not the entire feature history. Its inputs include the slice outcome, mapped requirements, acceptance criteria, contracts, architectural and security constraints, dependencies, repository conventions, and the evidence expected at completion. The broader specification remains available for context, but the slice defines the active delivery boundary.

Take the first example slice: an employee submits an expense above the configured threshold, the expense enters PendingApproval, and an audit record identifies the threshold and rule that produced the state. The implementation work may touch a form, API contract, domain service, configuration access, persistence, and tests. Those are not separate outcomes. They are coordinated tasks required to make one behavior observable from end to end.

The agent should inspect existing names, error conventions, test patterns, authorization utilities, migration practices, and CI commands before changing files. Contract-first work may define the pending status and response shape before service code. A TDD-oriented repository may first express the exact-threshold and above-threshold behavior as failing tests. SpecNexus does not prescribe a programming language, UI framework, testing library, or architecture. It keeps the work bounded while allowing the repository’s engineering practices to determine how the slice is built.

Implementation also has to preserve negative and security behavior. The threshold check must not exist only in the client. A caller should not be able to force an approved state. Repeated requests and concurrent manager decisions need the behavior defined in the slice or recorded as unresolved. Audit data should be created by the trusted application path, not accepted as arbitrary client input.

The outputs are changed-file evidence, implementation and test results that were actually run, contract or documentation updates required by the slice, and branch or draft-PR readiness where applicable. A file list alone is not enough. The evidence should explain which change satisfies which requirement and identify commands that were not run with the reason.

Figure 3: IMPLEMENT uses an approved outcome slice to constrain contract-first delivery and capture implementation evidence.

What should the team observe at this point? The agent no longer reinterprets the full feature on every turn. It solves one agreed outcome within known repository constraints. This bounded implementation reduces context size and review scope while preserving framework freedom. The maintained prompt guidance contains operational prompts; copying that pack into an implementation discussion would obscure the smaller decision that matters now.

VALIDATE: Convert Acceptance Criteria into Evidence

Generated code and generated tests can agree with each other while both reflect the same mistaken assumption. VALIDATE therefore starts from obligations, not from whatever tests happen to exist. Its inputs are the slice’s acceptance criteria, negative paths, authorization rules, contracts, NFRs, changed behavior, test data needs, and the implementation evidence returned by the previous phase.

For the expense feature, a positive scenario can show that an amount above the threshold becomes pending and cannot be treated as approved. A boundary scenario should prove that an amount exactly equal to the threshold follows the confirmed rule. Negative scenarios should cover an unassigned manager attempting a decision, a non-manager calling the endpoint, and a repeated decision against an already completed expense. Audit validation should confirm that approval and rejection record the actor, outcome, time, and relevant rule context without allowing later mutation.

Different obligations may require different evidence. Domain rules may be covered by unit tests. Authorization and persistence behavior usually need integration evidence. The employee and manager journeys may justify UI automation. Audit inspection or operational behavior may require a targeted manual check. An NFR such as concurrent-decision safety needs a scenario designed for that property rather than a generic happy-path test.

Traceability makes these results explainable. AC-1 should map to one or more TS-n scenarios, and an NFR-n should map to the scenario that proves it. The validation record should show pass or fail, the environment or command used, relevant output, and any obligation that remains uncovered. A passing test count without this mapping cannot show whether an important rule was never tested.

Figure 4: VALIDATE turns acceptance, negative-path, and NFR obligations into mapped coverage evidence.

The expected observation is not simply “tests passed.” It is that intended behaviors can be followed from requirement to acceptance criterion to scenario to result. Uncovered or failed scenarios remain visible in the validation evidence instead of disappearing in a chat transcript; when persisted tracking is active, they also update the delivery state. This produces stronger evidence for QA, developers, architects, and reviewers. The repository’s validation guidance is the maintained source for validator commands and should be used instead of reproducing that inventory here.

ASSURE: Make Release Readiness Defensible

ASSURE brings the delivery story together. Its input is a review package: source intent, framework-native specification, capability and slice mappings, repository diff, changed files, implementation tests, validation evidence, blockers, relevant security or NFR obligations, and any persisted state transitions when tracking is active. The purpose is not to repeat VALIDATE. It is to decide whether the available evidence supports release readiness.

The review first checks for specification drift. Did the implementation use the configured threshold at the agreed point in time? Did authorization remain server-side? Does the decision endpoint permit only the assigned manager? Are both outcomes audited? Does the diff introduce behavior outside the approved slice? These checks compare code and evidence with intent rather than treating either as independently authoritative.

The assurance pass also reviews code quality, automation quality, security, contracts, data changes, and NFR coverage in the context of the slice. A generated test is evidence only after its assertion, setup, and independence have been reviewed. A test that derives its expected value from the implementation may prove very little. Similarly, an audit test that checks only that a row exists may miss whether the actor or decision context is trustworthy.

Findings should be specific and repairable. If the manager role is checked in the UI but not the service, the repair targets authorization rather than reopening the entire feature. If the threshold boundary lacks evidence, add the missing scenario and update the coverage map. After each repair, focused validation is rerun; when persisted tracking is active, the state records the new evidence. Residual risk is documented rather than converted into an unsupported claim.

Figure 5: ASSURE evaluates drift, code, tests, security, NFRs, repairs, and residual risk as one decision package.

The output is an explicit decision such as Approved, Needs Changes, or Blocked, supported by findings, test results, state impact, repairs, and remaining questions. The observation is that release readiness can be explained without relying on an agent’s confidence. The benefit is a defensible handoff to reviewers and approvers, with unresolved risk still visible.

Key Benefits of the End-to-End Pattern

The four phases are useful individually, but their main value comes from continuity.

• Less ambiguity and rework: Material questions are resolved or recorded before they become implementation choices that must be removed later.
• Smaller phase context: Each phase loads the decisions, references, and evidence needed for its current job instead of carrying one ever-growing conversation.
• Framework freedom: OpenSpec or Spec Kit owns the framework-native specification while SpecNexus connects it to delivery evidence and, when tracking is active, persisted state.
• Bounded implementation: One outcome slice gives the agent a clear finish line while still allowing coordinated UI, API, data, security, and QA changes.
• Visible state: When tracking is requested or work spans multiple turns, gates, blockers, current phase, slice status, transitions, and next action remain inspectable rather than implicit.
• AC/TS/NFR traceability: Requirements and non-functional obligations connect to named scenarios and actual results.
• Stronger evidence: Reviewers can inspect why the change exists, what was implemented, what was run, what failed, and what remains uncovered.
• Pause, resume, and handoff: When persisted tracking is active, resumable state allows another turn, developer, QA engineer, or reviewer to continue from recorded decisions instead of reconstructing the feature from chat history.

For the expense example, this means the original threshold rule remains connected to the code boundary, the boundary scenario, the audit evidence, and the final decision. The feature is not passed through four disconnected departments. It is one delivery story with progressively stronger evidence.

Practical Boundaries and Common Mistakes

The pattern should be applied with judgment. A low-risk text correction does not need the same evidence package as an authorization and audit change. Proportionate use is different from skipping the boundaries that make the workflow reliable.

The first mistake is treating DEFINE, IMPLEMENT, VALIDATE, and ASSURE as status labels while allowing work to move forward with failed gates. If a threshold owner is unknown and that decision changes data or behavior, changing the phase name does not make the slice ready.

The second mistake is slicing by technical layer. A “database slice” followed by an “API slice” and then a “UI slice” may leave each increment impossible to validate as user value. Keep technical tasks inside the outcome they support unless the work is an explicit enabling slice with its own completion evidence.

The third mistake is allowing generated tests to certify generated behavior without independent review. Tests must be checked against acceptance criteria, negative paths, authorization, and NFR obligations. Otherwise, the implementation and its tests can preserve the same drift.

The fourth mistake is skipping repository context. Generic code can violate local contracts, naming, error handling, test conventions, or security utilities even when it looks clean in isolation. Repository inspection is part of the delivery input, not an optional optimization.

The fifth mistake is describing SpecNexus as a substitute for OpenSpec or Spec Kit. That removes the framework-native ownership model and creates duplicate specification artifacts. The separation is intentional: capabilities anchor specifications; slices anchor delivery.

Finally, avoid copying long prompt packs, installation steps, or validator lists into feature discussions. Link to maintained sources so the delivery conversation can stay focused on the current decision. The canonical SpecNexus repository links the usage guide, prompt library, framework-output guidance, validation guidance, and complete examples.

Conclusion: Keep the Delivery Story Connected

This article has followed one compact expense-approval feature from incomplete intent to an evidence-based assurance decision. DEFINE resolved material questions and created capability and outcome boundaries. IMPLEMENT built one approved slice against repository conventions and contracts. VALIDATE connected acceptance criteria and NFRs to named scenarios and results. ASSURE reviewed the specification, diff, tests, evidence, repairs, and residual risk as one package.

The important point is not the number of phases. It is the continuity between them. Reliable agentic delivery does not ask an agent to infer the whole engineering contract in one attempt. It progressively reduces ambiguity, narrows the active context, preserves framework-native specifications, and strengthens the evidence available for the next decision.

For a practical next step, begin with one feature whose business rule, authorization boundary, or validation obligation is currently easy to misunderstand. Use the execution map to identify what must be clarified, what one outcome slice should deliver, how its behavior will be proved, and what evidence an approver will need. That is where the implementation pattern becomes real.