Living Report

Practical engineering · Original scripted fixtures · Product experiments not performed

How to use and check Living Report

Living Report is an engineering publication maintained by Oleg Siutkin. Its goal is to help you choose a next step, inspect its basis and understand uncertainty. Reader demand and usefulness have not yet been validated by a participant study.

Three useful starting points

Choose a tool for a concrete task and its actual requirements. Compare the same product surface, plan and environment. A CLI, IDE extension and hosted agent can have different capabilities even when their product name is shared.

Improve a workflow by checking the result against an independently specified contract. Start with the bounded bugfix walkthrough, then test the tests and inspect a parallel-task conflict.

Understand a change by asking what changed, which tool/version or task is affected, what action is appropriate and what evidence supports that action. An updated page or a successful fetch alone does not establish new research.

What the current report can and cannot establish

The legacy comparison is being migrated to scoped capability assertions and a shared requirements model. Existing coverage percentages describe recorded feature statuses. They are not measured task quality, safety or productivity. Old descriptive cells, uncertainty and differing product surfaces make a general ranking especially unreliable. Treat current comparisons as research leads; inspect exact documentation and test the relevant task before relying on advice.

A linked source does not automatically support every sentence around it. Some legacy publication fragments remain unbound or require semantic review. A current review schedule means only that the recorded deadline has not passed. It does not mean every claim was independently observed or the whole edition rechecked.

Distinguish documented availability, observed behavior in a recorded environment, attributed vendor results and editorial judgment. Primary documentation can establish a documented feature; a vendor performance statement remains attributed. A security advisory applies to its named version range and environment. A fix for one advisory never proves general product safety.

A practical acceptance runbook

  1. Write a bounded task with allowed files, constraints and a stop condition.
  2. Record the actual product, surface, version, model, plan and environment.
  3. Capture the baseline commit and reproduce the problem before changing it.
  4. Define expected behavior independently of the implementation.
  5. Inspect the candidate diff and run checks that could reject an incorrect patch.
  6. Record changed tests, failures, manual interventions and unplanned edits.
  7. Keep process success, passing tests and human patch acceptance as separate outcomes.
  8. Preserve a recovery point. Merge, spending and production changes need their own authority.

The three walkthroughs use original disposable fixtures. Their repairs and parallel workers are scripted, not observations of coding products. They show specific acceptance and recovery checks; they do not constitute a benchmark. Actual coding-product trials and reader follow-up remain not performed.

Download and reproduce the demonstrations

Save run_demos.py and contracts.json into the same new directory. Python 3.11+ and Git are required. The scripts use no model/API or network service. Choose a new output directory for each invocation.

python3 run_demos.py tests --output /tmp/lr-tests-example
python3 run_demos.py brownfield --output /tmp/lr-bugfix-example
python3 run_demos.py parallel --output /tmp/lr-parallel-example

The output includes baseline identities, actual diffs and structured results. Commit IDs and measured wall-clock intervals vary by run. Read the limitations in each walkthrough before interpreting a passing check.

Dates, uncertainty and corrections

Substantive fact verification, successful source access, technical rendering, review-deadline evaluation and exact deployment are different events. An unavailable date stays unavailable. A no-op render cannot renew evidence. Static pages age; recheck a material requirement against current primary evidence before acting.

Mandatory unknown or stale evidence should produce insufficient evidence, not a forced winner. A known incompatibility excludes a candidate for that requirement. Preferences only help choose among candidates whose mandatory conditions pass. Free client licensing, subscription allowance and inference/provider payments are separate questions. These are the intended decision rules; full integration into the legacy chooser is still pending.

For a correction, identify the public section, exact wording, relevant product scope and a supporting source. Oleg Siutkin is the editor-maintainer. Editorial review should retain the old wording, explanation, evidence and decision rather than silently rewriting history. No claim of a staffed response service or measured weekly maintenance capacity is made.