cgreene / cgreene/farewright

Implement director clock, disruption injection, and actual-trip fixture fallback

Open
#29 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

demo-integrity enhancement testing workstream:adapters workstream:core workstream:deployment
Dominant language
No language data
Stars
0
Forks
0
Avg merge
8h 21m
Merged PRs (30d)
2

Description

Outcome

The demo can compress time and recover transparently without rewriting user inputs, source events, or external history.

Scope

  • Implement authenticated demo-admin clock advancement with real recorded_at and simulated effective_at.
  • Inject a plausible schedule change into the actual booked return.
  • Capture versioned safe phase seeds and atomically materialize new run-scoped fixture histories with FixtureSeedApplied and fresh simulated references.
  • Parameterize user-facing prebooking fixture runs from the confirmed request/mandate and post-booking runs from actual trip facts.

Acceptance

  • Director cannot alter mandate, supplier result, or user request.
  • Prior runs/provider objects remain immutable; late callbacks stay with their original run and cannot affect the new run.
  • Start/switch is rejected while the active run has pending approval/payment action or planned/in-progress/unknown effect.
  • The atomic switch invalidates any remaining setup/review handoff, so no browser page from the closed run can mutate the new one.
  • Generic seeds are private-engineering-only before booking; user-facing seeds always use that user's confirmed facts.
  • Every fixture run has its own replayable event history, fresh simulated references, fixture provenance, and visible FIXTURE MODE label; rebuild needs no source run/seed snapshot.
  • No command claims to rewind Duffel, Stripe, OAuth, or webhook state.

Dependencies

  • #11, #13, #18, and #25.

Review

Demo-integrity, privilege, replay, and run-isolation review.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading dependencies #11, #13, #18, and #25, then map the acceptance criteria for clock advancement, run isolation, fixture provenance, and privilege boundaries. Done means all listed invariants hold, including immutable prior runs, safe atomic switching, user-specific confirmed facts, replayable histories, and no external-state rewind claims.

Written by the indexing model from the issue text.

Assessment

Domain
authentication, backend, payments, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.