DEV Community: RELAUNCH DEPT.

Your AI agent said "done." What would prove it?

RELAUNCH DEPT. — Sat, 08 Aug 2026 06:32:56 +0000

AI-assisted disclosure: I used AI tools to help edit this article and the
open-source project it describes. The architecture, tests, deployment evidence,
and claim boundaries were reviewed against the public repository and live
service before publication.

I created this piece of content for the purposes of entering the All Things
Agentic Hackathon.

An autonomous agent can produce a confident status update long before the work
is actually complete. A deployment command can exit successfully while the
public endpoint still fails. A marketplace can display an opportunity that the
authoritative issue has already closed. A generated report can look finished
while one required source is stale.

The problem is not that language models cannot reason. The problem is that
“done” is a state transition, and state transitions need evidence.

I built Proofline to test a
simple pattern: let the model interpret the task, but make a deterministic gate
decide whether the evidence is sufficient.

Separate interpretation from acceptance

Proofline divides the workflow into two layers.

The agent layer uses Gemini 3.6 Flash and Google Agent Development Kit to:

interpret the task contract;
identify the requirements that need proof;
explain missing or contradictory evidence;
call a narrowly scoped evaluation tool.

The verification layer then applies explicit rules. It does not ask the model
whether the task feels complete. It evaluates structured evidence and returns
one of four states:

NEEDS_EVIDENCE — at least one requirement lacks fresh authoritative proof;
CONFLICT — authoritative sources contradict one another;
APPROVAL_REQUIRED — the evidence is complete, but the next action has an external side effect;
READY — every requirement is satisfied and no approval gate remains.

That split matters. The model remains useful where language and context are
messy, while the acceptance boundary stays inspectable and testable.

Make evidence a first-class object

Each evidence item carries more than a sentence saying something worked. It
records the requirement it supports, its source, whether that source is
authoritative, when it was observed, and the value that was actually returned.

A deployment claim, for example, should not be supported by “the command
succeeded.” Better evidence is an external HTTP response from the deployed URL,
the active revision identifier, and a timestamp inside the allowed freshness
window.

The same rule applies outside infrastructure. If a payment platform reports a
test balance, it cannot prove live revenue. If a bounty marketplace says an
issue is open but the repository says it is closed, the authoritative issue
wins and the conflict should stop the workflow.

Hash the decision packet

Once the gate evaluates the evidence, Proofline serializes the result in a
canonical order and computes a SHA-256 packet hash. The hash does not make a
weak claim true. It makes the exact decision inputs and output tamper-evident.

This is useful when an agent runs asynchronously. A reviewer can verify that
the packet being approved is the same packet the gate evaluated. If any
requirement, evidence item, timestamp, or decision changes, the hash changes.

Keep external actions behind a human boundary

Evidence can prove that a form is complete; it cannot decide whether a person
wants to submit a legally binding entry, publish a message, or spend money.
Proofline therefore treats those actions as a separate approval state.

This prevents a common automation mistake: combining technical readiness with
permission to act. The agent can prepare everything and prove that preparation,
but the final side effect remains explicit.

Prove the architecture with a live path

The public demonstration runs as a Google ADK application on Cloud Run. An
external request can discover the proofline app, create a real ADK session,
invoke Gemini, and call the deterministic evaluation tool. The repository also
contains a credential-free test path so the safety boundary can be inspected
without cloud access.

The deployed demo currently uses in-memory state. Firestore and Pub/Sub are
documented extension points for durable packets and asynchronous rechecks; they
are not presented as active components. That distinction is intentional:
architecture diagrams should separate what is live from what is planned.

A practical checklist

Before allowing an agent to declare a real task complete, ask:

What exact requirement is being satisfied?
Which source is authoritative for that requirement?
Is the observation fresh enough for the decision?
What happens when two authoritative sources disagree?
Can the decision be reproduced from structured inputs?
Does the next step create an external side effect?
Can a reviewer distinguish deployed components from planned ones?

If those questions do not have explicit answers, the agent probably has a
status message, not proof.

You can inspect the implementation, tests, architecture, and deployment
evidence in the public Proofline repository,
watch the 2:53 live demonstration, or verify the
Cloud Run application discovery endpoint.

If you want an external evidence audit for a launch or automation, RELAUNCH DEPT. offers a USD 59 evidence audit and a USD 249 implementation sprint. These are operational services, not legal, tax, or financial advice.

The JSON Error That Hid the Real Failure

RELAUNCH DEPT. — Sat, 08 Aug 2026 03:38:57 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

A migration audit should fail loudly when data is lost. Mine failed loudly too—but, in one edge case, it reported the wrong failure.

The bug lived in a one-command Python showcase built for an open-source Memanto contribution. The command turns a real GitHub discussion into an Open Knowledge Format bundle, runs Memanto's official migration dry run, round-trips the records through production mapping code, and writes a JSON fidelity receipt.

The happy path was straightforward. The uncomfortable path was not.

The pipeline and its two kinds of failure

The final audit is a subprocess. It can return a non-zero exit status for two very different reasons:

it completed the comparison and found lost or changed records, while still emitting a valid JSON receipt; or
it crashed before it could emit valid JSON.

The first case is expected domain behavior. We want to preserve its receipt and then propagate the non-zero status. The second is an operational failure. We want the original CalledProcessError, including its exit code, because that is the evidence that tells a developer what actually went wrong.

The original control flow captured the subprocess error, but then parsed its output before re-raising it:

try:
    audit_stdout = _run(audit_command, capture=True).stdout
except subprocess.CalledProcessError as error:
    audit_error = error
    audit_stdout = error.stdout or ""

report = json.loads(audit_stdout)
report_path.write_text(json.dumps(report))

if audit_error is not None:
    raise audit_error

That looked reasonable until the audit process failed without producing JSON. json.loads() then raised JSONDecodeError first. The original subprocess exception—and its meaningful return code—never reached the caller.

The parser had become an error-mask.

Reproducing the hidden branch

The useful breakthrough was to stop thinking of the output as simply “valid” or “invalid” and model two independent signals:

Did the process succeed?
Is its output valid JSON?

That creates four cases:

Process result	Output	Correct behavior
success	valid JSON	write receipt and continue
failure	valid JSON	write receipt, then re-raise the process error
failure	invalid JSON	re-raise the process error; do not create a receipt
success	invalid JSON	surface `JSONDecodeError` because the producer broke its contract

The masked failure was the third row. A regression test simulated an audit that exited with status 7 and printed plain text instead of JSON:

def fake_run(command, *, capture=False):
    if capture:
        raise run_demo.subprocess.CalledProcessError(
            7,
            command,
            output="audit crashed before producing JSON",
        )
    return run_demo.subprocess.CompletedProcess(command, 0)

The test asserts two things that matter operationally:

try:
    run_demo.run_showcase("acme/repo", 7, workdir)
except run_demo.subprocess.CalledProcessError as error:
    assert error.returncode == 7
else:
    raise AssertionError("Invalid audit output masked the process failure")

assert not (workdir / "audit.json").exists()

It does not merely expect “an exception.” It verifies that the right exception and exact status code survive, and that invalid output is not blessed as an audit artifact.

The fix: preserve causal priority

The correction keeps valid failing receipts, but gives the original process failure priority when JSON parsing also fails:

try:
    report = json.loads(audit_stdout)
except json.JSONDecodeError:
    if audit_error is not None:
        raise audit_error from None
    raise

report_path.write_text(
    json.dumps(report, indent=2, ensure_ascii=False) + "\n",
    encoding="utf-8",
)

if audit_error is not None:
    raise audit_error

The from None is deliberate. In the simultaneous-failure branch, the JSON error is a side effect of missing output, not the root cause. Suppressing that context keeps the traceback focused on the subprocess failure the operator needs to investigate.

At the same time, a valid JSON report from a fidelity failure is still written before the original non-zero result is propagated. That report is valuable evidence; throwing it away would create a different debugging problem.

What changed after the fix

The branch now has explicit regression coverage for both failure modes:

a failed audit with valid JSON preserves the receipt and exit status;
a failed audit with invalid output preserves the original exit status and writes no receipt.

The focused suite reports 25 passing tests, with Ruff checks, formatting, and mypy also clean on the contribution branch. The wider migration demo has additionally completed a 32-record real-data round trip with zero removed or changed portable fields. Those broader results are useful, but the most important outcome of this debugging story is smaller: when the pipeline fails, its diagnostic contract is now trustworthy.

Three lessons I am keeping

1. Error handling needs its own truth table

Nested fallible operations create combinations that a linear happy-path reading hides. A small matrix exposed the missing branch faster than another end-to-end run would have.

2. Test identity, not just category

“An exception was raised” would have passed before and after the fix. Checking returncode == 7 proves that causality survived.

3. Artifacts are part of failure semantics

A diagnostic file should exist only when it is valid. The absence assertion prevents future code from leaving behind a misleading audit.json after a producer crash.

Evidence

The larger PR introduces an OKF portability workflow; this Smash Stories entry is specifically about the real exception-masking bug caught and fixed during its review. The PR is open and mergeable at the time of writing; no merge or bounty award is assumed.

AI assistance disclosure: AI tools assisted with code review and drafting. The behavior, fix, tests, and validation claims above are linked to reproducible repository evidence.

Five Mobile Landing-Page Bugs That Hide in Desktop Review

RELAUNCH DEPT. — Sat, 08 Aug 2026 03:28:24 +0000

A practical pre-launch QA pass for 320 px, 375 px and 414 px screens.

A landing page can look polished on a laptop and still lose customers on a phone. The problem is rarely one dramatic failure. It is usually five small defects that make the first action harder than it should be.

1. Horizontal overflow that only appears at one width

Test at 320 px, 375 px and 414 px. Look for clipped copy, carousels wider than the viewport, fixed-width tables and decorative elements that push the page sideways. Record the exact viewport and attach a screenshot; “mobile is broken” is not an actionable bug report.

2. A primary CTA that disappears below the fold

The visitor should understand the offer and see the primary action without hunting. Check whether a tall hero image, consent banner or oversized navigation moves the CTA below the first useful screen. The fix is often hierarchy, not more copy.

3. Touch targets that work with a mouse but not a thumb

Buttons and links need enough space to tap reliably. Use 44 × 44 px as a practical minimum, then check the distance between adjacent controls. Tiny close icons, crowded navigation and text-only links are common failure points.

4. Forms that ignore the mobile keyboard

Verify labels, focus order, error messages, autofill and the keyboard type for email, phone and numeric fields. A form can technically submit and still create enough friction to lose the conversion.

5. Images that steal the performance budget

Inspect oversized hero images, off-screen media loaded too early and layout shifts caused by missing dimensions. The goal is not a perfect laboratory score; it is a stable first interaction on a real connection.

A useful QA report should make every finding reproducible: viewport, steps, expected behaviour, actual behaviour, screenshot and priority. That format gives a designer or developer something they can fix immediately.

I have packaged this process into a fixed-scope Mobile Landing Page QA Audit: one live page, annotated screenshots, a prioritized fix list and one retest, delivered within five business days for $59.

AI-assisted tools may support analysis; every published finding is reviewed before delivery.

Originally published by RELAUNCH DEPT. on Medium.