HISTORICAL DIG · JUL—AUG 2026
The AI says it is done. How do I verify that before delivery?
An AI completion note is only a cue to look. Before handoff, open the file, test, or target page and confirm that the result happened—and that it is the version being handed over.
WORKFLOW 001 · NODE POSITION
Current node 047 nodes total
Check the result, not the claim
HOW IT RELATES TO WORKFLOW 001
Relation to the current subject
It is not a fourth question. It is the handoff threshold shared by all three.
Where a tool runs, which extensions it adds, and whether the right project state can be recovered days later all end at the same action: open the result and compare it with the original requirement. Workflow 001 uses this threshold for task completion; Q01 applies it to the target environment, Q02 to whether an extension changes an observable result, and Q03 to whether the restored state is the right one.
Record state at the time
- Work and handoff
- Checkable work results
- In-depth guide
- Developing
- Historical E2 · one community report + two method references · no cross-task run
THE GUIDANCE AT THE TIME
Judgment at the time
Open the version being handed over before deciding that the work is done.
Open full rationale and return rules
Pick the single completion claim that matters most to the handoff. Check it against the source file, test, or target page: did it happen, is this the current version, and can you go back if it is wrong? If any part remains unseen, leave it unconfirmed.
- Who it was for
- People using AI to change documents, web pages, or code before handing the result to a colleague, client, or real environment
- Why it mattered then
Open note
The real risk is not an imperfect summary. It is treating a candidate result as a finished handoff, then sending, publishing, paying, or merging.
- Where the judgment stops
Open note
This historical Dig has method references and one closed community report, but no BitShovel cross-task run or independent-user reproduction. It does not establish that every AI run fails, or that DevHub or any other tool works.
CHECK BEFORE READING ON
Fit check
First make sure there is a deliverable you can open yourself.
This record may help
- You already have a file, page, code change, or target state that is about to be handed over.
- You can open the original request, current result, and any necessary test or target page in a read-only way first.
Do not use it yet when
- There is no concrete deliverable yet and the work is still exploratory; define the result before applying a handoff check.
- The check would require an unauthorized real account, sensitive data, or an irreversible action.
- You need BitShovel to establish the general reliability of a model, Open Code Review, or DevHub—this record contains no such evidence.
EARLIER CHECKING METHOD · NOT A BITSHOVEL TEST
Historical trial
Unrun, unfrozen guidance: check the one completion claim that matters most to the handoff.
- Time needed
- 10–20 minutes
- Likely cost
- Usually no additional cost
- Permission boundary
- Read-only first; do not send, publish, pay, delete, or merge before the check
- 01
First step
Open this step
Pick one delivery-critical claim and check it against the source file, test, or target page.
- 02
What should exist
Open this step
A short note stating the claim, what supports it, what is missing, and the next step.
- 03
If run, what counts as confirmation
Open this step
You can open the supporting material yourself and distinguish what is confirmed from what remains unknown.
- 04
Stop when
Open this step
The evidence would require a real account, sensitive data, or an irreversible action you are not authorized to take.
- 05
How to back out
Open this step
Keep the original file or branch; if the check fails, revert and return the unproven item to the queue.
MAKER DEMO · NOT A BITSHOVEL RUN
Method and interfaces
A terminal can locate a review comment; it cannot prove that the comment is right.
Open method boundary
This pinned Open Code Review terminal image only shows how review output is tied to a file and line range. It is not a BitShovel run, correctness proof, second-person review, or maker endorsement.
This pinned terminal region only shows that a review comment can be tied to a file and line range. It does not establish that the suggestion is correct, that BitShovel ran the tool, or that a second person accepted the result.
About this image and its source
Alibaba / Open Code Review contributors · Apache-2.0. BitShovel cropped the complete terminal panel from the pinned source and converted it to a metadata-free WebP without rewriting, hiding, rearranging, or translating terminal content. The project did not participate in, approve, or endorse BitShovel.
Open source page ↗Read use and attribution guidelines ↗SOURCES AND EVIDENCE
Sources and evidence
As of August 15, 2026, the record contains one closed community report and two method references—not a failure rate, cross-task run, or independent-user reproduction.
Open evidence boundary
A 2026-08-15 recheck found all three sources still available: one closed user report, Git's explanation of version history, and RTINGS' published test method. They help frame a precaution and a checking method; they provide neither a failure rate nor a BitShovel test result.
- 01Closed community report · Source rechecked
A Codex user reported claimed completion without execution
Open source boundary
The issue is now closed and describes the reporter's GPT-5.4 use at that time. It identifies a failure mode worth guarding against; it is not an OpenAI finding, an independent reproduction, or a general failure rate.
Open original source ↗ - 02Official method reference · Source rechecked
Git preserves comparable history through snapshots and commits
Open source boundary
GitHub's documentation supports the mechanism of reviewing, comparing, and recovering versions. Git does not make an AI result correct.
Open original source ↗ - 03Cross-domain method analogy · Source rechecked
RTINGS publishes standard tests, raw measurements, and retest methods
Open source boundary
This first-party explanation helps separate a maker claim, a test result, and a later revision. BitShovel has not reproduced the RTINGS method across AI tasks.
Open original source ↗
REVISION RECORD
Revision record
Keep R2 through R4: the narrower method and the visual correction remain part of the record.
Open 3 revisions
- Revision 2
Separated investigation progress from strength of evidence and based the judgment on what actually happened.
- Revision 3
Added an openable field note so readers could compare the result with the checking steps.
- Revision 4
Removed the marketing-led full-page Open Code Review image and kept the inspectable terminal-review region from the same pinned source.
- What the record said before
- Used the complete, marketing-led project page as the primary visual.
- What changed
- Kept only the complete terminal panel and labeled it as a maker demo—not a BitShovel run, correctness proof, or second-person review.
WHAT THIS RECORD LEAVES
What this record leaves
A completion note should trigger a check, not replace one.
The current Workflow judges a primary workflow through observable results, target environment, extension cost, and project state. This historical record keeps only the final handoff threshold shared by those decisions.
Back to the Dig index