GitHubDesign partner

ONE REPOSITORY · EIGHT JOBS

Follow the evidence past go-live.

Move acme-support-agent from a clean checkout to an inspectable memory, a handover, a change review, a routed unknown, and a practice-level responsibility view.

SCENARIO 01

Connect the repo

A clean fictional checkout is visible with source, prompts, tools, evaluations, configuration, and documentation, but no Onboard UX artifacts yet.

01 · REPOSITORY

What is visible

acme-support-agent/fictional fixture
  • src/
    • agent/orchestrator.py
  • prompts/
    • refund-triage.md
  • tools/
    • refund_api.py
  • evals/
    • probes/refund-routing.yaml
  • config/
    • routing.toml
  • docs/
    • runbook.md

02 · ACTION

What happens next

IllustrativeChoose local repositoryPlanned local interface — illustrative.
Verified CLI foundationInspect the repositoryadopt detect ./acme-support-agent --jsonThe public Alpha CLI detects repository archetype; it does not run the simulated Workbench.

03 · ARTIFACT

What is produced

outputs/connection.jsonIllustrative fixture

Repository and observation summary

archetype
AI system · high confidence
observed roots
6
unknown boundaries
2

04 · OUTCOME

Work avoided

See what the local foundation recognizes and what remains unknown before running a useful job.

Limit

Detection is not full system comprehension, and the simulated Local Workbench does not execute any product code.

Choose another scenario above, or use Left and Right Arrow while a scenario tab is focused.

SCENARIO 02

Understand what shipped

The repository is connected, an observation boundary is declared, and structural plus delivery-history inputs are available.

01 · REPOSITORY

What is visible

acme-support-agent/fictional fixture
  • src/
    • agent/orchestrator.py
  • prompts/
    • refund-triage.md
  • tools/
    • refund_api.py
  • evals/
    • probes/refund-routing.yaml
  • config/
    • routing.toml
  • docs/
    • runbook.md

02 · ACTION

What happens next

Prototype onlyMap the repositoryadopt map . --firm acme --engagement support-agent --system acme-support-agent --archetype ai --jsonPrototype only — `adopt map` is not available on public main.
IllustrativeRecover decision evidencePlanned workflow — illustrative.

03 · ARTIFACT

What is produced

outputs/blueprint.jsonIllustrative fixture

System identity and relationship graph

observed identities
24
representative nodes
8
unresolved references
2
outputs/decisions.jsonIllustrative fixture

Evidence-linked decision record

decision
dual approval above USD 500
evidence
PR-184 · ACME-91
intent confidence
owner confirmation

04 · OUTCOME

Work avoided

One view explains what shipped and the recoverable evidence for why the dual-approval rule exists.

Limit

Missing rationale and runtime-only behavior remain visibly unresolved rather than inferred.

SCENARIO 03

Ask a project question

The Blueprint, decisions, and durable bindings are populated before the delivery-time threshold changes.

01 · REPOSITORY

What is visible

acme-support-agent/fictional fixture
  • src/
    • agent/orchestrator.py
  • prompts/
    • refund-triage.md
  • tools/
    • refund_api.py
  • evals/
    • probes/refund-routing.yaml
  • config/
    • routing.toml
  • docs/
    • runbook.md

02 · ACTION

What happens next

IllustrativeAsk why refunds above the approval threshold need two approversPlanned local assistant — illustrative.

03 · ARTIFACT

What is produced

outputs/answers.jsonIllustrative fixture

Answer with provenance and knowledge state

delivery answer
known · cited
current threshold
change review pending
refund authority
unknown · route to owner

04 · OUTCOME

Work avoided

The answer cites PR-184, ACME-91, and routing configuration without returning first to the original FDE.

Limit

The assistant must return unknown, stale, or observation-limited instead of extrapolating.

SCENARIO 04

Find what is missing

The fixture has 24 observed identities: 19 covered and current, three uncovered, and two explicitly observation-limited.

01 · REPOSITORY

What is visible

acme-support-agent/fictional fixture
  • src/
    • agent/orchestrator.py
  • prompts/
    • refund-triage.md
  • tools/
    • refund_api.py
  • evals/
    • probes/refund-routing.yaml
  • config/
    • routing.toml
  • docs/
    • runbook.md

02 · ACTION

What happens next

Verified CLI foundationRecompute known coverageadopt coverage recompute --system acme-support-agent --jsonAvailable deterministic coverage primitive; the visual gap workflow is planned.
Verified CLI foundationWrite the observability statementadopt boundary --answers adopt/boundary-answers.json --archetype ai --write-statement ./onboard-output/coverage-boundary.mdAvailable boundary primitive; the guided Workbench review is planned.

03 · ARTIFACT

What is produced

outputs/gaps.jsonIllustrative fixture

Coverage and gap table

observed
24
covered/current
19
uncovered / outside
3 / 2
outputs/coverage-boundary.mdIllustrative fixture

Coverage and limitations statement

repository evidence
observed
production telemetry
not connected
channel history
not imported

04 · OUTCOME

Work avoided

Receive three targeted knowledge tasks and a transparent explanation of the two excluded surfaces.

Limit

Coverage is relative to the 24 observed identities, not a universal completeness claim.

SCENARIO 05

Create the handover

Priority gaps have been reviewed, decisions carry confirmation state, and owners plus freshness metadata are available.

01 · REPOSITORY

What is visible

acme-support-agent/fictional fixture
  • src/
    • agent/orchestrator.py
  • prompts/
    • refund-triage.md
  • tools/
    • refund_api.py
  • evals/
    • probes/refund-routing.yaml
  • config/
    • routing.toml
  • docs/
    • runbook.md

02 · ACTION

What happens next

Verified CLI foundationExport the local system-memory bundleadopt export ./onboard-exportAvailable export foundation; client-ready handover generation remains planned.
IllustrativeGenerate handover packPlanned workflow — illustrative.

03 · ARTIFACT

What is produced

outputs/handover/index.mdIllustrative fixture

Dated handover and runbook package

map + decisions
included with sources
owners + gaps
included
final approval
owner review required

04 · OUTCOME

Work avoided

A dated, source-linked draft replaces blank-page handover authoring.

Limit

Unverified items remain marked and a responsible owner must approve the pack.

SCENARIO 06

Something changes after go-live

CHANGE-207 proposes moving the approval threshold from USD 500 to USD 750 while the answer, runbook, and baseline still describe 500.

01 · REPOSITORY

What is visible

acme-support-agent/fictional fixture
  • src/
    • agent/orchestrator.py
  • prompts/
    • refund-triage.md
  • tools/
    • refund_api.py
  • evals/
    • probes/refund-routing.yaml
  • config/
    • routing.toml
  • docs/
    • runbook.md

02 · ACTION

What happens next

Planned serviceReview affected knowledgePlanned operated service — illustrative; it does not change application code.

03 · ARTIFACT

What is produced

outputs/freshness.jsonIllustrative fixture

Grouped impact and freshness review

change
USD 500 → USD 750
affected items
answer · runbook · baseline
automatic update
not allowed

04 · OUTCOME

Work avoided

Affected knowledge is grouped into one confirm-or-correct review and the stale answer is withheld.

Limit

The service identifies knowledge impact; it neither validates the business change nor fixes application behavior.

SCENARIO 07

Route what requires a human

A client asks whether the assistant can issue a refund automatically, but no approved evidence grants that authority.

01 · REPOSITORY

What is visible

acme-support-agent/fictional fixture
  • src/
    • agent/orchestrator.py
  • prompts/
    • refund-triage.md
  • tools/
    • refund_api.py
  • evals/
    • probes/refund-routing.yaml
  • config/
    • routing.toml
  • docs/
    • runbook.md

02 · ACTION

What happens next

IllustrativeAsk why refunds above the approval threshold need two approversPlanned local assistant — illustrative.
Planned serviceAnswer with evidence or route to the ownerPlanned operated service — illustrative; not production support or ITSM.
Planned serviceRun the client transitionPlanned operated service — illustrative.

03 · ARTIFACT

What is produced

outputs/answers.jsonIllustrative fixture

Answer with provenance and knowledge state

delivery answer
known · cited
current threshold
change review pending
refund authority
unknown · route to owner
outputs/live-answer.jsonIllustrative fixture

Answer, provenance, and escalation record

answer state
unknown · no authority evidence
owner role
Client operations owner
routing
prepared question
outputs/handover/transition-record.jsonIllustrative fixture

Handover ownership and readiness record

owner
Client operations owner
open confirmation
refund authority

04 · OUTCOME

Work avoided

Refuse to guess, route a prepared question to the role-based owner, and preserve the confirmed correction for reuse.

Limit

Human knowledge routing is not incident response or an SLA-backed support desk.

SCENARIO 08

See the portfolio

The selected acme-support-agent record has one freshness review and one routed question alongside anonymized aggregate fixture rows.

01 · REPOSITORY

What is visible

acme-support-agent/fictional fixture
  • src/
    • agent/orchestrator.py
  • prompts/
    • refund-triage.md
  • tools/
    • refund_api.py
  • evals/
    • probes/refund-routing.yaml
  • config/
    • routing.toml
  • docs/
    • runbook.md

02 · ACTION

What happens next

Planned serviceReview the deployment portfolioPlanned Fleet Console — illustrative; no live customer systems are connected.

03 · ARTIFACT

What is produced

outputs/fleet.jsonIllustrative fixture

Portfolio governance grid

systems needing review
2 of 4
open questions
3
ownerless items
1

04 · OUTCOME

Work avoided

The practice leader sees the selected system responsibility and the aggregate portfolio queue.

Limit

The simulated grid reports knowledge and adoption governance, not live system health.

THE THREAD THROUGH EVERY SCENARIO

Repository input becomes a reviewable responsibility.

  1. 01Observe only approved evidence.

    Unknown and inaccessible surfaces stay visible.

  2. 02Produce an inspectable artifact.

    Maps, answers, gaps, and reviews retain their sources and state.

  3. 03Reduce repeat FDE work.

    The output supports handover and adoption without pretending to operate the application.

See the FDE first sessionExplore every workflow