I had an idea, more of a stress-test really.
I have been building my IDE for a few months now, it's actually getting to a pretty solid state, but ...
For further actions, you may consider blocking this person and/or reporting abuse
[feature] I have a structural edge-case challenge for your agent team.
Add a deterministic “Verification Receipt” widget to article pages for returning readers. Its job is to determine whether the current article state still matches the state the reader previously observed.
1. State Contract
The receipt must produce exactly one of three states:
VERIFIED— explicit hash/revision evidence shows that the content and defined core metadata are identical.CHANGED— explicit evidence shows that the content or defined core metadata has diverged.UNKNOWN— the underlying sensor/source is unavailable, stale, blocked, inconsistent, or otherwise unable to establish either result.Invariant:
UNKNOWNis a first-class state and must never fail-open or be coerced intoVERIFIED. A timeout, 404, missing storage value, malformed response, or unavailable sensor must produceUNKNOWN, not a default-green result.2. Baseline and Evaluation
Baseline creation/update must be a separate operation from evaluation.
The evaluation itself must be read-only: it must not modify, replace, or refresh the saved baseline while performing the comparison.
A first visit with no baseline therefore returns
UNKNOWNrather than silently creating a baseline and reportingVERIFIED.3. Edge Cases
A metadata-only change must count as
CHANGED. For example, a title, tag set, or author change with identical body text must not produceVERIFIED.The receipt should also define its source of truth explicitly: what exact representation is compared (for example, the canonical article payload or another stable revision representation), rather than relying on a UI timestamp alone.
4. Inspectability
Clicking “Why?” should open an audit drawer showing:
body_hash, revision,updated_at,tag_set, etc.);Live,Timeout,Unavailable,Conflicting, etc.);5. Mandatory Tests
CHANGEDCHANGEDVERIFIEDUNKNOWNUNKNOWNUNKNOWNUNKNOWNUNKNOWN, while the previous baseline remains unchangedContext: this comes directly from a failure mode I’ve been investigating in autonomous coding systems: a correct rule executing over a dead or degraded sensor can produce a perfectly green result.
I’m interested in whether your triage team can implement “I don't know” as a valid, inspectable outcome, rather than treating it as an exception to swallow.
Interesting one, that's definitely 1 of those cases where the intricacy is filling the narrower cracks, rather than fill a canvas. I think that's a pretty solid 1 to run, though I doubt the PR'll go live... Counta think of it, I'll look into potentially hosting a forem live (the active codebase), it'll need 1 regardless to actually test it live, but that way once you get your feature request added, you can review the outcome on the demo site? Though I'll need to look where I still have credits, think i still have some on Azure.
Exactly. The widget is just the substrate.
What I’m actually probing is whether your triage team can return
UNKNOWNwhen its sensor is dead or the evidence is insufficient. That’s the failure mode I’ve been studying and experimenting with over the last few weeks.So the merge is secondary for me; the real deliverable is the behaviour and the test suite. It either passes or fails on the dead-endpoint, no-baseline, and conflicting-revision cases.
That’s the result I’d be most interested in seeing in your follow-up post.
Will definitely be interesting!
Me! Still confused, but I am interested (in Dwarven Stronghold).
Basically, put my money where my mouth is. When I do it, write a comment about something you want or want fixed in dev.to and my IDE will implement it. I'll review it (for research purposes and QC) and then create the PR to forem for it. Simple. Eg. @francistrdev I imagine you'd like a gif search, so you dont have to google them?
Aaaah! I know exactly what I want!
dev.to/effessdev/comment/3f65m
A progress bar! Is this how I am supposed to post the comment?
[feature] add a minimal progress bar at the top of the post page to know how much of the post we have read (progress excludes the comment section)
If I got what you are doing correctly, this is a wonderful idea!
Sounds solid, that's exactly how it should be formatted too! That way it'll know how to tag the PR properly when it eventually makes it to forem.
A gif search is useful, but I rarely use the integrated search. I tend to search in Google so that I get a good variety of images to use from. More creativity on my end because you will never know what GIF/Images I use for my article. One day is Anime and the other is just something else.
The architecture/QA split is probably the part that gets more important as agents improve. Writing the code is becoming cheaper, but deciding whether the change actually belongs in the system is still a separate job.
This is a really interesting experiment. I like that you're measuring the actual cost, success rate, and review process instead of treating AI coding as a black box. The follow-up stats should be especially interesting.