Chainable Stories · Handbook

A story is a compile-time abstraction. The compiler checks the selected relationships. Each registration still supplies real input and resources at runtime.

The code examples come from the complete Rust reference. Its small in-memory model makes the relationships visible.

The confirmation message remains owed. Entry and delivery can proceed independently under this policy. The workshop must retain the pending work after the browser leaves.

P names the provider's type. The workshop object holds the actual provider. CookieValid permits entry before confirmation; ConfirmedOnly waits for confirmation.

Both choices still require an active, unexpired session. See CS-01 and CS-04.

The configured provider must verify the submitted assertion. Admission then checks the current records. Selecting a provider type alone establishes neither fact.

Follow Signup in the root WorkshopStories contract to this successor:

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

Verified must support AdmitRegistration. verify(self) consumes the submitted stage and returns either that successor or an identity failure.

The root also exposes visits, delivery and confirmation. Those continuations remain discoverable without making every step own the whole account lifecycle. CS-02.

Follow the root's Visit relationship to EnterWorkshop. It checks current session facts and applies the selected entry policy again.

Separate functions can keep preview and archive independent. A shared policy contract can serve both identifier consumers.

For the wording change, two small functions are enough:

fn preview_label() -> &'static str { "Join the workshop" }
fn archive_label() -> &'static str { "Registration open" }

Compare the change's reach:

Before adding a mode flag to a helper, ask which product requirement needs that shared behavior. A current boundary may justify an abstraction with one implementation; hypothetical reuse does not. CS-05.

Only if the requirement changes them. Sharing the identifier rule does not make the consumers' layouts jointly owned.

The fields are private. The mutable borrow retains this workshop through the registration steps. Other code cannot swap its store or provider during that borrow.

Later handles check the workshop instance at runtime:

if !Arc::ptr_eq(&self.workshop.identity, &self.session.workshop) {
    return Err(EntryFailure::ForeignSession);
}

A zero-sized marker fits a data-free choice. This state needs both a subject and a resource borrow. CS-06, CS-07.

Yes. A delivery observation can add evidence about the already-bound operation. It must identify that operation. Replacing the reviewed version is a different change.

The reference separates these identity outcomes:

pub enum IdentityFailure {
    Rejected,
    Unavailable,
    InvalidObservation,
}

A rejected assertion and an unavailable provider call for different responses. Neither records an account.

Represent the alternatives the operation really has. A pure label formatter can return its label directly. Remote delivery needs its own outcome and recovery contract. CS-08, CS-09.

The review completed with a rejection decision. Refusing an unauthorized person's attempt to review is a separate outcome.

These reference implementations produce different entry behavior:

impl EntryRule for CookieValid {
    fn permits(_: bool) -> bool {
        true
    }
}
impl EntryRule for ConfirmedOnly {
    fn permits(confirmed: bool) -> bool {
        confirmed
    }
}

Selecting ConfirmedOnly changes a product rule. Replacing how an unchanged rule reads its records may be an implementation change.

If a compiler error exposes a forbidden combination, check the requirement before widening the bound. The project owns its checks and release cadence. CS-11, CS-12.

Determine whether the requested change authorizes the newly admitted behavior. Tests can support that decision; they cannot supply the owner's mandate.

In A, separate leaves allow independent changes. An is_archive flag added only to save the helper can create unwanted coupling.

In B, a shared policy keeps both consumers aligned. Their surrounding layouts can still change independently. CS-05.

A has independent wording decisions. B has shared policy authority. Similar code hides that difference.

An owner could later unify A's wording or split B's policies. That would change the agreement, so make the decision explicit.

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

The selected policy reaches the current entry check:

if !account.active {
    return Err(EntryFailure::Revoked);
}
if self.workshop.now >= account.expires {
    return Err(EntryFailure::Expired);
}
if !E::permits(account.confirmed) {
    return Err(EntryFailure::ConfirmationRequired);
}

Initial and later visits use this same handler. Delivery remains independently available. CS-04, CS-08.

ConfirmedOnly yields refused, refused, allowed. An expired or revoked session is still refused after confirmation.

Removing registration password collection does not decide later login. Follow that story's own contract and owner.

The reference checks the actual workshop instance:

if !Arc::ptr_eq(&self.workshop.identity, &self.session.workshop) {
    return Err(EntryFailure::ForeignSession);
}

A proposal story would also retain the approved version or digest. Check it when publishing, using the current stored record. CS-06.

A needs the same store instance and record. B needs the exact reviewed content. A new source observation can be valid later input if it identifies the original work; a replacement proposal needs its own decision.

For B, retain the original operation ID, input and source binding. A retry's correlation ID may change; it does not identify a new business intent by itself.

If the source can establish that the original effect did not occur, follow its retry contract. Otherwise preserve uncertainty. CS-09.

Now replace a pure label formatter with a network lookup. The lookup story needs failure handling; the pure formatter can remain total.

The reference keeps the obligation in its workshop object:

drop(work);
let delivery = shop.pending_confirmation().unwrap();
drop(delivery);
assert_eq!(shop.owed_messages(), 1);

Dropping either handle leaves one message owed. Destroying the workshop object loses its memory. A production story that promises restart recovery needs durable storage and source-safe recovery. CS-07, CS-09.

It survives abandoned handles while the workshop object lives. It does not survive losing the process.

For retirement, decide how existing work will finish, migrate or be cancelled under proper authority. Removing the new-registration route does not settle those obligations.

A recovery record must retain its source binding. A worker result may need a current claim or generation check before it can settle stored work. These distributed mechanisms lie beyond the in-memory reference.

For C, trace the assertion to the consumer's requirement. Keep required behavior and compatibility; retire obsolete private arrangements. CS-06, CS-11.

A needs evidence from the original source or an authorized migration. B needs the current right to settle. C needs the actual consumer promise, which may never have required three calls.

Show the meaningful composition and successors. Keep required data inside protected states, and identify facts that must be checked at runtime.

Explain how the design preserves the original work through the interruption. Use your project's normal checks. A different implementation can satisfy the same story.

Follow both changes back to the original promise. Point to the decision owner, the admitted work, current checks and remaining obligations. Explain any limit your design does not cross.

This generic consumer follows the root contract:

fn register<S: WorkshopStories>(shop: &mut S, assertion: &str) -> (S::Session, S::Confirmation) {
    shop.signup(assertion.into())
        .verify()
        .unwrap()
        .admit()
        .unwrap()
        .record()
        .into_followups()
}

Here, unwrap() belongs to a known-valid fixture. An application must handle the declared refusal and availability outcomes.

The two follow-ups are exposed together:

pub trait RecordedRegistration: private::Stage + Sized {
    type Session;
    type Confirmation;
    fn into_followups(self) -> (Self::Session, Self::Confirmation);
}

The workshop keeps owed work independently of either returned handle. The entry policy is sealed; the identity adapter is an open trusted port. Both choices have specific purposes in this example.

This attempted shortcut is rejected by the compiler:

shop.signup("a".into()).record();

Submitted has no record() method. Verification and admission produce the required successor.

Verified: AdmitRegistration constrains the next capability. Entry still checks current expiry and revocation. Pending work survives dropped handles, but only while the in-memory workshop lives.