decision: dev-build oracle coverage (ADR 0022 addendum)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- 機能追加
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- typescript
- 領域
- build-system
調査の方向性
Start by reading build-train.ts around line 296 and ADR 0022, then survey oracle usage across bos build, bos deploy, and regression stacks. Compare hashing cost with rebuild cost and assess the false-fresh risk for targets. Done means recording the decision and rationale in an ADR 0022 addendum, with a follow-up ticket if implementation is warranted.
索引モデルが issue の本文から書いたものです。
説明
Decision to make
The content-hash staleness oracle (#430) is deploy-only — build-train.ts:296 passes it only when input.deploy. Non-deploy bos build prerequisites use the mtime oracle, and target builds themselves always run unconditionally — only prerequisites get a freshness judgement at all.
Decide (and record as an ADR 0022 addendum):
- Should the content-hash oracle extend to non-deploy builds? (Dev builds pay a full tree hash per run today; the mtime oracle misses content edits with fresh mtimes, e.g. checkouts.)
- Should target builds be skip-if-fresh? (Currently a
bos build uialways rebuildsuieven when nothing in its closure changed.) A--frozen-style flag or config default could opt into skip-if-fresh targets. - If always-build-targets stays policy, say so explicitly and note why (e.g. bundlers' own caches make target rebuilds cheap, and false-fresh targets are worse than false-stale prerequisites).
Scope: research + decision + ADR addendum only — no code. The implementation becomes a follow-up ticket once the decision lands.
Blocked by
Nothing — independent.
Status
- Survey current oracle usage across
bos build/bos deploy/ regression stacks - Trade-offs written up (cost of hashing vs rebuild; false-fresh risk for targets)
- ADR 0022 addendum recorded with the decision
- Follow-up ticket created if implementation is warranted
- 主要言語
- TypeScript
- スター
- 5
- フォーク
- 3
- 平均マージ
- 11時間 8分
- マージ済み PR（30日）
- 90
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
NEARBuilders/everything-dev のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
NEARBuilders/everything-dev#400 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 55/100
NEARBuilders/everything-dev#507 ·
メンテナーはふだん 1 日以内に返信
-
bug needs-triage
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
NEARBuilders/everything-dev#496 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
NEARBuilders/everything-dev#493 ·
メンテナーはふだん 1 日以内に返信
-
ready-for-human
難易度 5/5 1週間以上 初心者へのやさしさ 15/100
NEARBuilders/everything-dev#491 ·
メンテナーはふだん 1 日以内に返信
NEARBuilders/everything-dev の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
diegosouzapw/OmniRoute#17386 ·
メンテナーはふだん 1 日以内に返信
-
ready-for-agent
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
メンテナーはふだん 1 日以内に返信
-
area/dashboard kind/bug kind/bug-qa QA/dev-automation
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
vybestack/llxprt-code#3917 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
api-parity
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
IBM/carbon-components-ember#1157 ·
メンテナーはふだん 1 日以内に返信