Spec Studio

A Pack is read from a named perspective

spec:consumers.review-perspectivesUse Case / Behavior · featureready floor ready

Packs: pack:design-iteration-v1, pack:design-management-v1, pack:self-hosting-v1

Design: 4 design entries · 1 pinned declaration · no decisions

Findings: no errors, no warnings

specs/consumers/review-perspectives.sdp.md

No open questions and no blocking questions; implementation binding present, verifier binding present, and expected-outcome oracle none.

The original design gave every reader one reading surface, each reading from their own concern: the analyst, the domain engineer, the architect, the tester, the designer and the agent (docs/lineage/v0-design/04-authoring-surfaces.md §6). The first adopter iterates each capability's design through advisor lenses, its runtime platform, the domain, operations and the product, each a written list of the questions its field asks, run over the same Pack by the same pass brief (libar-platform/design/advisors/lenses/, libar-platform/design/advisors/task-pass.md). It asks for a lens to be a filter over the same capability that reorders and emphasizes questions, entries, examples and constraints and opens the same Specs, with no new Spec kind and no compulsory sequence of stages (libar-platform/docs/feedback/sdp-feedback-02.md, item 28). The Protocol takes the member filter and the order and leaves each member's content whole; emphasis inside a member stays the reader's.

The owner ruled the word: perspective. The Spec Studio keeps lens for its graph views, its Packs, capabilities, architecture, tests and evidence views, and discipline stays the filter by kind or section. The adopter's advisor lens is a reader's concern, not a view of the graph, so in the Protocol's terms it is a perspective.

Intent
actor
A reviewer or an agent who reads a Pack for one concern, such as the domain model, operations or the runtime platform.
problem
Every reading of a Pack shows every member in the same order with the same emphasis, so a reader with one concern sorts it by hand, and an adopter keeps its perspectives as prose briefs the graph cannot apply.
outcome
Let a reviewer read the same Pack from one perspective at a time, filtered and ordered for that perspective, without a new kind or a stage.
Behavior
rule.contentIntact line 22 · specs/consumers/review-perspectives.sdp.md:22
A perspective filters and orders a Pack's members and leaves each selected member's content intact; every row opens the same Spec, and the whole Pack stays one step away.

no example exercises it

rule line 23 · specs/consumers/review-perspectives.sdp.md:23
A perspective adds no kind, readiness, stage or sequence; reading a Pack from one perspective records nothing, and no perspective is required before another or before ready is stated.
rule line 24 · specs/consumers/review-perspectives.sdp.md:24
The corpus owns its perspectives and their questions; the Protocol supplies the filter and ships no list of perspectives.
rule line 25 · specs/consumers/review-perspectives.sdp.md:25
A perspective is corpus data: a JSON object the corpus keeps beside its briefs and passes to the perspective filter, a catalog recipe, through --params. The reader loads no perspective file, and no validator lists or checks perspectives, so no registry forms.
rule line 26 · specs/consumers/review-perspectives.sdp.md:26
A perspective selects members by Spec id or id prefix, kind, section presence, Design key with an optional value, question key, and authored relation type with a stated direction; it selects component layer or context only through the member's code unit bindings, satisfying or referencing, that the perspective names; it infers nothing from prose, paths or imports.
rule line 27 · specs/consumers/review-perspectives.sdp.md:27
A member selected by a Design key, including the layer and context keys a component design states, is selected on declared intent; a member selected through a binding's component is selected on anchored structure; each row names which, and the two are never merged into one architecture answer.
rule line 28 · specs/consumers/review-perspectives.sdp.md:28
Values within one selector are alternatives and different selectors combine as requirements; an unsupported selector is a diagnostic in the result, and a valid selector that matches nothing is an explicit empty result.
rule line 29 · specs/consumers/review-perspectives.sdp.md:29
Members keep the manifest's authored order unless the perspective gives an explicit priority order, authored order breaking ties; every selected member's blocking questions stay visible whatever else the perspective filters out.

7 unkeyed rules.

Design
perspectiveObject line 33 · specs/consumers/review-perspectives.sdp.md:33
{ "name": "models", "select": { "kinds": ["model"] } } selects the members of kind model. A perspective is { name, select, order } with select and order optional, and its selectors are ids, idPrefixes, kinds, sections, designKeys, questionKeys, relations and bindings, each optional; different selectors combine as requirements. An absent selector imposes no requirement, a present empty list matches no member, and an absent or empty select object selects every member. A designKeys item is { key, value } with value optional; a relations item is { type, direction, target } with direction out or in and target optional; bindings is { via, layers, contexts }, where via is required and lists satisfies or references, and absent layers or contexts impose no restriction. order lists Spec ids by priority, authored order breaking ties.

no citation recorded

perspectiveRecipe line 34 · specs/consumers/review-perspectives.sdp.md:34
recipe 37, the perspective filter, takes params.pack and params.perspective and returns { pack, perspective, totals: { members, selected }, diagnostics, selected, notSelected }.
perspectiveRows line 35 · specs/consumers/review-perspectives.sdp.md:35
each selected row is { id, matchedOn: [{ selector, value, claim }], blockingQuestions: [{ address, question }] } in the perspective's order and then authored order; claim is declared for a match on authored intent and anchored for a match through a binding; notSelected lists the remaining member ids in authored order.
perspectiveDiagnostics line 36 · specs/consumers/review-perspectives.sdp.md:36
an unknown selector, a value of the wrong type or a bindings selector with no via is a diagnostic row { selector, problem }, and the recipe still applies the selectors it understood.
Verification

Verifier bindings

  • test:protocol.perspective-filter-recipe · anchored · test anchor binding present · test/iteration-recipes.test.ts:760

    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 1: external run evidence from vitest 4.1.10

    Build: CI 391 · Branch: cursor/media-plan-and-articles-09b1 · Commit: 076cd4f1f85640d8236e5cca1bffffa68ab79a33 · Start: 2026-10-31T15:32:20.471Z · Stop: 2026-10-31T15:34:02.073Z

    NameSuiteResultDuration
    compares keyed values, keyed order and unkeyed sections while keeping bindings apartiteration loop: design diffpassed83.58 ms
    compares question fields by key, whole unkeyed questions, envelope fields and other sectionsiteration loop: design diffpassed24.03 ms
    reports added and removed Specs and Packs, filters the union of membership, and ignores source linesiteration loop: design diffpassed39.49 ms
    diagnoses required input and schema differences and compares common contentiteration loop: design diffpassed10.49 ms
    runs the documented base-worktree procedure, preserves constant anchors, and compares HEADiteration loop: design diffpassed23367.74 ms
    compares a keyed rule that becomes a flow at the same addressiteration loop: design diffpassed31.53 ms
    compares new Design entries across schema versions when the base corpus has noneiteration loop: design diffpassed26.78 ms
    diagnoses uncertain optional fields at base 0.9.0 and head 0.9.0iteration loop: design diffpassed14.73 ms
    diagnoses uncertain optional fields at base 0.9.0 and head 0.10.0iteration loop: design diffpassed18.9 ms
    diagnoses uncertain optional fields at base 0.10.0 and head 0.9.0iteration loop: design diffpassed28.09 ms
    normalizes legacy rule markers in graphs with comparable rule-key capabilityiteration loop: design diffpassed17.53 ms
    invents no order across rules and flows from a legacy baseiteration loop: design diffpassed26.36 ms
    compares a legacy base's keyed entries by order within each listiteration loop: design diffpassed21.05 ms
    reports proposal scopes outside the common schema as incomparableiteration loop: design diffpassed7.3 ms
    lists all authored reasons into and out of the planning subject in type/from/to orderrelation reasons in planning recipespassed18.61 ms
    keeps dependency reasons in context-bundle footingrelation reasons in planning recipespassed8.94 ms
    matches every declared selector, combines requirements, and keeps authored order unless prioritizediteration loop: perspective filterpassed69.31 ms
    matches layers and contexts only through named bindings and keeps anchored matches apartiteration loop: perspective filterpassed27.79 ms
    reports malformed and unsupported selectors while applying understood onesiteration loop: perspective filterpassed26.17 ms
    keeps term addresses, term lines and key maps through the section cutiteration loop: context bundlepassed29.65 ms
    keeps questions and declarations in one place and member-example steps only in their member rowiteration loop: context bundlepassed30.4 ms
    takes the declaration cut last only with addresses and keeps compact pointers and linksiteration loop: context bundlepassed91.81 ms
    cuts a pinned dotted key to its line when it has no entry addressiteration loop: context bundlepassed20.04 ms
    composes both scopes, dependency footing, declarations, example bindings and a perspective subsetiteration loop: context bundlepassed38.24 ms
    takes all six whole-mode cuts in fixed order and counts the complete returned value including Unicodeiteration loop: context bundlepassed70.24 ms
    keeps a pinned declaration whole through the sixth cut when its key contains a dotiteration loop: context bundlepassed21.59 ms
    reports invalid, missing, doubled and unknown scopes without a partial bundleiteration loop: context bundlepassed34.89 ms
    accepts term scopes and detects changed definitions through their authored keysiteration loop: proposal schema and checkpassed39.18 ms
    holds the schema and recipe to the same accepted and refused documentsiteration loop: proposal schema and checkpassed126.52 ms
    checks the complete scope union, resolves both graphs, and reports each change independentlyiteration loop: proposal schema and checkpassed15.33 ms
    agrees with recipe 35 on added, removed and changed entry values and on whole-Spec changesiteration loop: proposal schema and checkpassed13.3 ms
    excludes anchor-only changes and requires the caller's base graphiteration loop: proposal schema and checkpassed14.83 ms
    compares interleaved keyed rules and flows in their authored order and reports verifier changes apartiteration loop: comparison and budget edgespassed21.4 ms
    cuts example text once and preserves compact pointers after the sixth cutiteration loop: comparison and budget edgespassed60.02 ms
    reads the base graph and proposal from named JSON files through the real parameter seamiteration loop: comparison and budget edgespassed8.13 ms
    requires a test bound directly to an example before the bundle names it enablediteration loop: example enablementpassed17.83 ms
    compares rule order by text and other anonymous collections as a wholeiteration loop: anonymous collection orderpassed16.78 ms
    keeps addresses in each place when narrative, example, question and section text are cutiteration loop: protected entry addressespassed47.69 ms
Design view

Requirement drawing

  • Declared verifying examples: no declared verifying example.
Requirement drawing for spec:consumers.review-perspectives
The diagram as text
  • spec:consumers.review-perspectives: A Pack is read from a named perspective · declared Spec
  • spec:consumers.projections-model: Projections fan out from one graph without becoming truth stores · declared Spec
  • impl:protocol.perspective-filter-recipe: realizes the perspective filter in the shipped recipe catalog · anchored code · test/iteration-recipes.test.ts:753
  • test:protocol.perspective-filter-recipe: test:protocol.perspective-filter-recipe · anchored test binding · binding present · test/iteration-recipes.test.ts:760
  • spec:consumers.review-perspectives refines spec:consumers.projections-model · declared
  • impl:protocol.perspective-filter-recipe satisfies spec:consumers.review-perspectives · anchored
  • test:protocol.perspective-filter-recipe verifies spec:consumers.review-perspectives · anchored
Mermaid source

Copyable source; the Studio draws static SVG.

Preferred and chosen syntax: requirementDiagram; exact refines, satisfies and verifies, with claim words in nodes and per-edge comments.

Decisions

No decision record named.

Runtime
  • impl:protocol.perspective-filter-recipe · realizes the perspective filter in the shipped recipe catalog · test/iteration-recipes.test.ts:753

    Uses

    None.

Runtime observation: not tracked.

Evidence

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

Impact
Relations of spec:consumers.review-perspectives
The diagram as text
  • spec:consumers.delivery-session-on-ramp: Delivery sessions route work from current graph state
  • spec:consumers.design-slice: A slice reads a Pack as one design, with the architecture it touches and what each member needs next
  • spec:consumers.pack-design: The Pack context carries the Pack's design
  • spec:consumers.projections-model: Projections fan out from one graph without becoming truth stores
  • spec:consumers.review-perspectives: A Pack is read from a named perspective
  • spec:consumers.upgrade-kit.capability-adoption: Capability adoption counts where each capability is used and where it could apply
  • spec:consumers.review-perspectives dependsOn spec:consumers.pack-design · declared
  • spec:consumers.review-perspectives refines spec:consumers.projections-model · declared
  • spec:consumers.delivery-session-on-ramp dependsOn spec:consumers.review-perspectives · declared — the design loop narrows a Pack to one perspective's members
  • spec:consumers.design-slice dependsOn spec:consumers.review-perspectives · declared — a slice read for one concern takes the members a perspective selects
  • spec:consumers.upgrade-kit.capability-adoption dependsOn spec:consumers.review-perspectives · declared — perspectives are counted from the objects the caller passes
Mermaid source

Copyable source; the Studio draws static SVG.

Preferred syntax: flowchart. Chosen syntax: labelled flowchart, preserving exact relations, claims and folds.

Rests on

Rested on by

Distance 1

Distance 2

Distance 3

Distance 4

Distance 5

Distance 6

Relations

Relation and directionOther endClaimReasonExercised keys
dependsOn · outgoingThe Pack context carries the Pack's design
spec:consumers.pack-design · resolves
declaredNoneNone
refines · outgoingProjections fan out from one graph without becoming truth stores
spec:consumers.projections-model · resolves
declaredNoneNone
dependsOn · incomingDelivery sessions route work from current graph state
spec:consumers.delivery-session-on-ramp · resolves
declaredthe design loop narrows a Pack to one perspective's membersNone
dependsOn · incomingA slice reads a Pack as one design, with the architecture it touches and what each member needs next
spec:consumers.design-slice · resolves
declareda slice read for one concern takes the members a perspective selectsNone
dependsOn · incomingCapability adoption counts where each capability is used and where it could apply
spec:consumers.upgrade-kit.capability-adoption · resolves
declaredperspectives are counted from the objects the caller passesNone

Bindings

Implementation binding: present

  • impl:protocol.perspective-filter-recipe · realizes the perspective filter in the shipped recipe catalog · test/iteration-recipes.test.ts:753 · role projection

Design reference: none

Verifier binding: present

  • test:protocol.perspective-filter-recipe · anchored · test/iteration-recipes.test.ts:760 · test anchor

Expected-outcome oracle: none

Runtime observation: not tracked.

Run results: not recorded in the graph.

Findings

None.

Composing (0)

Composing needs the script.