An AI agent that shows its working
Ask one of three questions about this site and replay a real agent session answering it: every file it opened, every command it ran, and the line numbers behind each claim.
- Competency
- Interactive AI chat
- Context
- Quidne · Interactive AI chat
- Built with
- Claude Code, Claude Opus 5.5, Python, JavaScript
Try it
What has to pass before a release counts as done?
11 tool calls
- Bash
$ git ls-files | head -80 - Bash
$ git ls-files | tail -n +81 | head -80 - Read
pipelines/01-site.yml - Bash
$ git ls-files tests tools | head -30 - Grep
“(?i)done|release|verify|gate|smoke|PROD” in README.md - Read
deploy/modules/verify-site.ps1 - Read
pipelines/templates/steps-api-deploy.yml - Grep
“-Check '|function Invoke-VerifyApi|return 1|checks passed” in deploy/modules/verify-api.ps1 - Bash
$ git -C ../Quidne.Deploy show v1.2.0:pipelines/swa-pipeline.yml | grep -n -i -E "verify|gate|dependsOn|condition" | head -40 - Bash
$ git -C ../Quidne.Deploy grep -n -i -E "Invoke-Verify|verify" v1.2.0 -- pipelines | head -30 - Read
deploy/modules/verify-api.ps1 · lines 195–234
The repository never defines "done" in so many words. The closest thing is the release pipeline: a release is finished when a build has passed its test gates and then been deployed to, and checked live on, each environment in turn. The pipeline builds once and runs four gates. ContentIntegrity and ConfigSchema run Pester specs over the site content and config. ModuleSyntax checks the JavaScript in src/js. DeploySpecs runs the deploy, verify, local, tools and site-content specs plus the tests inside deploy/modules pipelines/01-site.yml:40–67. That build is deployed to DEV first. UAT depends on DEV and PROD depends on UAT, and both of those run only from main pipelines/01-site.yml:91–102. The README describes that promotion to UAT and PROD as happening "by approval" README.md:13.
In each environment the contact API is deployed before the site, from the package the build already tested. Its live checks run straight after, and any failure stops the step pipelines/templates/steps-api-deploy.yml:22–37. Those checks cover four things. The health endpoint must be up and report the right environment and commit. Requests from the site's own address must be allowed through, while other origins are refused. Bad submissions must be rejected. The TLS certificate must be valid. A single failure means the API fails verification deploy/modules/verify-api.ps1:216–231.
The site then has its own live checks. The home page must load and carry a build marker. Unknown paths must return the site's own 404 page. Plain http must redirect to https. The certificate must be valid. Every deployed file must match the hashes in the build's file list. Security and cache headers must match the checked-in config. The served app-config.json must name the right environment and settings deploy/modules/verify-site.ps1:837–843. In the pipeline the resume page must also return 200, and the file list must be the one the build published. Rebuilding it on the deploy machine would only compare those files with themselves deploy/modules/verify-site.ps1:882–896. One failed check fails the run. So does a pass where the number of checks run differs from the planned count stamped into the site deploy/modules/verify-site.ps1:850–863.
Some things I could not confirm. The shared pipeline template in Quidne.Deploy (at tag v1.2.0) calls the site verification and fails when it reports errors, but that template is outside this repository, so I cannot cite it. I also did not confirm that the gates must pass before packaging starts. The approvals before UAT and PROD are set in Azure DevOps, not in any file here, so I could not see who approves them or whether they are required. Finally, I did not read the Pester test files themselves, so I can only say which suites run, not what each one checks.
8 cited sources
pipelines/01-site.yml:40–67gates: - name: ContentIntegrity steps: - template: /pipelines/steps/node.yml@QuidneDeploy - template: /pipelines/steps/pester.yml@QuidneDeploy parameters: testPath: tests/Site.Integrity.Tests.ps1 - name: ConfigSchema steps: - template: /pipelines/steps/pester.yml@QuidneDeploy parameters: testPath: tests/Site.Config.Tests.ps1 - name: ModuleSyntax steps: - template: /pipelines/steps/module-syntax.yml@QuidneDeploy parameters: scriptRoot: src/js - name: DeploySpecs steps: - template: /pipelines/steps/pester.yml@QuidneDeploy parameters: testPath: - tests/Deploy.*.Tests.ps1 - tests/Verify.*.Tests.ps1 - tests/Local.*.Tests.ps1 - tests/Tools.*.Tests.ps1 - tests/Site.Content.Tests.ps1 - deploy/modulespipelines/01-site.yml:91–102- target: UAT serviceConnection: uat-quidne-site environment: uat-quidne-site dependsOn: DeployDEV mainOnly: true preview: true - target: PROD serviceConnection: prod-quidne-site environment: prod-quidne-site dependsOn: DeployUAT mainOnly: true preview: trueREADME.md:13| `pipelines/` | `01-site.yml`, extending Quidne.Deploy's `swa-pipeline.yml`: build the site and API once, deploy DEV, promote to UAT and PROD by approval |pipelines/templates/steps-api-deploy.yml:22–37# The package the build tested, not a rebuild of this agent's checkout. $result = Invoke-DeployApi ` -RepoRoot $repoRoot ` -Environment '$(deployTarget)' ` -PackagePath '$(Pipeline.Workspace)/api-package/Quidne.Contact.zip' ` -Version '$(Build.SourceVersion)' $result | Select-Object Environment, FunctionApp, DefaultHostname, Version | Format-List | Out-String | Write-Host $code = Invoke-VerifyApi ` -RepoRoot $repoRoot ` -Environment '$(deployTarget)' ` -Hostname (Get-DeploymentDefaults -RepoRoot $repoRoot -Environment '$(deployTarget)').ApiHostname ` -ExpectedVersion '$(Build.SourceVersion)' if ($code -ne 0) { throw "Invoke-VerifyApi reported $code failing checks for $(deployTarget)." }deploy/modules/verify-api.ps1:216–231$results = [System.Collections.Generic.List[object]]::new() $results.AddRange([object[]]@(Test-ApiAvailability -Hostname $Hostname -Environment $Environment -ExpectedVersion $ExpectedVersion)) $results.AddRange([object[]]@(Test-ApiCors -Hostname $Hostname -Origin $Origin)) $results.AddRange([object[]]@(Test-ApiRejection -Hostname $Hostname)) $results.AddRange([object[]]@(Test-SiteTls -Hostname $Hostname)) foreach ($result in $results) { $mark = if ($result.Passed) { 'PASS' } else { 'FAIL' } Write-Host " $mark [$($result.Check)] $($result.Name) — $($result.Detail)" } $failed = @($results | Where-Object { -not $_.Passed }) if ($failed.Count -gt 0) { Write-Host "$($failed.Count) of $($results.Count) checks failed." return 1 }deploy/modules/verify-site.ps1:837–843$results = [System.Collections.Generic.List[object]]::new() $results.AddRange([object[]]@(Test-SiteAvailability -Hostname $Hostname -RequireResumePage:$RequireResumePage)) $results.AddRange([object[]]@(Test-SiteTls -Hostname $Hostname)) $results.AddRange([object[]]@(Test-SiteContentIdentity -Hostname $Hostname -Manifest $manifest)) $results.AddRange([object[]]@(Test-SiteSecurityHeader -Hostname $Hostname -ConfigPath $configPath)) $results.AddRange([object[]]@(Test-SiteCacheHeader -Hostname $Hostname -ConfigPath $configPath -Manifest $manifest)) $results.AddRange([object[]]@(Test-SiteAppConfig -Hostname $Hostname -Environment $Environment -ExpectedSetting $expectedSetting -ExpectedCheckCount $plan.Total))deploy/modules/verify-site.ps1:882–896# Recomputing the manifest here would compare the agent's tree against itself, green even on a failed upload. if ([string]::IsNullOrWhiteSpace($ManifestPath) -or -not (Test-Path -LiteralPath $ManifestPath -PathType Leaf)) { throw "Invoke-Verify needs the build's site manifest; none at '$ManifestPath'." } if (-not (Get-Command -Name 'Get-DeploymentDefaults' -ErrorAction SilentlyContinue)) { throw "Get-DeploymentDefaults is not available. Dot-source deploy/Import-Site.ps1 first." } $hostnameArgs = @{} $verifyHostname = (Get-DeploymentDefaults -RepoRoot $RepoRoot -Environment $Environment).VerifyHostname if (-not [string]::IsNullOrWhiteSpace($verifyHostname)) { $hostnameArgs['Hostname'] = $verifyHostname } Invoke-VerifySite -RepoRoot $RepoRoot -Environment $Environment -ManifestPath $ManifestPath ` -RequireResumePage @hostnameArgsdeploy/modules/verify-site.ps1:850–863$failed = @($results | Where-Object { -not $_.Passed }) if ($failed.Count -gt 0) { Write-Host "$($failed.Count) of $($results.Count) checks failed." return 1 } # The site publishes the planned count, so a plan that drifted from the run is a false claim on the page. if ($results.Count -ne $plan.Total) { Write-Host "All $($results.Count) checks passed, but the stamped plan says $($plan.Total)." return 1 } Write-Host "All $($results.Count) checks passed." 0
How did quidne.com move to Static Web Apps without downtime?
11 tool calls
- Bash
$ ls workstreams/ && git log --oneline | head -30 - Grep
“(?i)static web app|downtime|cutover” in workstreams - Grep
“(?i)downtime|cutover|cut over|outage|dns|apex” in workstreams/quidne-public-website-refactor.tracker.md - Grep
“(?i)downtime|cutover|cut over|outage” in workstreams/quidne-public-website-refactor.md - Read
workstreams/quidne-public-website-refactor.md · lines 340–379 - Glob
docs/*.md - Grep
“(?i)P7\.|cutover|cut over|www” in workstreams/quidne-public-website-refactor.tracker.md - Read
workstreams/quidne-public-website-refactor.tracker.md · lines 404–428 - Read
workstreams/quidne-public-website-refactor.tracker.md · lines 600–611 - Read
workstreams/quidne-public-website-refactor.tracker.md · lines 457–468 - Read
workstreams/quidne-public-website-refactor.tracker.md · lines 479–479
The records show that quidne.com did not move to Static Web Apps without downtime. The www hostname appears to have switched with no recorded outage. The apex domain, quidne.com itself, returned a 404 page for about 13 minutes during its switch.
The plan for the move is in the refactor workstream. It moves one step at a time, and each step can be undone. Before any DNS change, a full snapshot of the DNS records is saved, and the 300-second TTL means a rollback takes effect within about five minutes workstreams/quidne-public-website-refactor.md:350–352. The order was: DEV, then UAT, then PROD set up but checked only on its own azurestaticapps.net address while the old App Service kept all traffic. Next came www alone with a 48-hour soak, then the apex in a low-traffic window, and finally retiring the old App Service at T+30 days workstreams/quidne-public-website-refactor.md:354–366.
The tracker records the first four steps as done. DEV went live on 2026-09-22 and UAT on 2026-09-23. PROD was checked against its default hostname with the DNS zone unchanged before and after. The www soak ran from 2026-09-23 to 2026-09-25 and logged 76 samples, 75 OK and one RED. The RED sample is put down to the monitoring machine being offline, not to the site workstreams/quidne-public-website-refactor.tracker.md:603–607. Throughout the soak, the apex was still served by the old App Service IP, 104.42.231.5 workstreams/quidne-public-website-refactor.tracker.md:607.
The apex was switched on 2026-09-25 at about 20:15Z. A DNS snapshot was taken first, and the domain reached Ready on the 10th check. The new site then passed all 39 checks, and mail records were confirmed unaffected workstreams/quidne-public-website-refactor.tracker.md:410–422. However, the tracker states that the order of steps caused a gap: the new DNS record was written before Azure finished validating the domain. As a result, http://quidne.com/ returned the Static Web App's 404 page for about 13 minutes. A future re-cutover should expect the same gap unless the order is changed workstreams/quidne-public-website-refactor.tracker.md:479.
The final step, stopping and then deleting the old App Service, is still marked "Not started" workstreams/quidne-public-website-refactor.tracker.md:457–463. The rollback target therefore still exists, as far as the tracker shows. Several things are outside what I could check here. The plan names docs/DNS-CUTOVER.md as holding the revert commands, but there is no docs/ folder in the repository. The soak log and DNS snapshots are stored outside the repository, so I relied on the tracker's summaries of them. I also cannot confirm from the repository whether the App Service has been stopped since the tracker was last updated.
7 cited sources
workstreams/quidne-public-website-refactor.md:350–352Needs Phase 0. Each phase is independently revertible; every DNS-mutating run publishes a full `record-set list` snapshot as an artifact first, and `docs/DNS-CUTOVER.md` carries the literal revert commands. TTL 300 everywhere means worst-case restore is ~5 minutes.workstreams/quidne-public-website-refactor.md:354–3661. **DEV** — full pipeline, `dev.quidne.com`. Zero production risk; settles the remaining spikes. 2. **UAT** — same at `uat.quidne.com`. The sign-off surface, including `/resumes/jasonking/`. 3. **PROD provisioned, no DNS** — verify everything against the `*.azurestaticapps.net` hostname. The old App Service still serves 100% of traffic, untouched. 4. **`www` first** — T-24 h drop TTLs; snapshot; repoint `www` CNAME to the SWA and bind the domain. `www` serves the new site while the apex still serves the old. **Soak 48 h.** Blast radius is `www` only; revert is one `set-record`. 5. **Apex** — per the Phase 5 sequence, in a low-traffic window. On rollback, restore `A @ 104.42.231.5` but **leave the SWA validation TXT value in place** so re-cutover needs no re-validation. 6. **Decommission at T+30 days** — stop (don't delete) App Service `quidnepublic`, wait 7 more days, then remove its TXT marker, audit the three `ms-domain-verification` values before touching any, delete the App Service and plan, and retire the `.bat`/pkzip/`\\thorin` scripts.workstreams/quidne-public-website-refactor.tracker.md:603–607| P7.1 | Cutover step 1 — DEV at `dev.quidne.com` | 23 | 2026-09-22 · `Ready` on attempt 6; 200 + sentinel on DigiCert `CN=dev.quidne.com` to 2027-03-22; `Invoke-VerifySite -Environment DEV -Hostname dev.quidne.com -RequireResumePage` returns **0 on all 39** | | D4 | Pin line endings so one commit deploys one content hash | 23 | 2026-09-22 · `.gitattributes` (`* text=auto eol=lf`) · found via check 3 failing 25 of 102 files; local `src/` hash back to `043c1f36…`, matching the deployed tree · see the chunk 23 standing fact | | P7.2 | Cutover step 2 — UAT at `uat.quidne.com` | 25 | 2026-09-23 · run 831 (`20260923.1`) · approval 29 approved 13:32:53Z, `Verifying UAT at https://uat.quidne.com/` → all 39 checks passed | | P7.3 | Cutover step 3 — PROD provisioned, no DNS | 26 | 2026-09-23 · run 832 (`20260923.2`) · blocked 14:12:21Z→14:26:38Z on approval 30, verified all 39 against `lemon-sand-082e0321e.1.azurestaticapps.net`; zone hash `9dc070f4…` identical either side | | P7.4 | Cutover step 4 — `www` first, 48 h soak | 27 | 2026-09-25 · `C:\AI.IO\QuidnePublicWebsite\soak\www-soak.csv` · 76 rows 2026-09-23T15:08Z→2026-09-25T14:40Z, 75 OK, 1 RED (observer offline — see the chunk 27 standing fact); one body hash throughout; re-asserted at close: `www` 200 + sentinel, `http://quidne.com/` 200 from `104.42.231.5` |workstreams/quidne-public-website-refactor.tracker.md:607| P7.4 | Cutover step 4 — `www` first, 48 h soak | 27 | 2026-09-25 · `C:\AI.IO\QuidnePublicWebsite\soak\www-soak.csv` · 76 rows 2026-09-23T15:08Z→2026-09-25T14:40Z, 75 OK, 1 RED (observer offline — see the chunk 27 standing fact); one body hash throughout; re-asserted at close: `www` 200 + sentinel, `http://quidne.com/` 200 from `104.42.231.5` |workstreams/quidne-public-website-refactor.tracker.md:410–422**Status:** Done · Chunk 28 — apex serving the new site since 2026-09-25 ~20:40Z Per the Phase 5 sequence, **in a low-traffic window**. On rollback, restore `A @ 104.42.231.5` but **leave the SWA validation TXT value in place** so re-cutover needs no re-validation. **Acceptance criteria** - [x] Cut over in the chunk 28 session itself — window decided 2026-09-25: now, ~20:15Z - [x] Snapshot exported before the change — `C:\AI.IO\QuidnePublicWebsite\dns-snapshot\quidne.com-20260925-202513.json`, 18 record sets - [x] Apex bound per P5.3 and reaching `Ready` — registered 20:27:18Z, `Ready` on attempt 10 - [x] `https://quidne.com/` serves the new site; `Invoke-VerifySite -Environment PROD -Hostname quidne.com -RequireResumePage` returns **0 on all 39** against the deployed tree (D5 stashed for the run) - [x] Mail unaffected — MX and TXT re-read from `ns1-03`: identical but for the appended token (`C:\AI.IO\QuidnePublicWebsite\dns-snapshot\mail-{before,after}-apex-20260925.txt`)workstreams/quidne-public-website-refactor.tracker.md:479| **The alias write makes the apex 404 until `Ready`** | The parent's order puts the alias before the wait, so `http://quidne.com/` answered SWA's 404 for ~13 min (registered 20:27:18Z, `Ready` on attempt 10 of 40). `Validating` with `errorMessage: null` throughout — slow, not failing. A re-cutover should expect the same gap, or try the alias after `Ready` and record whether validation still completes |workstreams/quidne-public-website-refactor.tracker.md:457–463### P7.6. Cutover step 6 — decommission at T+30 **Status:** Not started · Chunk 29 **Stop, do not delete.** Stop App Service `quidnepublic`, wait 7 more days, then remove its TXT marker, **audit the three `ms-domain-verification` values before touching any**, delete the App Service and plan, and retire the `.bat`/pkzip/`\\thorin` scripts.
Is anything about the live site going to expire soon?
25 tool calls
- Bash
$ ls; ls deploy deploy/modules workstreams 2>/dev/null | head -60 - Grep
“(?i)expir|renew|notAfter|certificate|domain registration” (!src/{img,work}/**) - Grep
“(?i)expir|renew|notAfter|certificate|cert\b|days” in deploy - Grep
“(?i)expir|renew|notAfter|certificate” in workstreams - Read
deploy/modules/verify-site.ps1 · lines 222–279 - Read
workstreams/quidne-public-website-refactor.md · lines 320–339 - Bash
$ echo | openssl s_client -connect quidne.com:443 -servername quidne.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName - Bash
$ for h in www.quidne.com api.quidne.com; do echo "== $h"; echo | openssl s_client -connect $h:443 -servername $h 2>/dev/null | openssl x509 -noout -subject -issuer -dates 2>&1 | head -5; done - Grep
“(?i)expir|renew|notAfter|days remaining” in workstreams/quidne-public-website-refactor.tracker.md - Bash
$ grep -n -o -i -E '.{0,160}(expir|renew).{0,160}' workstreams/quidne-public-website-refactor.tracker.md | head -10 - Grep
“(?i)(expir|renew|certificate)” in workstreams/quidne-public-website-refactor.tracker.md - Bash
$ grep -n -o -i -E '.{0,200}certificate.{0,200}' workstreams/quidne-public-website-refactor.tracker.md | cut -c1-450 | head -6 - Grep
“(?i)decommission|soak|T\+30|2026-1[0-2]-” in workstreams (*.tracker.md) - Bash
$ grep -n -o -i -E '.{0,140}(decommission|T\+30).{0,160}' workstreams/quidne-public-website-refactor.tracker.md | cut -c1-320 | head -12 - Read
workstreams/quidne-public-website-refactor.tracker.md · lines 440–474 - Bash
$ grep -n -i -E 'state of play|T\+0|cutover (date|on|at)|cut over' workstreams/quidne-public-website-refactor.tracker.md | cut -c1-260 | head -12 - Read
workstreams/quidne-public-website-refactor.tracker.md · lines 20–41 - Read
workstreams/quidne-public-website-refactor.tracker.md · lines 410–419 - Grep
“(?i)client.?secret|workload identity|federat|sas token|api.?key” in workstreams - Bash
$ whois quidne.com 2>/dev/null | grep -i -E 'expir|registrar:|updated' | head -6 - Bash
$ grep -n -o -i -E '.{0,120}(client.?secret|workload identity|federat|sas token|api.?key).{0,140}' workstreams/quidne-public-website-refactor.tracker.md workstreams/quidne-contact-form-function.md | cut -c1-330 | head -8 - Bash
$ curl -s https://rdap.verisign.com/com/v1/domain/quidne.com | grep -o -E '"eventAction":"[a-z ]+","eventDate":"[^"]+"' | head -5 - Grep
“(?i)auto-?renew|registration (expir|renew)|registrar.{0,40}(renew|expir)|2026-11-09|domain renew” (!src/{img,work}/**) - Grep
“(?i)registrar” in workstreams/quidne-public-website-refactor.md - Grep
“(?i)^\s*schedules:|cron:” in pipelines
The domain registration is the one thing close to expiring. Public registry data (RDAP from Verisign) shows quidne.com was first registered in 1999 and expires on 2026-11-09 at 21:29 UTC, 32 days from today. Nothing in the repository tracks this. A search for auto-renew, registration expiry or that date found nothing. The plans only mention the registrar to say its nameservers should point at the Azure DNS zone workstreams/quidne-public-website-refactor.md:161. I could not see whether auto-renew is on at the registrar, and that is the first thing to check. If the domain lapses, the site, the www, dev, uat and api subdomains, and any mail on the domain all stop working together.
The TLS certificates are not a near-term concern. I connected to the live site and found DigiCert/GeoTrust certificates valid until 2027-03-25 for quidne.com (about 168 days left), 2027-03-23 for www.quidne.com and 2027-03-30 for api.quidne.com. They were all issued in late September, which fits Azure's automatically managed certificates. The repository's verification script fails a run when 14 days or fewer remain, to catch a renewal that has stalled deploy/modules/verify-site.ps1:254–256. However, I found no scheduled trigger in the pipelines folder, so that check only runs when someone deploys. It is not a standing monitor, and it does not look at the domain registration at all.
There is also a dated deadline coming up, though nothing expires with it. The apex moved to the new hosting on 2026-09-25 workstreams/quidne-public-website-refactor.tracker.md:410. The plan's last step is to stop the old App Service at 30 days after that cutover, then remove its DNS verification record and delete it 7 days later workstreams/quidne-public-website-refactor.tracker.md:457–466. By my arithmetic that means stopping it around 2026-10-25 and deleting it around 2026-11-01, and the step is still marked not started. The same tracker's summary says no chunk is calendar-gated any more and nothing waits on a clock workstreams/quidne-public-website-refactor.tracker.md:33–35. That contradicts the plan, so these dates could easily be missed.
Some things I could not verify. I did not check the registrar's auto-renew setting or the payment method on file. I did not check the expiry of the dev and uat certificates live; the tracker records dev's as valid to 2027-03-22. I did not check whether the old App Service is still running. The Azure DevOps service connections use workload identity federation, which normally has no secret that expires, but I did not confirm that in Azure.
5 cited sources
workstreams/quidne-public-website-refactor.md:1615. Repoint the registrar's nameservers to `az network dns zone show --query nameServers`.deploy/modules/verify-site.ps1:254–256# A stalled managed renewal shows up here long before it shows up as an outage. $results.Add((New-SiteCheckResult -Check 'TLS' -Name "more than $MinimumDaysRemaining days remaining" ` -Passed ($daysRemaining -gt $MinimumDaysRemaining) -Detail "$daysRemaining days"))workstreams/quidne-public-website-refactor.tracker.md:410**Status:** Done · Chunk 28 — apex serving the new site since 2026-09-25 ~20:40Zworkstreams/quidne-public-website-refactor.tracker.md:457–466### P7.6. Cutover step 6 — decommission at T+30 **Status:** Not started · Chunk 29 **Stop, do not delete.** Stop App Service `quidnepublic`, wait 7 more days, then remove its TXT marker, **audit the three `ms-domain-verification` values before touching any**, delete the App Service and plan, and retire the `.bat`/pkzip/`\\thorin` scripts. **Acceptance criteria** - [ ] `quidnepublic` stopped at T+30 with the date recorded; site still serving from the SWAworkstreams/quidne-public-website-refactor.tracker.md:33–35**No chunk is calendar-gated any more.** Chunk 8 was the last one — it wanted 7 days of verified mail flow after chunk 5, and it closed 2026-09-22 on the developer's attestation rather than on that evidence. Nothing in this tracker now waits on a clock.
Replay. Three Claude Code sessions on claude-opus-5-5, recorded on 8 October 2026 against this site's repository at d829b56. Tool calls, results and answers are as recorded; long tool output is trimmed and pauses over 0.9 seconds are shortened.
A question about a real repository
The agent starts where a new engineer would: it lists the repository's files, reads the pipeline, then reads the verifiers that fail a run. Each look is a tool call you can open, with the output it got back.
It says what the record says
Asked how the move happened without downtime, the agent finds that it did not quite: the record shows the bare domain returned 404 for about 13 minutes. It reports that rather than the answer the question invited.
Repository first, then the live site
For expiry, the agent finds the verifier's 14-day certificate rule, then reads the certificates quidne.com is serving. It also looks up the domain's registration date in public registry data, which nothing in the repository tracks, and says what it could not check from outside the registrar.
Every claim has a line number
Each citation names a file and a range of lines the agent actually read. Open one to see the quoted lines. A test fails the build if a quote stops matching the file it names.
Your turn
Pick a question and press Replay. The replay keeps the order and rough pace of the recorded session; long pauses are shortened.
What it shows
An AI agent answering questions about a real system from the system's own files, with its working in view. You see each search, each file it read and each command it ran, then an answer whose every claim points at the lines behind it. Where the record contradicts the question, the answer says so.
This page replays recorded sessions; it does not call a model. The interface reads from one source of events, so the same page can be pointed at a live agent behind your own sign-in.
What you get
- An artefact: an agent over your repositories, runbooks and tickets, with a short list of tools you choose: search, read, and named read-only checks.
- A proof: every answer cites file and line, and a test fails the build when a cited line stops saying what was quoted.
- A number: 16 citations across these three answers, each compared with its file on every build.
After we leave, your team owns the tool list and the instructions. Adding a tool is a code change with a test, and every session can be exported and replayed the way this page replays these.
How it is built
Each question was put to its own Claude Code session on 1 October 2026, told to stay read-only, cite only lines it had read, and answer in under 200 words. Nothing else was scripted. tools/record-chat.py turns the session transcripts into this page's data: tool calls, trimmed results, the answer and each citation with the lines it quotes. It refuses to write the file if anything in it looks like a credential.
The browser plays that data through a ChatSource interface: a replay source today, with a live source for a same-origin chat endpoint written against the same events. With scripts off, all three answers and their sources are plain HTML.