Determinism Tier 1 follow-up: markdown audit reports embed a wall-clock timestamp
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 48/100
調査の方向性
Start in packages/darnit/src/darnit/tools/audit.py at format_results_markdown, which currently writes a wall-clock Generated At stamp. Compare the now_provider kwarg on RemediationExecutor (feature 036) and the scrub() helper plus docstring in tests/darnit/fixtures/error_class_baseline/capture_baseline.py. Decide drop vs opt-in vs injectable clock for the stamp, and whether pass_history[].duration_ms is omitted or documented as non-reproducible. Done when two identical-commit markdown reports match byte-for-byte without scrubbing those fields.
索引モデルが issue の本文から書いたものです。
説明
Follow-up to #418 (Determinism Tier 1), which this gap escaped.
Summary
format_results_markdown in
packages/darnit/src/darnit/tools/audit.py embeds a wall-clock stamp
in every report:
**Generated At:** 2026-09-08T15:47:47.180106Z
Consequence: a markdown audit report can never be byte-for-byte
reproducible, even for an identical commit with an identical verdict
set. Two runs one second apart produce different bytes.
A second, smaller instance: pass_history[].duration_ms is
load-dependent. It reads 0 for fast file-existence checks in practice,
but nothing guarantees that.
How it surfaced
Feature 036's SC-002 required capturing a pre-feature output baseline
and diffing post-feature output against it byte-for-byte. Two
consecutive captures of the same commit did not match. Both fields had
to be scrubbed for the baseline to be stable at all -- see the scrub()
helper in tests/darnit/fixtures/error_class_baseline/capture_baseline.py
and its docstring, which documents both as out of scope for 036 and
points here.
#418's survey covered filesystem iteration order, wall-clock injection
into remediation templates, list ordering, and non-atomic writes. It
did not look at the report formatter, which is why this was missed.
Why it matters
Same argument #418 makes: a compliance tool whose report output drifts
run-to-run undermines the "same commit -> same result" premise that
makes an audit trustworthy. Concretely it also:
- Blocks any golden-file regression test of markdown output. Any future
feature wanting to prove "my change is output-neutral" has to
reinvent the same scrubbing. - Makes report diffs noisy in review when an operator commits reports
to a repo (some fleet operators do).
Scope
Decide between:
- Drop the field. Simplest. The information is recoverable from
the attestation timestamp or the file mtime for anyone who needs it. - Make it opt-in via a formatter argument, default off.
- Make it injectable -- feature 036 already established this
pattern for exactly this problem:RemediationExecutorgained a
now_providerkwarg (defaulting todatetime.now) so tests can
pin a fixed clock. Applying the same shape to
format_results_markdownkeeps production behavior while making
the output testable.
Recommend (3) for consistency with the precedent, or (1) if nobody is
actually consuming the field.
Also decide whether duration_ms should be omitted from serialized
pass_history (it is diagnostic, not evidence) or kept and documented
as non-reproducible.
Non-goals
- Re-auditing the other formatters. JSON and SARIF do not embed
timestamps at the per-result level; the attestation predicate has its
own timestamp, which is legitimate and should stay. - Any change to what the audit concludes. This is purely about output
byte-stability.
Constitution alignment
- II. Conservative-by-Default: reproducible reports are a
precondition for the report being usable as evidence.
Related
- #418 (Determinism Tier 1) -- parent; closed by #424 before this gap
was found. - #419 / #420 / #421 -- the rest of the determinism set.
- Feature 036 (#435) -- surfaced this, and established the
now_providerinjection pattern option (3) would reuse.
- 主要言語
- Python
- スター
- 22
- フォーク
- 27
- 平均マージ
- 1日 20時間
- マージ済み PR（30日）
- 39
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
darnitdevorg/darnit のほかの issue
-
`darnit validate` crashes on openssf-baseline.toml summarising levels対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンneeds triage
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
darnitdevorg/darnit#589 ·
メンテナーはふだん 1 日以内に返信
-
needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
darnitdevorg/darnit#587 ·
メンテナーはふだん 1 日以内に返信
-
needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
darnitdevorg/darnit#585 ·
メンテナーはふだん 1 日以内に返信
-
quality
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
darnitdevorg/darnit#523 ·
メンテナーはふだん 1 日以内に返信
-
documentation good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
darnitdevorg/darnit#516 ·
メンテナーはふだん 1 日以内に返信
darnitdevorg/darnit の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
onyx-dot-app/onyx#16016 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
black --check exits 0 and prints All done when a multi file run is interrupted対応中かも @jiteshgulati が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 2 日以内に返信
-
Non-positive worker counts wait for results without starting workers対応中かも @IlyaKhalafi が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信