traceability showで、選んだ1要素の内容を読めるようにするAccepted(2026-10-05決定)。
GUIは、要求を根にした1本の木と、選んだ要素の詳細ペインで表示を構成する。木は軽いtraceabilityで作る。詳細ペインには、選んだ要素の内容を出す。
traceabilityの各Nodeは、識別子とlabelしか持たない。軸・説明文・procedures・Scenarioのphases・生成されたTestCaseの手順は、どの読み取り出力にも含まれない。一方、設計書§11は、viewがKnowledgeや.markharness/を直接読まず、CLIの出力だけを入力とすると定めている。そのためGUIは、詳細ペインの内容を取る手段を持たない(Issue #95)。
設計書§12は、TestCaseの詳細表示専用モデルを「viewで具体的な必要性が確認されてから追加する」ものとし、「生成ファイルを直接読めば当面は代替できる」と書いていた。詳細ペインという具体的な必要が出たので、この記述を見直す必要がある。また、直接読む代替案は、view側が.markharness/を直接読まないという境界と矛盾する。
traceability showを追加するmarkharness traceability show --uid <UID> [--at <git-ref>] [-d, --dir <path>]
選んだ1要素の内容を、標準出力へJSONで1件だけ返す。traceabilityは軽いままにし、内容は詳細だけが持つ。--atの意味はtraceabilityと同じで、省略時は作業ツリー、指定時はそのGit refを読む(0033)。木と詳細で読む時点がずれると、GUIの表示が食い違うためである。
traceabilityに引数なしで--atなどを渡す従来の使い方は変えない。showはそのサブコマンドとして置く。
| 要素 | 項目 |
|---|---|
| Requirement | requirement_id、axis、description |
| Feature | feature_id、axis、description |
| Behavior | behavior_id、axis、description、procedures |
| Scenario | scenario_id、description、phases(各stepsのactionとuse、results)、implementation_note |
| TestCase | case_id、case_revision、phases(use:を展開した、実際に実行される手順) |
全要素にschema_version・record_kind・at・kind・uidを付ける。
kindはrequirement・feature・behavior・scenario・test_caseのいずれか。呼び出し側はuidだけで引けるので、要素の種類を事前に知らなくてよい。record_kindは1つ(traceability_detail)にする。種類ごとの項目の違いは、JSON SchemaのoneOfで表す。nullにせずキーごと省略する。traceabilityのlabelの扱いと、設計書§11の「未知の任意フィールドを追加しても読める」方針に揃える。source: externalのRequirementはdescriptionを出さない。外部文書が内容を持つためで、labelを出さないのと同じ理由である(0023)。phasesは、Knowledgeに書かれたまま返し、useは展開しない。TestCaseのphasesは展開した結果を返す。前者は編集の現在値、後者は「実際に実行される内容」の確認用で、目的が違うため形も分ける。case_uidで引き、現在の版を返すTestCaseのuidは、traceabilityのtest_cases[].case_uidである。case_revisionは指定させない。GUIが木に使った--atと同じ値を渡せば、木と一致する版が返る。
uidは失敗にする--uidが、その時点のどの要素にも一致しない場合は、終了コード2で終了し、標準出力には何も出さない。エラー文には、uidと読んだ時点(working-treeまたはGit ref)を含める。GUIは、失敗したら木を再取得すればよい。
schema_versionは1とする0039に従い、0.xの間は上げない。
次の項目は、表示に使わないので、いまは含めない。編集の範囲が決まってから、必要なら別に決める。
source_revision・related_issuesforked_from設計書§12の「TestCaseの詳細表示専用モデル」は、この決定で追加済みの扱いにする。
.markharness/を直接読まない境界を保つなら、内容はCLIから出すしかない。use:の展開結果は生成ロジックの出力である。GUIが自前で再現すると、生成ロジックと食い違いうる。traceabilityに--detailのような引数を足し、全件の内容を一括で出す。 木が重くなり、「木は軽く、詳細は1件ぶんだけ」という前提と食い違う。採用しない。record_kindを分ける(5種類)。 呼び出し側が事前に要素の種類を知っている必要があり、uidだけでは引けない。採用しない。case_uidとcase_revisionの両方で指定させる。 GUIが木と同じ--atを渡せば版は一致するので、版の指定は要らない(YAGNI)。採用しない。traceabilityの一部だけ崩れ、use:の展開の再現も要る。採用しない。uidを、found: falseを持つ正常なJSONで返す。 成功と失敗の区別が出力の中に移り、呼び出し側が毎回その項目を見る必要がある。impact・coverageの失敗の扱いとも揃わない。採用しない。docs/*/design/cli-read-model-design.mdに§5.5を追加し、§9・§12・§14.1を更新する。CLIマニュアルにも追加する。schema/traceability-detail-read-model.schema.json)と、種類ごとのfixture(tests/fixtures/read-models/traceability_detail/v1/)を追加する。knowledge reconcileとIntentの形式は変えない。詳細の出力は、GUIが編集Intentを作るときの現在値を渡すだけである。