Handing off to planning

---
title: Handing off to planning
description: What a downstream planning tool consumes from Specgent, and what it never receives.
---

## One artifact

Downstream planning consumes exactly one artifact: one accepted specification
revision, identified by its revision id. Which one depends on the slice
decision.

| Feature shape                | The artifact to consume                                      |
| ---------------------------- | ------------------------------------------------------------ |
| a reasoned no-slice decision | the accepted Feature Specification revision                  |
| sliced                       | the accepted Feature-Slice Specification revision, per Slice |

It is not a bundle of the specification, the RFC and whatever else sits beside
them: it is one revision, named by id, whose bytes are sealed and immutable. The
contract binds both sides. Specgent must make that one document sufficient for
planning, and the consumer must not reach behind it; a planner that reads the
RFC because the specification was thin has changed what the accepted artifact
means. The readiness report names the revision to consume.

## What the artifact carries

Each specification embeds a portable description section: the material a
planner or a tracker needs, in a form that travels. It is a deterministic
projection of the canonical register, not a summary written beside it. Render
drift blocks sealing and acceptance, so the embedded section cannot quietly
disagree with the register it came from.

A presentation profile may reorder headings and map metadata onto your
organization's conventions. It may not create canonical meaning, weaken
traceability, invoke external systems or generate implementation instructions.

## Copy out, do not push

Specgent does not push portable material to a tracker, open an issue or call any
external system. Copying the embedded section into your tracker is a human
action, and it stays one, so no second, drifting copy of the specification
appears where the record cannot see it.

## What a specification never carries

The specification stops at the contract. A validator checks every sealed
artifact for the following classes, and a specification carrying one does not
seal:

- task backlogs: implementation plans, task breakdowns, work plans, or
  checkbox lists that reference file paths;
- source patches, as diff or patch fences;
- estimates, story points or assignees;
- branch naming or commit strategy;
- paths for files that do not exist yet;
- edit instructions such as "change X to Y in Z";
- exact code symbols to write;
- ordered implementation steps;
- commands to run.

## Where the boundary sits

Specgent's readiness vocabulary stops at `development-ready`. It never reports
`implemented`, `test-passing`, `QA-approved`, `deployed` or `released`, because it
never observes a build, a test run or a deployment.

Your planning tool decides how to build the thing. Specgent decides what the
thing is and proves that decision is grounded. When a built thing is wrong,
there is exactly one document to hold it against.