[sgardoll]

Supersedes #101 on the current head

Re-port of PR #101 (sgardoll/gate-deploy-truthfulness) onto the moved milestone head, because a parallel Devin branch landed on the milestone and changed the same region. The old branch is untouched; this is a fresh branch carrying only the deploy-truthfulness findings that are still missing.

Dropped finding (D1 / overlay hide-timer): Dr's cancelCommitProgressHide() already implements the deploy-progress overlay hide-timer fix on this head, so it is not re-added here.

Ported findings:

1. 5xx → UNCONFIRMED — deployOutcomeOfStreamResult (src/provisionStream.js) now maps only 4xx → FAILED; a 5xx stays UNCONFIRMED because a gateway can answer 502/503/504 after forwarding the request to the runner.
2. explainedByVerified ledger — resolveProjectPubspec (app.js) marks a sighting explained by a verified write as spent evidence, so repeated exports of unchanged content can no longer retire an uncertain write.
3. Truthful "runner returned HTTP " message — provisionMissingCodeFiles names the received HTTP status in its UNCONFIRMED throw instead of claiming the connection dropped.

Full CI passes on this head.

[greptile-apps]

This PR does not match any of the 1 configured review trigger rule.

[devin-ai-integration]

Devin Review found 2 potential issues.

[devin-ai-integration]

🔴 Repeated exports clear pending class writes

With two uncertain writes of identical content, resolveProjectPubspec retires one on each unchanged export. The second write can land later, after its dirty entry has cleared and the stale snapshot was cached.

Learn more

The dirty ledger tracks uncertain provisioning attempts by file path and content. An export showing that content establishes at most one observable transition; repeated exports of the same snapshot do not establish that another pending attempt wrote it. The explainedByVerified flag only spends sightings attributed to verified writes. When no verified credit exists, repeated sightings can each decrement uncertain, emptying the ledger and enabling caching while a runner can still write.

Example: Two requests for class X time out. The first writes X; two consecutive exports both show X. Both uncertain credits disappear, and an export is cached. The second request then writes X over a newer edit, while the cache still describes the earlier project state.

Recommended fix: Track the last observed content or distinct landing evidence per path, including sightings consumed by uncertain writes. Never retire another uncertain credit on an unchanged export; preserve uncertainty where identical writes cannot be distinguished.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 Returned class content keeps exports uncached

After a verified X sighting, explainedByVerified stays true when an export shows another version. If a pending write then restores X, its new sighting cannot retire the dirty entry, so every deploy re-exports.

Learn more

The project source cache is bypassed while any class write has an outstanding dirty entry. A verified write of X sets explainedByVerified on the X record, but observations of any other content do not reset it. If another edit replaces X with Y and the pending X write later restores X, the ledger rejects that distinct X sighting. It can remain dirty for the rest of the session, forcing a complete project export on each deploy.

Example: A timed-out provision of X is followed by a confirmed retry of X. An export sees X and consumes the confirmed credit. A later sync changes the class to Y, then the original provision writes X. Exports now show X again, but the pending X credit never clears.

Recommended fix: Track the last observed content per path and allow a new transition back to X to supply fresh evidence. Do not reset the evidence solely because time passes or the same snapshot is exported again.

---

Was this helpful? React with 👍 or 👎 to provide feedback.