A context bundle is composed per invocation within a stated budget

actor

An agent starting one design pass over a Pack or an ordered list of Specs.

problem

Each pass assembles the same reading material by running the same recipes and joining their answers by hand, and nothing bounds what it hands the model.

outcome

Give an agent the reading material for one design pass in one composed slice of the graph within a stated budget, so no session hand-assembles it.

rule line 27 · specs/consumers/context-bundle.sdp.md:27

A bundle is a catalog recipe that takes its scope and its budget as recipe parameters; it adds no entrance and no query verb.

rule line 28 · specs/consumers/context-bundle.sdp.md:28

A bundle is composed from the graph on each invocation by the reader every recipe uses; nothing is precomputed, saved or committed, and two invocations over the same graph with the same parameters compose the same bundle.

rule line 29 · specs/consumers/context-bundle.sdp.md:29

A bundle takes one scope: pack, a Pack id, or specs, an ordered list of Spec ids. For specs the members are the listed Specs in the given order and the boundary is each member's one-hop neighbors through the four typed relations both ways, with verifies and supersedes apart, as the Pack boundary is built. Both scopes or neither is a diagnostic result. A changeset fills specs from the impacted Spec ids changed-file impact reports, and a Pack's open questions are read from the Pack bundle, not from a third scope.

rule line 30 · specs/consumers/context-bundle.sdp.md:30

With pack, a bundle may take members, an ordered subset of the Pack's member ids, which the perspective filter returns; it keeps the Pack's framing and boundary, lists only those members in that order, and states that it is a subset, so one filter implementation serves both recipes.

rule line 31 · specs/consumers/context-bundle.sdp.md:31

A bundle for a Pack carries the Pack design assembly, its members in authored order with their design columns and its boundary, then each member's open questions with their addresses and lines, its dependency footing, its pinned declarations and its examples.

rule line 32 · specs/consumers/context-bundle.sdp.md:32

The budget is a hard limit on a successful bundle, counted in UTF-16 code units, the length a recipe body reads, of the compact JSON.stringify of the value the recipe returns, its scope, budget and left-out statement included; sdp q --json prints a longer indented form, and the budget never measures printed text. The bundle also reports a token estimate labeled as an estimate, so no model's tokenizer binds the Protocol.

rule.oneCopy line 33 · specs/consumers/context-bundle.sdp.md:33

A bundle carries a member's open questions only in its questions, a pinned declaration's value only in its member's Design section, and an example's steps only in its own member row when the example is a member of the bundle; an example outside the bundle keeps its steps in the row of each member it refines or verifies.

no example exercises it

rule.cutOrder line 34 · specs/consumers/context-bundle.sdp.md:34

When the scope exceeds the budget, the bundle cuts in a fixed order and stops at the first cut after which it fits: boundary rows down to their ids, footing rows down to their ids, member narrative, example step text, non-blocking question text, remaining section values other than pinned declarations, then, only when the caller allows it, pinned declarations down to their entry addresses. It never cuts member ids, the stated rung, the floor reached, the stated next rung, blocking questions or entry addresses, and it cuts nothing else.

no example exercises it

rule.declarationAddresses line 35 · specs/consumers/context-bundle.sdp.md:35

A caller allows the last cut by passing declarations: "addresses"; without it, or with declarations: "whole", pinned declarations stay whole, and any other value is a diagnostic result.

no example exercises it

rule line 36 · specs/consumers/context-bundle.sdp.md:36

Without part, when the protected content alone exceeds the budget after every permitted cut, the recipe returns a budget-exceeded result as data and no partial bundle: the requested scope, the budget, and the minimum count the protected content needs in the same unit; sdp q exits 0, because the result is the body's return and not a refusal.

rule line 37 · specs/consumers/context-bundle.sdp.md:37

A bundle gives the file and line of an entry or a binding in place of a source excerpt, because the reader never reads source.

rule line 38 · specs/consumers/context-bundle.sdp.md:38

A bundle states its scope, its budget and what it left out to stay within the budget, so a reader knows what to read in the Specs themselves.

rule line 39 · specs/consumers/context-bundle.sdp.md:39

A bundle carries facts from the graph and no instructions of its own; the brief that tells an agent what to look for stays the corpus's own text.

rule.parts line 40 · specs/consumers/context-bundle.sdp.md:40

With part, the 1-based index of the part to return, a bundle comes in ordered parts, each within the budget, and the members of its parts, read in part order, are the bundle's members in order, each once.

spec:consumers.context-bundle.parts-cover-the-pack · enabled

rule.partBoundaries line 41 · specs/consumers/context-bundle.sdp.md:41

A part boundary falls between items and never inside one: the boundary is the first item and each member is one item, in the scope's order, and each part holds the longest run of items after the part before it that fits the budget.

spec:consumers.context-bundle.parts-cover-the-pack · enabled

rule.partCuts line 42 · specs/consumers/context-bundle.sdp.md:42

In parts the bundle tries the cut order one cut at a time, starting from no cut, splits the scope at each stage and takes the first stage at which every part fits the budget, each part measured whole in the shape it returns: its repeated fields, its leftOut, the boundary in part 1 and the final part.of; every part takes that stage's cuts and lists them in leftOut.

spec:consumers.context-bundle.parts-cover-the-pack · enabled

rule.partHeader line 43 · specs/consumers/context-bundle.sdp.md:43

Every part repeats the scope, the budget, the declaration mode, the cuts taken, its own place among the parts and, for a Pack scope, the Pack's id, title and framing, so each part reads on its own; only the first part carries the boundary.

spec:consumers.context-bundle.parts-cover-the-pack · enabled

rule.sameParts line 44 · specs/consumers/context-bundle.sdp.md:44

The split depends on the graph and on every parameter but part, so a caller that asks for each part in turn over one graph reads one bundle.

spec:consumers.context-bundle.parts-cover-the-pack · enabled

rule.oversizedItem line 45 · specs/consumers/context-bundle.sdp.md:45

When the repeated part header alone exceeds the budget after every permitted cut, the recipe names "header" as its one oversized item and returns no part. Otherwise, when an item alone exceeds the budget after every permitted cut, the recipe names each such item with its length and returns no part. In both cases sdp q exits 0.

spec:consumers.context-bundle.oversized-member-named · enabled

10 unkeyed rules.

Verifying examples

Given a probe Pack of three members whose bundle exceeds the budget {budget: 10000} {sizes: "and one member carries a blocking question longer than the budget"}
When each part of its context bundle is requested in turn
Then the answer names the oversized items {oversizedItems: "spec:probe.two"}

Given a probe Pack of three members whose bundle exceeds the budget {budget: 10000} {sizes: "while each member fits a part alone"}
When each part of its context bundle is requested in turn
Then the bundle comes in {parts: 3} parts, each within the budget
Then the members of the parts, in part order, are the Pack's members in authored order, each once: {complete: true}

Example space

Given a probe Pack of three members whose bundle exceeds the budget {budget:number} {sizes:"while each member fits a part alone"|"and one member carries a blocking question longer than the budget"}
When each part of its context bundle is requested in turn
Then the bundle comes in {parts:number} parts, each within the budget
Then the members of the parts, in part order, are the Pack's members in authored order, each once: {complete:boolean}
Then the answer names the oversized items {oversizedItems:string}

bundleRecipe line 49 · specs/consumers/context-bundle.sdp.md:49

recipe 36, the context bundle, takes exactly one scope, params.pack or params.specs, an optional params.members beside pack, params.budget, 100,000 code units by default, params.declarations, "whole" by default or "addresses", and an optional params.part; a missing, doubled or unknown scope, another declarations value, or a part that is not a positive integer returns { diagnostics } and no bundle.

bundleShape line 50 · specs/consumers/context-bundle.sdp.md:50

{ scope, budget, declarations, used, tokenEstimate: { value, method }, leftOut, pack, members, boundary }, where declarations is the mode in force, pack is { id, title, framing } for a Pack scope and null otherwise, and tokenEstimate.method reads UTF-16 code units divided by four, an estimate.

no citation recorded

memberShape line 51 · specs/consumers/context-bundle.sdp.md:51

{ id, file, title, specKind, altitude, statedReadiness, floorReached, statedNextRung, holds, narrative, sections, questions, footing, declarations, examples, design, decisions, implementedBy, referencedBy, verifiers }, with file the member's carrier path; sections as the graph holds them, without intent.openQuestions; questions one row per open question in authored order, { index, question, blocking, key, address, line } with its fields, key absent and address null when it has none; footing as dependency footing (recipe 21) reports it; declarations the keys of the member's pinned declarations in Design order; design the counts of entries, declarations, open questions and blocking questions; decisions the decisions its design columns name; implementedBy and referencedBy as { id, claim, file, line, role, component }; and verifiers as { id, claim, enabled, file, line }. holds lists the member's stated-next-rung failures as the reader returns them, each with its clauseId and description, and with targets on a typed-dependency failure.

no citation recorded

exampleRow line 52 · specs/consumers/context-bundle.sdp.md:52

{ id, member, file, statedReadiness, enabled, steps } lists one example that refines or verifies the member, in id order, with member true and steps null when the example is itself a member of the bundle, its steps then sitting in its own member row.

no citation recorded

pointer line 53 · specs/consumers/context-bundle.sdp.md:53

{ line } replaces a cut entry that has no entry address, line being the line the location table records for it, or null when it records none; the entry's Spec and file are those of the row that holds it, and its place in the bundle names its path. A cut entry whose text names other entry addresses becomes a list of them, led by its own address when it has one and otherwise ended by its pointer.

no citation recorded

boundaryRows line 54 · specs/consumers/context-bundle.sdp.md:54

a Pack scope's boundary is the Pack design's; a Spec-list scope's boundary is every Spec outside the list one authored relation away from a listed Spec, in the same row shape.

footingCut line 55 · specs/consumers/context-bundle.sdp.md:55

{ refines, dependsOn, constrainedBy, decidedBy } replaces a member's footing at the footing cut, each a list of target ids in code-unit order, with a type that has no target left out.

no citation recorded

narrativeCut line 56 · specs/consumers/context-bundle.sdp.md:56

The narrative cut replaces a member's narrative with the entry addresses written in it, in order of first appearance and joined by single spaces, or with null when it holds none.

exampleCut line 57 · specs/consumers/context-bundle.sdp.md:57

The example cut replaces each entry of a member's behavior.examples, and its behavior.exampleSpace, with its pointer, and each example row's steps that are not null with the pointer of that example's behavior.examples.

questionCut line 58 · specs/consumers/context-bundle.sdp.md:58

The question cut replaces each non-blocking question in questions with its address, or with its pointer when it has no key, and with { pointer, links } when it has links, pointer being that address or pointer; blocking questions stay whole.

sectionCut line 59 · specs/consumers/context-bundle.sdp.md:59

The section cut replaces each section entry other than a pinned declaration with its entry address when it has one, and otherwise with its pointer.

declarationCut line 60 · specs/consumers/context-bundle.sdp.md:60

The declaration cut, taken only under declarations: "addresses", replaces each pinned declaration in its member's Design section with its entry address, or with its pointer when its key has none; the member's declarations keeps the keys.

leftOutLines line 61 · specs/consumers/context-bundle.sdp.md:61

One fixed line per cut taken, in cut order, makes up leftOut: Boundary details; ids kept per direction., Footing details; ids kept per relation type., Member narrative., Example step text, including member sections and example-space vocabulary., Non-blocking question text; addresses and links kept., Section entry values other than pinned declarations; addresses and lines kept. and Pinned declaration text; entry addresses kept.

budgetExceeded line 62 · specs/consumers/context-bundle.sdp.md:62

{ scope, budget, declarations, budgetExceeded: true, protectedLength, leftOut } is the whole result when the protected content alone exceeds the budget after every permitted cut, with protectedLength in the budget's unit.

no citation recorded

partShape line 63 · specs/consumers/context-bundle.sdp.md:63

a part is the bundle shape with part: { index, of } after declarations, where of is the number of parts; its members hold its run of members, its boundary holds the scope's boundary in part 1 and is null in every later part, and its used and tokenEstimate measure the part.

partDiagnostic line 64 · specs/consumers/context-bundle.sdp.md:64

a part above the number of parts returns { diagnostics: [{ scope: "part", problem: "The bundle has <of> parts." }] }, in the { scope, problem } row the recipe's other diagnostics use.

partsExceeded line 65 · specs/consumers/context-bundle.sdp.md:65

{ scope, budget, declarations, part: { index, of: null }, budgetExceeded: true, oversized: [{ item, length }], leftOut } is the whole result when an item exceeds the budget alone after every permitted cut, where item is "header" alone when the repeated header exceeds the budget, and otherwise a member id or "boundary", in scope order. For "header", length counts the code units of a part with part: { index: 1, of: 1 }, no members and a null boundary after every permitted cut; otherwise it counts a part that holds that item alone.

no citation recorded

Verifier bindings

• spec:consumers.context-bundle.oversized-member-named · A member larger than the budget is named, and no part is returned · declared · example enabled · specs/consumers/context-bundle.oversized-member-named.sdp.md

  External run evidence from test/self-hosting-bundle-parts.test.ts

  Test anchors: test:protocol.context-bundle.oversized-member-named, test:protocol.context-bundle.parts-cover-the-pack. Specs verified by those bindings: spec:consumers.context-bundle, spec:consumers.context-bundle.oversized-member-named, spec:consumers.context-bundle.parts-cover-the-pack.

  Run 2: external run evidence from vitest 4.1.10

  Build: CI 439 · Branch: docs/articles-refresh-1 · Commit: 61576184ea9f39b7f91c51fef5ff991b0bf2d0e6 · Start: 2026-11-04T07:59:39.962Z · Stop: 2026-11-04T08:03:39.928Z

  Name	Suite	Result	Duration
  executes the bound example against a fresh world	A Pack too large for one bundle reads whole in parts (spec:consumers.context-bundle.parts-cover-the-pack)	passed	105.61 ms
  executes the bound example against a fresh world	A member larger than the budget is named, and no part is returned (spec:consumers.context-bundle.oversized-member-named)	passed	19.54 ms
  diagnoses invalid part 0	bundle part budgets	passed	9.06 ms
  diagnoses invalid part -1	bundle part budgets	passed	12.8 ms
  diagnoses invalid part 1.5	bundle part budgets	passed	28.1 ms
  diagnoses invalid part null	bundle part budgets	passed	15.53 ms
  diagnoses invalid part "1"	bundle part budgets	passed	4.51 ms
  diagnoses invalid part true	bundle part budgets	passed	4.26 ms
  diagnoses a part beyond the final count	bundle part budgets	passed	11.15 ms
  accepts an exact whole-part budget and cuts only when that item cannot fit	bundle part budgets	passed	18.87 ms
  measures two-digit part counts and takes the longest whole run at every boundary	bundle part budgets	passed	156.54 ms
  repartitions at the first common cut stage instead of mixing cut and whole members	bundle part budgets	passed	15.81 ms
  preserves pinned declarations until addresses are allowed, and never returns a partial part	bundle part budgets	passed	28.12 ms
  gives an empty scope one complete part when it fits	bundle part budgets	passed	4.89 ms
  names only the part header when the repeated Pack framing alone exceeds the budget	bundle part budgets	passed	28.17 ms
  names an oversized boundary when its outside neighbour ids exceed the budget after every cut	bundle part budgets	passed	92.58 ms

• spec:consumers.context-bundle.parts-cover-the-pack · A Pack too large for one bundle reads whole in parts · declared · example enabled · specs/consumers/context-bundle.parts-cover-the-pack.sdp.md
• test:protocol.context-bundle-recipe · anchored · test anchor binding present · test/iteration-recipes.test.ts:777

  External run evidence from test/iteration-recipes.test.ts

  Test anchors: test:protocol.context-bundle-recipe, test:protocol.design-diff-recipe, test:protocol.perspective-filter-recipe, test:protocol.proposal-schema-and-recipe. Specs verified by those bindings: spec:consumers.context-bundle, spec:consumers.design-diff, spec:consumers.intent-composition.proposal, spec:consumers.review-perspectives.

  Run 2: external run evidence from vitest 4.1.10

  Build: CI 439 · Branch: docs/articles-refresh-1 · Commit: 61576184ea9f39b7f91c51fef5ff991b0bf2d0e6 · Start: 2026-11-04T07:59:39.962Z · Stop: 2026-11-04T08:03:39.928Z

  Name	Suite	Result	Duration
  compares keyed values, keyed order and unkeyed sections while keeping bindings apart	iteration loop: design diff	passed	138.02 ms
  compares question fields by key, whole unkeyed questions, envelope fields and other sections	iteration loop: design diff	passed	38.97 ms
  reports added and removed Specs and Packs, filters the union of membership, and ignores source lines	iteration loop: design diff	passed	49.13 ms
  diagnoses required input and schema differences and compares common content	iteration loop: design diff	passed	16.41 ms
  runs the documented base-worktree procedure, preserves constant anchors, and compares HEAD	iteration loop: design diff	passed	46789.11 ms
  compares a keyed rule that becomes a flow at the same address	iteration loop: design diff	passed	22.6 ms
  compares new Design entries across schema versions when the base corpus has none	iteration loop: design diff	passed	22.68 ms
  diagnoses uncertain optional fields at base 0.9.0 and head 0.9.0	iteration loop: design diff	passed	21.42 ms
  diagnoses uncertain optional fields at base 0.9.0 and head 0.10.0	iteration loop: design diff	passed	18.47 ms
  diagnoses uncertain optional fields at base 0.10.0 and head 0.9.0	iteration loop: design diff	passed	26.72 ms
  normalizes legacy rule markers in graphs with comparable rule-key capability	iteration loop: design diff	passed	22.49 ms
  invents no order across rules and flows from a legacy base	iteration loop: design diff	passed	34.13 ms
  compares a legacy base's keyed entries by order within each list	iteration loop: design diff	passed	24 ms
  reports proposal scopes outside the common schema as incomparable	iteration loop: design diff	passed	10.33 ms
  lists all authored reasons into and out of the planning subject in type/from/to order	relation reasons in planning recipes	passed	16.59 ms
  keeps dependency reasons in context-bundle footing	relation reasons in planning recipes	passed	11.6 ms
  matches every declared selector, combines requirements, and keeps authored order unless prioritized	iteration loop: perspective filter	passed	81.45 ms
  matches layers and contexts only through named bindings and keeps anchored matches apart	iteration loop: perspective filter	passed	30.36 ms
  reports malformed and unsupported selectors while applying understood ones	iteration loop: perspective filter	passed	26.62 ms
  keeps term addresses, term lines and key maps through the section cut	iteration loop: context bundle	passed	27.43 ms
  keeps questions and declarations in one place and member-example steps only in their member row	iteration loop: context bundle	passed	26.45 ms
  takes the declaration cut last only with addresses and keeps compact pointers and links	iteration loop: context bundle	passed	102.53 ms
  cuts a pinned dotted key to its line when it has no entry address	iteration loop: context bundle	passed	22.36 ms
  composes both scopes, dependency footing, declarations, example bindings and a perspective subset	iteration loop: context bundle	passed	26.89 ms
  takes all six whole-mode cuts in fixed order and counts the complete returned value including Unicode	iteration loop: context bundle	passed	67.89 ms
  keeps a pinned declaration whole through the sixth cut when its key contains a dot	iteration loop: context bundle	passed	23.87 ms
  reports invalid, missing, doubled and unknown scopes without a partial bundle	iteration loop: context bundle	passed	49.2 ms
  accepts term scopes and detects changed definitions through their authored keys	iteration loop: proposal schema and check	passed	31.66 ms
  holds the schema and recipe to the same accepted and refused documents	iteration loop: proposal schema and check	passed	195.49 ms
  checks the complete scope union, resolves both graphs, and reports each change independently	iteration loop: proposal schema and check	passed	19.28 ms
  agrees with recipe 35 on added, removed and changed entry values and on whole-Spec changes	iteration loop: proposal schema and check	passed	20.11 ms
  excludes anchor-only changes and requires the caller's base graph	iteration loop: proposal schema and check	passed	19.08 ms
  compares interleaved keyed rules and flows in their authored order and reports verifier changes apart	iteration loop: comparison and budget edges	passed	26.1 ms
  cuts example text once and preserves compact pointers after the sixth cut	iteration loop: comparison and budget edges	passed	52.69 ms
  reads the base graph and proposal from named JSON files through the real parameter seam	iteration loop: comparison and budget edges	passed	12.42 ms
  requires a test bound directly to an example before the bundle names it enabled	iteration loop: example enablement	passed	18.74 ms
  compares rule order by text and other anonymous collections as a whole	iteration loop: anonymous collection order	passed	25.03 ms
  keeps addresses in each place when narrative, example, question and section text are cut	iteration loop: protected entry addresses	passed	53.04 ms

Requirement drawing

Decisions

• The agent front door is one evaluation sink over the exported reader

  The front door is two entrances over one seam: the package exports the reader constructor, and the CLI carries a single evaluation sink that derives the graph in process, injects that same reader, and prints the body's pre-shaped return.

• impl:protocol.context-bundle-recipe · realizes the context bundle in the shipped recipe catalog · test/iteration-recipes.test.ts:770

  Uses

  None.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.