knowledge intent-from-strictdocAccepted(2026-09-29決定、実装済み)。
0023はsource: externalのRequirementを定義し、0030は外部側の識別子source_key(StrictDocのMIDを推奨)を追加した。しかし、既存のStrictDocプロジェクトの要求をこれらのRequirementとして登録する手段はCLIに無く、knowledge reconcileのIntentを要求1件ずつ人手で書くしかない(issue #88。実プロジェクトでは358件)。importの入力はnative・junitのみで、knowledgeには書き込まず、常にCanonicalSnapshotを出力する。
strictdoc export --formats=jsonは、プロジェクト全体をout/json/index.jsonの1ファイルに出力する(strictdoc 0.30.1で確認)。DOCUMENTS[]の下にSECTIONと要求がNODESで入れ子になり、要求ノードは_NODE_TYPE: "REQUIREMENT"とMIDを持つ。次の点が設計に効く。
.sdocとMarkdown形式(.md、.markdown)の両方をドキュメントの第一級の形式とする。Markdown形式にはドキュメント単位のMIDが存在しない(MIDは要求などのノードごとにだけ書ける)。JSON上もドキュメントのMIDは無い。.sdocのドキュメントがENABLE_MID: Trueのときだけである。後者でソースにMIDが書かれていない場合、exportの実行ごとに別のMIDが生成される。spec/の2つのMarkdownドキュメントが51要求を持つ。また、tests/配下にフィクスチャとしてMIDを含むMarkdownが複製されている。knowledge intent-from-strictdocはIntent YAMLをstdoutに出力するだけで、何も書き込まないmarkharness knowledge intent-from-strictdoc --input out/json/index.json \
[--sdoc-root <dir>]... [-d <dir>] | markharness knowledge reconcile -
knowledgeへの書き込みは既存のknowledge reconcileに任せる。これによりatomicな書き込み・--check・id基準の冪等性が再実装なしで得られる。importは「常にCanonicalSnapshotを出力する」性質を保つため、import --source strictdocにはしない。
markharnessはstrictdocを実行せず、要求の本文もパースしない(設計書P5: Coreは外部形式を知らない)。利用者がstrictdoc exportを実行し、出力ファイルを--inputで渡す。
DOCUMENTS[].NODESを再帰的にたどり、_NODE_TYPE == "REQUIREMENT"のノードだけを対象とする(SECTIONは入れ子をたどるだけ。カスタムgrammarの型は対象外)。各要求から次のRequirementを生成する。
| フィールド | 値 |
|---|---|
id |
sd-<MID全体>(MIDは小文字hexで、有効なslug) |
source |
external |
source_key |
MID(0030の推奨どおり) |
source_locator |
§4 |
source_revision |
current |
axis |
[] |
MIDは小文字hexで1桁以上でなければならない(桁数は検証しない)。Intentは文字列整形で組み立てるため、これ以外の値はid(slug)にもYAMLにも到達させない。
source_locatorは要求MIDの索引で決めるJSONにソースファイルのパスが無く、Markdown形式にはドキュメントMIDも無いため、要求自身のMIDから所属ファイルを引く。--sdoc-root(複数回指定可。省略時はプロジェクトルート)以下の*.sdoc・*.md・*.markdownを走査し、MIDを宣言する行を索引にする。
.sdocは行頭のMID: <値>。**MID**: <値>(行末の \は許す)。[REQUIREMENT]ブロックをテキストノード内のコード例として引用しているため。.sdocの複数行文字列(FIELD: >>>から<<<まで。インデントされず、要求ブロックの引用が行頭に来る)と、Markdownのコードフェンス(3つ以上のバッククォートまたはチルダで囲まれた領域。閉じられなければファイル末尾まで)である。要求のMIDに一致する行がちょうど1ファイルにあれば、そのパスをsource_locatorとする。パスはプロジェクトルート基準の相対パスで、区切りは/(knowledge reconcileがgit hash-objectをプロジェクトルートで実行するのと同じ基準)。--sdoc-rootはプロジェクトルート配下でなければならない。
この走査はStrictDocを解釈しない。要求の構文やノード構造は読まず、MIDを宣言する行と、上記のリテラル領域の境界だけを判定する。
次のいずれかがあれば、診断を出力して非0で終了し、Intentは何も出力しない。
--sdoc-rootでの絞り込みを案内する)。--sdoc-rootがプロジェクトルートの外にある。ENABLE_MID: TrueだけでMIDがexportのたびに生成される状態では、id・source_keyが実行ごとに変わり、再実行のたびに別のRequirementが作られる。索引に一致する行が無いため、この状態は§5の「どのファイルにも宣言されていない」で検出される。--sdoc-rootでドキュメントのディレクトリだけを指定する(StrictDocのinclude_doc_pathsに相当)。source_revision: currentの解決に必要な、ソースファイルのコミット(未コミットならknowledge reconcileが失敗する。ADR 0029)。idは入力のMIDだけから決まり、実行順序や件数に依存しない。src/knowledge_strictdoc.rs(新規): JSON+MID索引→Intentの変換。src/cli.rs: KnowledgeCommand::IntentFromStrictdoc。tests/knowledge_intent_from_strictdoc_cli.rs(新規)。source_locatorをStrictDocソースファイル(.sdoc/.md/.markdown)へ一般化し、validate・reconcile・traceabilityの該当メッセージを合わせる。import --source strictdoc: importの出力(CanonicalSnapshot)と--bind・--formatの意味が崩れるため不採用。knowledge配下で直接書き込む専用コマンド: knowledge reconcileの書き込み経路と重複するため不採用。strictdocをサブプロセスとして実行する: 外部ツール実行と環境差(Windows等)を持ち込むため不採用。.sdoc/Markdownパーサ: MIDを宣言する行以外は不要なため不採用。.sdocヘッダの照合: 当初案。Markdown形式にドキュメントMIDが無く、Markdownドキュメントを扱えないため不採用。TITLE照合・全件同一--source-locator・利用者による対応表: TITLEは重複しやすく、複数ファイルのプロジェクトでは不正確になる(0023の変更検出はソースファイル単位のblob差分)ため不採用。--excludeによる除外指定: 想定外の複製を拾わない安全側として、走査範囲を明示する--sdoc-root(複数指定可)を採る。source_keyによる重複検出・更新・削除検出: 0030 §3のスコープ外を維持する(YAGNI)。idがMIDから決定的なので、id基準の冪等性で再実行は成立する。intent --source <name>のような汎用化: 入力形式が1つのうちは不要(設計書§9.2)。2つ目の形式が来た時点で改名を検討する。