Real ingestion and cache semantics
Ownership/visibility filtering, real pagination, README404 vs errors, hashed cache identity and saved row updates.
Integrations / INTERACTIVE WORKSHOP
Repo v1.0.0Build a fixture repository refresh
Edit provider rows and replay real ingestion calls. Observe private/foreign filtering, page boundaries, missing README behavior, cache identity, stale rows and partial persistence after failure.
01 / CONFIGURE
Choose a scenario. Change the inputs or build a sequence of commands.
02 / RUN
Execute the installed package against a new fictional example.
03 / INSPECT
Follow the result, actual calls, generated output and integration code.
THE WORKBENCH
Make it your example.
Your server-side changes are temporary. External-service examples use local response fixtures. Start with sample data.
Start with a preset, or change the input and run it.
The behavior is the example.
Your result will show the values, decisions and generated output from the actual package.
Calls used by this scenario. The handbook explains setup, authorizers, storage and error recovery.
The complete response is shown as data. Wide PHP integers are transported as exact decimal strings. Values are never evaluated as PHP or JavaScript.
Run an example to inspect its response.
The last two successful run states stay in this tab’s memory. Run a changed example to compare the actual package results.
What you can exercise here.
Failure recovery boundaries
Later failures can leave earlier writes; disappeared rows are not automatically removed.
Live account publication
Credentials, rate-limit scheduling, allowlists, sanitization and durable reconciliation belong in the consuming application.
UNDERSTAND THE BEHAVIOR
Ingestion, cache and publication have different boundaries.
Build fictional provider records and replay fetches, README reads and cache changes. Inspect persisted rows as well as the number of actual intercepted requests.
The provider builder controls local response data
Rows specify owner, visibility, README status and page. @owner follows the selected owner. The real RepoService filters ownership and visibility and writes real disposable Repository rows. No GitHub credential or network request is used.
Cache identity includes host configuration
Fetch twice to observe a cache hit. Editing the provider README does not invalidate an existing result. Credential rotation and visibility changes select different package cache identities; clear-cache affects only this request’s fixture cache.
Absence and failure are different
A README 404 is accepted as absence. A later 403 or failed list is an error and can leave earlier rows persisted. Missing rows in a subsequent response are not automatically purged; stale private rows need explicit publication policy.
Pagination needs a real full-page boundary
The two-page fixture pads page one to the provider’s actual 100-row boundary so the service genuinely requests page two. The response limits displayed persisted rows and summarizes very long request traces; persisted_count reports the full fixture count.
GO FURTHER
Try the boundary cases.
Test admission before publication
Start with public defaults and inspect owned, foreign and private rows. Expected: only eligible owned public records are fetched. Run Private mode includes owned private rows and compare persisted visibility; private mode is not authorization to export those rows publicly.
Observe a stale cache and explicit refresh
Run Cache survives provider fixture edits. Expected: the second fetch makes no new provider requests and retains its cached README. Append clear-cache and fetch: the edited fixture appears. Compare Credential and visibility cache isolation to see new transport work.
Distinguish missing data from partial failure
Run README 404 is accepted, then Failure after an earlier row persisted. Expected: absence is accepted; the failing fetch is rejected while an earlier row can remain in persisted. Inspect snapshots after each command, rather than inferring rollback from the failed response.
Inspect stale rows and genuine pagination
Run Missing rows are not purged and identify the pre-existing row left in storage. Run Two actual 100-row page boundaries and inspect page queries plus persisted_count. Expected: page two is actually requested; no stale-row reconciliation is silently simulated.
COMPOSE THE RESPONSIBILITIESUseful alone.
Useful alone.
Better when the boundaries fit.
Repo ingests provider metadata; a host application must reconcile ownership, visibility and stale rows before publishing. MrLaravel maps trusted source declarations. Neither package by itself establishes that code or repository contents are safe to disclose.