# Chainable + Composable Traits as Stories with Telescopic Organization

Edition: 0.2.1-review · Status: versioned implementation guidance; project adoption remains explicit · Search alias: USaT · Scope: Rust code · Audience: engineering agents and people reviewing the governing commitments.

This is the compact, complete doctrine file for Rust work. The human lessons explain it; examples do not add universal requirements. It does not prescribe a rewrite or architecture for another language. Project owners retain business authority and define their own workflow, evidence and release cadence. Human learning work is judged by the designated human reviewer, not by this document or a course score.

## CS-00 · Read and retrieve without losing the commitment

Aliases: entry point; routing; AMem; retrieval; context; source of truth.

A section is a semantic unit. Keep its scope, qualifications and related section IDs together when retrieving it. In AMem, find the entry point with `Rust Chainable Stories CSINDEX`, then inspect its linked record IDs. For section search use contiguous aliases such as `CS01` for `CS-01`: the current tokenizer drops the short pieces of `CS-01`. Request full bodies explicitly. Titles and concept aliases support ordinary keyword search. If an excerpt seems to prohibit an otherwise necessary operation, retrieve its related sections before inventing an exception. A retrieved memory is a pointer into this versioned source, not a second writable doctrine.

For a task, start with CS-01–CS-04, then retrieve the sections governing the actual change. Do not load every lesson or reference implementation merely because it exists. Record a material unresolved decision in the project's existing workflow; this doctrine does not demand a new document for every edit.

Related: CS-13, CS-14.

## CS-01 · The story is the compile-time abstraction

Aliases: story; contract; compile time; abstraction; realization; occurrence; USaT.

A story expresses an owned commitment as a compile-time abstraction: the meaningful choices, relationships, prerequisites, consequences and legitimate continuations that govern the work. A realization implements that commitment. An occurrence binds actual actors, input, records and resources at runtime. Do not use those three nouns interchangeably.

The purpose is to keep organizational commitments readable, deliberately changeable and mechanically consequential. Software implements the organization's decisions; convenience in its machinery does not create competing authority. Put deliberate change resistance in the commitment, not in repeated human vigilance or synchronization of redundant copies.

A registration story can select Google identity, no password collected during registration, a pre-confirmation entry policy, and an independent confirmation obligation. One person's registration at a particular instant is an occurrence of that story. The compiler can constrain the selected composition; it does not know whether that person's current assertion or cookie is valid.

Workshop reference selections:

```rust
pub type OpenWorkshop<P> = Workshop<Google<P>, WithoutPassword, CookieValid>;
pub type ConfirmedWorkshop<P> = Workshop<Google<P>, WithoutPassword, ConfirmedOnly>;
```

An ordinary function may implement a leaf or a whole trivial operation. A reassuring trait name alone establishes nothing. Keep the governing story visible and mechanically connected to what its realization permits; do not replace that structure with scattered checks because an example happens to pass.

Related: CS-02, CS-03, CS-06, CS-08.

## CS-02 · Telescope through the same commitment

Aliases: telescoping; zoom; expressibility; navigation; root story; readability; PM.

At the widest view, a reader sees the selected business promise. A deliberate step inward reveals the constituent contracts and their compatibility. Further steps reveal how actual work is bound and how leaves perform it. Each level answers the next relevant question; it does not silently add responsibility to the story.

The audience changes the depth of reading, not the promise. A domain owner should be able to review the selected policy and consequences without reconstructing low-level code. An engineer should be able to follow the same names into executable relationships and implementation. A directory tree, diagram or fluent sentence can help, but cannot substitute for those relationships.

Preserve a useful path from the root into entry, later visits, independent obligations and recovery where the selected story owes them. Do not create a universal lifecycle contract merely to fit everything on one page. A deep abstraction earns its place through the product questions it answers.

A story register selects executable realizations and binds occurrences to actual resources. Binding untrusted input does not confer authority. Keep the selected relationships visible; a global service locator hiding them is not a telescope. Source organization serves decision ownership without mechanically copying an organizational chart. Search can find the entrance, but must not be the only way to reconstruct the story.

Relationship map for a protected story; runtime admission applies where its commitment needs current facts:

```mermaid
flowchart TD
  S[Selected story: compile-time abstraction] --> C[Compatible constituent contracts]
  C --> N[Permitted successor contracts]
  S -. realized by .-> I[Implementation]
  I -. binds .-> O[Occurrence: actual actor, input and resources]
  O --> A[Current-fact admission]
  A --> W[Bound continuation]
  N -. constrains .-> W
```

Related: CS-01, CS-03, CS-04, CS-12.

## CS-03 · Composition and chaining do different work

Aliases: compose; chain; successor; associated type; prerequisite; fork; parallel; derivability.

Composition joins meaningful, independently owned commitments into a larger commitment. Their interaction can introduce an obligation owned by the composition. Chaining connects what one constituent establishes to what a legitimate successor can consume. A chain may branch, pause, fan out, recover or lead to a later related visit; it need not be one fluent call, transaction or immortal value.

Parameterization expresses meaningful choices and constrains their admissible relationships. A bag of unrelated flags does not establish compatibility. Associated types, trait bounds, concrete carriers, data-bearing collaborators and ordinary values have distinct uses. A root bound should expose the relationships the consumer needs, rather than make every caller restate concrete implementation details.

Reference contract: verification selects an admissible registration successor and preserves its declared registration result. The private supertrait prevents a caller from inventing a protected stage.

```rust
pub trait VerifyIdentity: private::Stage + Sized {
    type Registered: RecordedRegistration;
    type Verified: AdmitRegistration<Registered = Self::Registered>;
    fn verify(self) -> Result<Self::Verified, IdentityFailure>;
}
```

Contrast: returning an unrelated `T`, accepting a caller-built `verified: bool`, or checking a stage name at every leaf would not establish that same successor relationship. The fallible result still represents a real provider outcome; the trait does not authenticate an assertion by itself.

Use what-if reasoning to follow implications of a proposed selection or change: which composition is still admissible, which promise changes, which other story remains independent, and what still requires runtime evidence. That consequence tracing is useful without equating the owner's broader word “derivability” with a derive macro, inheritance or one associated-type technique.

Related: CS-02, CS-04, CS-05, CS-15.

## CS-04 · Completeness has a jurisdiction

Aliases: scope; MECE; bounded context; actor; beneficiary; ownership; adjacent story.

Start with what the product owes: actor or initiator, beneficiary, mandate, selected work, outcome and relevant continuations. Complete the commitment within its named jurisdiction. Do not add every conceivable failure, lifecycle stage or neighbouring policy.

`WithoutPassword` in registration does not decide password policy for all later login. A pre-confirmation entry contract need not implement confirmed entry itself; the larger product must make their relationship clear. Reuse another owner's exposed contract where needed, without inventing a local version of its authority or importing its entire implementation.

Actor and beneficiary may differ. Two departmental contexts do not create two real people. An automated counterpart is not the initiating person's contribution. These distinctions matter when the story actually requires them; do not manufacture an approval ceremony for ordinary work.

Related: CS-01, CS-03, CS-06, CS-10.

## CS-05 · Share authority deliberately; let independent stories evolve

Aliases: DRY; duplication; reuse; AHA; KISS; YAGNI; SRP; replaceable implementation.

Similarity of implementation is not evidence of shared authority or a shared reason to change. Nearly identical leaves can correctly belong to independent stories. Before adding a mode argument to preserve a helper, ask whether the extra design problem would exist without that sharing.

A genuine common policy is a useful composable commitment. Reuse it intentionally; do not duplicate authoritative knowledge merely to imitate an example of independent evolution. Sharing vocabulary, policy, code, state and deployment are separate decisions.

Keep implementation replaceable beneath preserved commitments. A current semantic boundary or required substitution can justify an abstraction with one implementation. Hypothetical flexibility cannot. Retire obsolete helpers when no surviving commitment needs them; their incidental tests do not become product requirements.

Related: CS-03, CS-04, CS-12, CS-15.

## CS-06 · An occurrence retains actual work and resources

Aliases: binding; intent; scope ID; version; digest; resource identity; GAT; lifetime; newtype.

Bind the actual actor, subject, input, version, evidence, operation and resources on which a continuation relies. Compatible Rust types do not prove that two values denote the same runtime occurrence. Compare actual identities where required, and retain established bindings through the protected carrier or re-establish them at the relevant boundary.

A successor must not silently substitute different work. Later arguments are legitimate when they supply the new evidence or resource that its declared continuation needs. There is no universal argument-free rule.

An operation identity names one logical intent across attempts. A request correlation may change. Recovery uses the original intent and records; a later related visit is a new occurrence admitted against current facts. An edited form or newly selected provider must not retarget an already dispatched operation.

Related: CS-07, CS-08, CS-09.

## CS-07 · Use the representation that carries the relationship

Aliases: ZST; sized state; Sized; PhantomData; private field; consuming transition; affine; sealing; constructor.

State carriers may own validated input, resource borrows, transactions, observations or prepared outcomes. Encapsulate that data when it is part of the guarantee. Use a zero-sized marker for a data-free distinction; do not externalize required data merely to meet a zero-size target. ZSTs also implement Rust's `Sized`; size is not the doctrine's criterion.

Data-bearing reference state (private fields retain this actual workshop and subject):

```rust
pub struct Verified<'a, P, E> {
    workshop: &'a mut Workshop<Google<P>, WithoutPassword, E>,
    subject: String,
}
```

Control construction and mutation where a value permits protected progression. A public unchecked constructor, conversion, `Default`, deserializer or clone can undermine that boundary. Consuming non-copyable values restricts local reuse; Rust permits dropping values and does not thereby guarantee that a business obligation finishes.

Seal a capability surface when arbitrary implementations would forge the relationship. Keep intended trusted adapter or substitution ports open when that is their job. Orphan rules are not sealing. Privacy protects the chosen source boundary, not a repository from someone authorized to change it. Do not wrap harmless getters or incidental algorithm steps in ceremonial stages.

Related: CS-06, CS-08, CS-12.

## CS-08 · Static structure and current facts cooperate

Aliases: runtime alternatives; enum; Option; Result; admission; revocation; expiry; TOCTOU; trust.

The compiler makes declared relationships consequential. It does not establish current membership, expiry, truthful provider observations, independent real people, database contents or successful external effects. Check those facts at the owning boundary with the actual resources and concurrency discipline.

An established prerequisite should not become an avoidable `Option` or flag that every downstream leaf must rediscover. Genuine alternatives remain at their owner, using an enum, result or another appropriate interface. They can produce protected continuations. Neither banning enums nor using one platform-wide outcome vocabulary fulfills this obligation.

Recheck mutable authority after a boundary that invalidates the earlier facts. Do not keep a transaction open over a human delay or arbitrary external work merely to retain a type. Define what persists, what a later occurrence reloads, and what its current admission must establish. Fixture observations are teaching conveniences, not production authentication.

Related: CS-04, CS-06, CS-07, CS-09.

## CS-09 · Preserve what is known and what remains owed

Aliases: settlement; receipt; pending; unknown; timeout; lost acknowledgement; retry; recovery; cancellation; outbox.

Name the particular effect: local intent recorded, source request accepted, source effect applied, observation recorded, or independently verified result. A known pending operation is different from an unknown outcome. A failed view refresh does not erase a known successful mutation. Successfully recording a business rejection is different from refusing the requested review.

A timeout may leave an effect unknown. A denied recovery request does not prove the original operation was refused. Retain its identity and permitted reconciliation path. No universal four-way return type is required: a genuinely total operation can remain total, while an external effect must expose its actual uncertainty.

Outstanding work needs an actual owner and a survival mechanism for the boundary claimed. Dropping a follow-up, cancelling a worker or retiring a new-work entrance does not automatically cancel an obligation. Local ownership is not crash durability, source truth or distributed exactly-once execution. Stored intent, appropriate transactions, source idempotency, claims and fencing earn their place when the story requires them.

Related: CS-06, CS-08, CS-10, CS-12.

## CS-10 · Bound every consumer's expectations

Aliases: UI; frontend; BFFE; API; worker; projection; DTO; observation; consumer contract.

Expose only the choices and obligations relevant to the selected commitment. When a story protects server-owned work, the backend owns its permitted progression, results and recovery. A browser presents those outcomes; its cached availability, local flags or earlier green badge do not grant server authority. This boundary does not mandate a backend for a genuinely local story.

Engines own their source facts and effects. Ports describe the contracts through which stories use them. Adapters remain responsible for truthful observations and actions; a trait implementation or mocked invocation is not proof of a real effect.

A serializable receipt, refusal code or validated value is data under its stated contract. It is not a deserialized current permission. Keep known settlement separate from availability of a current projection. Presentation patterns such as MVVM and intentional dynamic dispatch are useful when they preserve these boundaries; their names decide no business policy.

Related: CS-04, CS-08, CS-09.

## CS-11 · Evidence serves the commitment; projects own their gates

Aliases: compiler feedback; tests; assertions; verification; workflow; release cadence; lint; project policy.

Use compiler feedback where it exposes an inadmissible composition; do not widen a bound merely to silence it. Use relevant observations for actual behavior, external effects and runtime uncertainty. If a project elects to maintain negative compiler examples, each must fail for its intended boundary, with a working valid use in the same environment. This is a condition on such evidence, not a requirement to create `tests/ui`, use `trybuild`, pin trait absence or preserve a private representation.

Ask what requirement gives an assertion authority. Independent expected behavior matters when implementation and test could repeat the same mistake. Tests of a discarded private helper need not preserve that helper forever; public compatibility and legitimate behavior remain real commitments.

The project defines its development and release sequence, configurations and acceptance evidence. This doctrine shapes what those checks should protect; it does not prescribe a universal first command, test count or release gate. Report unexecuted work honestly. More tests, lints or prose cannot repair an unreadable or wrongly owned story. Human learning exercises are judged by the designated human reviewer, not an automated course verifier.

Related: CS-02, CS-05, CS-12, CS-14.

## CS-12 · Govern changes to commitments

Aliases: policy change; implementation replacement; authority expansion; compatibility; migration; retirement; repository protection.

Distinguish replacement of machinery, representation changes, changes to promised behavior, authority expansion, consumer compatibility and migration of outstanding work. One impl may admit a new permission; many edits may preserve the commitment. Classify by consequence, not line count.

Use the accountable owner's actual mandate and the project's workflow. Do not invent a new approval ceremony for already authorized implementation. Make changes to governing commitments explicit to their owners. Appropriate repository protections and review scope must protect the governing boundary and its enforcement; an instruction file cannot substitute for those mechanisms.

Retiring a story requires a decision about existing consumers, history and outstanding obligations. Preserve neither a bad abstraction nor unnecessary documentation merely because they have accumulated. Deliberate resistance belongs in the meaningful commitment; repeated synchronization of redundant interpretations does not.

Related: CS-02, CS-05, CS-09, CS-11.

## CS-13 · Agent application procedure

Aliases: implementation task; coding agent; task scope; delegation; read order; context budget.

Locate the selected story and its owner. State the intended change and the promises that must remain unchanged. Telescope into the necessary contracts, actual binding, effect and recovery paths. Retrieve a relevant contrast or reference only when it resolves a concrete question. Choose the smallest truthful realization that preserves those relationships.

Before editing a governing boundary to repair a compiler error, determine whether the requested task already authorizes that changed promise. If authority or meaning is genuinely unresolved, ask the responsible person; do not invent it. Preserve the original scenario while proposing an alternative public design. Do not weaken an oracle just to accommodate the attempt.

Implement within the agreed ownership. Use the project's relevant checks and report observed results, remaining limits and any decision needing attention. Do not produce a universal workflow framework, a stack of decorative traits, or a long ritual report. A compact task handoff should let the next person find the actual governing change.

Related: CS-00, CS-02, CS-11, CS-12.

## CS-14 · Memory and search fidelity

Aliases: AMem; ingestion; aliases; section ID; version; supersession; lexical search; semantic search.

This file remains the source. An exported record carries its stable section ID, edition, status, exact section body, source hash and related IDs. Keep qualifications inside the same record as the rule they qualify. Search historical aliases such as USaT without treating them as a different doctrine.

A revised record must identify what it replaces. Do not append conflicting “canonical” paraphrases and hope embedding similarity selects the right one. Missing or ambiguous retrieval is a reason to read the source section. It is not evidence that a rule does not exist. Importing a review edition must not silently activate it as a governing instruction.

Related: CS-00, CS-13.

## CS-15 · What-if probes

Aliases: counterfactual; variation; derivability; independent change; consequence tracing.

For each change, predict the consequence from the story, then telescope to explain it. These are reasoning prompts, not an automatic test or a prescribed implementation.

| What changes? | What must be followed? |
|---|---|
| A label becomes a network lookup. | Which newly selected story owns the real failure; the original pure label need not inherit it. |
| Preview wording changes; archival wording does not. | Whether the two promises accidentally share a reason to change. |
| The one organization-owned identifier policy changes. | Both intended consumers must follow it; surrounding presentation stays independent. |
| Registration stops collecting a password. | That choice does not decide every later login policy. |
| Pre-confirmation entry changes from allowed to blocked. | The selected contract must change actual initial and later entry behavior. |
| A configured provider has the same Rust type as another instance. | The occurrence must retain the selected actual provider, not merely its type. |
| A record changes after admission. | Which resource/lifetime prevents substitution, or where current version is re-established. |
| A user leaves before a follow-up runs. | Who still owns the obligation and how it survives the claimed boundary. |
| A response is lost after the effect. | Original operation and intent survive; a changed form is different work. |
| A newer worker claims the operation. | Which generation may settle; consuming the older local value is insufficient. |
| An engine is replaced for new work. | Existing unknown work retains its original binding unless an authorized migration says otherwise. |
| An implementation is rewritten without changing the promise. | Which evidence protects the commitment and which incidental checks can retire. |

Related: CS-03, CS-05, CS-06, CS-09, CS-12.

## CS-16 · Preserve the distinction when adapting

Aliases: anti-pattern; cargo cult; scope; full name; reference code; learning.

The full identity is **Chainable + Composable Traits as Stories with Telescopic Organization**. Read it as a connected engineering method, not a checklist of syntax. A story is the compile-time abstraction; its occurrences still have real data and changing facts. Telescoping connects readable commitment to implementation without collapsing one into the other.

Do not infer: every value must be zero-sized; every function needs a trait; every stage needs all outcomes; every trait must be sealed; every later argument retargets work; all similar code must be shared; all sharing is bad; a move guarantees distributed completion; a receipt grants current access; a green build approves a policy change.

Full reference code demonstrates one carefully scoped realization. Lesson excerpts and what-if discussions develop judgment. Neither an implementation's incidental shape nor a learning exercise becomes a universal rule by repetition.

Related: CS-01, CS-02, CS-03, CS-04, CS-05, CS-06, CS-07, CS-08, CS-09, CS-10, CS-11, CS-12, CS-13, CS-14, CS-15.