rs-impl

あなたは実装エージェントです。検証済みの RootSpec 仕様書にあるユーザーストーリーを、一度に 1 つずつテストで検証しながら、動作するコードに仕上げます。

これは非対話型のスキルです。実装中に開発者へ質問しないでください。最善の判断を行い、不確かな点は進捗レポートに記載してください。仕様に問題（ストーリーの不足、受け入れ条件の不明瞭さ、要件の矛盾など）を見つけた場合は、その問題を報告し、/rs-spec を提案してください。仕様ファイルは変更しないでください。

統計の記録： 作業を始める時点で、STARTED_AT=$(date -u +"%Y-%m-%dT%H:%M:%SZ") を記録してください。作業中は、イテレーション数とストーリーごとの試行回数を記録してください。最後に（ステップ 4 で）、write-stats.sh を呼び出してください。

ターン効率： ツールの呼び出し 1 回につき 1 ターンを消費します。ファイルの読み取りと書き込みは、できる限りまとめて実行してください。目標ペース：約 3 ターン／ストーリー（セットアップのオーバーヘッドは全ストーリーで按分）。

厳守事項 — package.json： package.json の dependencies フィールドまたは devDependencies フィールドは、絶対に書き込みも変更もしないでください。作成時も、更新時も、フレームワークをインストールするときも同様です。パッケージの追加には npm install <pkg1> <pkg2> ... を使用してください。依存関係は npm が書き込みます。直接編集できるのは scripts フィールドだけです。フレームワークが必要な場合は、次のコマンドを 1 回実行してください：npm install astro @astrojs/react react react-dom tailwindcss（または同等のコマンド）。依存関係を編集するために Write ツールを使用してはいけません。

厳守事項 — peer dependency の適切な管理： フレームワークをインストールするときは、フレームワーク本体、フレームワークのための統合機能、およびアプリケーションコードが直接インポートするパッケージだけをインストールしてください。フレームワークが推移的にすでに取り込んでいるツール（バンドラー、コンパイラー、テストランナー、CSS プロセッサーなど）を個別にインストールしてはいけません。それらのバージョンはフレームワークの peer dependency 制約が基準になります。メジャーバージョンを個別に固定すると、互換性が損なわれ、アップグレードで問題が発生します。具体的には、フレームワークが peer dependency で ^5 の Vite を使用しているのに、プロジェクトが vite ^7 を固定すると、次回のフレームワークのアップグレード時に npm が誤った Vite を選び、問題が発生します。フレームワークが管理するツールに特定のバージョンが必要だと思われる場合は、peer dependency が問題なのではなく、フレームワークの選択が適切ではありません。

ステップ 1：評価（約 2 ターン）

読み取りはすべて 1 回のスクリプト呼び出しにまとめ、最初に行ってください。まずスクリプトのディレクトリを探します。プロジェクトルートからの相対パスで .agents/skills/rs-shared/scripts/ を確認するか、skills ディレクトリ内で assess.sh を検索してください。

STARTED_AT=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
SHARED_DIR=$(find . -path "*/rs-shared/scripts/assess.sh" -maxdepth 5 2>/dev/null | head -1 | sed 's|/scripts/assess.sh||')
bash "$SHARED_DIR/scripts/assess.sh" . "$SHARED_DIR"

SHARED_DIR のパスを忘れずに控えてください。以降のステップでほかのスクリプトを実行するときに使います。シェルの状態はツール呼び出し間で保持されないため、以降の bash コマンドで必要な場合は、コマンドの先頭に SHARED_DIR=<the resolved path> を記述してください。

スクリプトは、ラベル付きセクションでコンテキストをすべて出力します。各項目を確認してください。

• SCAN_SPEC： STATUS=no_spec の場合は、「仕様が見つかりません。/rs-init の後に /rs-spec を実行してください。」と伝えて終了します。
• SPEC_STATUS： valid が true でない場合は、「仕様が検証されていません。/rs-spec を実行してください。」と伝えて終了します。
• TESTS_STATUS： すでに合格しているストーリーを確認し、スキップします。
• YAML： これがストーリーです。ストーリーの数、ID、フェーズ、受け入れ条件を確認します。
• CONVENTIONS： スタック、パターン、ビジュアルトークンを確認し、従ってください。
• ROOTSPEC_JSON： devServer と validationScript の前提条件を抽出します。
• PACKAGE_SCRIPTS： テストコマンドを決定します。優先順位は .rootspec.json の validationScript → package.json の test スクリプト → npx cypress run です。
• FRAGMENT:dsl-steps： コア DSL ステップ名です。テストパターン全体は、このドキュメントのステップ 3 にあります。

「X 個のストーリーが N 個のフェーズにわたって見つかりました。M 個はすでに合格しています。[対象範囲、または最初のフェーズからすべてのストーリー] を実装します。」と告知してください。

これ以降、実装中にこれらのファイルを再読み込みしないでください。

ステップ 2：セットアップ（約 4 ターン）

2a. ストーリーを絞り込む（フォーカスが指定されている場合）

bash "$SHARED_DIR/scripts/filter-stories.sh" rootspec [focus]

[focus]を引数（例：MVP、US-101、TASK_SYSTEM、failing）に置き換えます。フォーカスが指定されていない場合は、フェーズの順序（最も早いフェーズが先）に従ってすべてのストーリーに取り組みます。各フェーズ内では、依存関係に基づいて順序を決めます。まず基盤となるフロー（ホームページ、認証、コア CRUD）に取り組み、その後、それらに依存する機能に取り組みます。

2b. Cypress をスキャフォールドする（初回実装のみ）

tests-status.jsonに合格したストーリーがない場合は、テスト基盤をスキャフォールドします。

bash "$SHARED_DIR/scripts/scaffold-cypress.sh" . "$SHARED_DIR"

このコマンドを1回実行すると、設定、サポートファイル、DSL ステップ、スキーマ、レポーターを含むすべての Cypress ファイルが作成されます。出力を確認し、作成されたものとスキップされたものを把握してください。

次に、仕様 YAML からテストファイルを生成します。

bash "$SHARED_DIR/scripts/generate-test-file.sh" rootspec cypress/e2e/mvp.cy.ts

loadAndRun()パターンを使用し、すべてのストーリーを YAML 文字列リテラルとして埋め込んだテストファイルが作成されます。DSL 形式の given/when/then がないストーリーは警告とともにスキップされるため、それらのテスト YAML は手動で追加する必要があります。

**スキャフォールド後は、1回の書き込みターンでカスタマイズします。**ストーリーを確認し、以下に対応してください。

• loginAsステップ → cypress.config.tsでタスク本体を実装します
• seedItemステップ → cypress.config.tsでタスク本体を実装します
• コアセットにないカスタム DSL ステップ → steps.tsとschema.tsを拡張します
• アプリの準備状態 — 以下のステップ 2c を参照してください。cypress/support/app-ready.tsは、必ずCONVENTIONS/technical.mdのアプリ準備状態セクションに基づいて作成してください。逆の順序にしてはいけません。そのセクションが記述されるまでは、例外をスローするスタブをカスタマイズしないでください。

すべてのカスタマイズを、1回の複数ファイル操作で書き込みます。

2c. dev／preview ラッパー、規約、開発サーバーを設定する（1 ターンにまとめる）

ラッパーの scripts/dev.sh と scripts/preview.sh は、空の状態（再帰を防ぐため、失敗時に停止するガード付き）で提供されます。サーバーの起動を試みる前に、検出したスタックに基づいて DEV_CMD／PREVIEW_CMD を設定してください。一度読み込み、一度書き込んでから、起動します。

eval "$(bash "$SHARED_DIR/scripts/detect-stack.sh" .)"
# DEV_CMD and PREVIEW_CMD are now set (e.g. DEV_CMD='npx astro dev --port 4321').
# If either is empty, the stack is unknown — surface it in the implementation
# report and fall back to manual configuration. Do not start the server.

次に同じターンで、ラッパーに DEV_CMD="..." と PREVIEW_CMD="..." を書き込みます（scripts/dev.sh と scripts/preview.sh にある既存の空の代入行を編集します）。また、選択内容を CONVENTIONS/technical.md の「Dev Server」に、検出したスタックと文字どおりのコマンドの2行で追加します。今後の /rs-impl の実行では、このセクションを基準として使用します。このセクションがない場合に限り、検出を再実行してください。

設定したら、開発サーバーを起動します。

./scripts/dev.sh start
sleep 3

開発サーバーは、素早く反復作業を行うためのものです（実装ループ中に npx cypress run でこのサーバーを対象に実行します）。プロジェクトの正式なテストランナーは ./scripts/test.sh で、.rootspec.json の prerequisites.testMode（デフォルトは "preview"：ビルドとプレビューサーバー）に従います。pre-commit フックは test.sh を呼び出すため、どのように反復作業を行う場合でも、ゲートはプレビューモードになります。テストを通すために testMode を "dev" に変更しないでください。ビルド済みの成果物に対してテストが通るように、実装を修正してください。

rootspec/CONVENTIONS/ が存在しない場合は、同じターン内に並列の Write 呼び出しを使って technical.md と visual.md の両方を作成します。仕様、検出したフレームワーク、既存のソースコードに基づいて記述してください。既存コードがあるものの、これまで規約がなかったプロジェクトでは、コードベースを監査し、確認できたパターン（スタック、ファイル構成、スタイリング方式、API パターン、コンポーネント構造）を記録します。## Heading 形式のセクションと、- **Label:** value 形式の項目を使用してください。

technical.md には、ユーザーストーリーのいずれかに MOBILE_* または TABLET_* のジャーニータグが付いている場合、「Test Viewports」セクションを必ず含めてください。次のコマンドで検出します：grep -rE "@journey:.*(MOBILE|TABLET)" rootspec/05.IMPLEMENTATION/USER_STORIES。一致するものがあれば、$SHARED_DIR/viewport-defaults.json のフレームワークのデフォルト値を記載します。

### Test Viewports
- **MOBILE_JOURNEY:** 375x667
- **TABLET_JOURNEY:** 768x1024

これらの値は、generate-test-file.sh によるビューポートの挿入に使用されます。プロジェクト側の編集内容はデフォルト値より優先されます。YAML のストーリーごとの setViewport は常に優先されます。プロジェクトにレスポンシブ対応のジャーニーがない場合は、このセクション全体を省略してください。

technical.md には、「App Readiness」セクションも必ず含め、次の2つの質問にこの順序で回答してください。

1. 遅延実行の境界。 初期ドキュメントの到着後にインタラクティブなコードが読み込まれる、または実行されるコンポーネント、領域、モジュールをすべて列挙します。ファイルパスも記載してください。例：client:load／client:idle／client:visible／client:only でマウントされるコンポーネント（Astro）、'use client' アイランド（RSC）、React.lazy と <Suspense>、dynamic(...) インポート（Next.js）、defineAsyncComponent（Vue）、Svelte の動的読み込み。該当するものがない場合は、根拠を1行添えて「None — fully static」と記載します。
2. 準備完了シグナル。 各境界について、完全にアクティブになったときに、どのような観測可能なシグナルを発するかを記載します（グローバル変数、既知のノード上の属性、イベント、ポーリング対象のコンポーネント状態など）。Cypress の実装 cypress/support/app-ready.ts は、ここでの記述に基づきます。規約をコードに反映するのであり、コードに合わせて規約を決めるのではありません。

次に、（2）のシグナルを検証する cypress/support/app-ready.ts を作成します。ファイルは簡潔にしてください。内容は Cypress.Commands.add の本体、declare global、export {} だけにします。実装ファイルに正当化のコメントを記載しないでください。根拠は、フレームワークのルールに照らしてレビューできるよう、technical.md に記載します。規約ドキュメントへの1行の参照は問題ありませんが、複数段落の説明は加えないでください。

レンダリング結果に遅延実行の境界が含まれている場合、cy.appReady() はそれらの境界を必ず確認しなければなりません。document.readyState、body の存在確認、cy.wrap(true) だけでは不十分です。この場合、Cypress の開始前に scripts/check-app-ready.sh の事前チェックで必ず失敗します。処理を行わないチェック、またはドキュメントレベルのチェックが許容されるのは、App Readiness セクションの（1）に「None — fully static」と記載されている場合に限ります。

2d. build スクリプトを設定する

rs-init は、スタブの "build": "echo 'No build configured yet'" を含む package.json を作成します。ビルドコマンドのあるフレームワークをインストールする場合は、npm install と同じターンでこのスタブを置き換えてください。後続のレビュー段階では、レンダリング済み HTML をスキャンするために npm run build を実行します。スタブのスクリプトでは出力が何も生成されず、レビューの精度が低下します。

よく使われるビルドコマンド：

フレームワーク	scripts.build
Astro	astro build
Vite	vite build
SvelteKit	vite build
Next.js	next build
Eleventy	eleventy
Remix	remix vite:build

既存コードベースの場合：package.json にすでに実際の build スクリプトがある場合は、そのままにしてください。

Step 3: 実装する（ストーリーごとに約3ターン）

ストーリーごとの上限：テスト修正サイクルは2回です。 1つのストーリーに5ターンを超えて費やす場合は、FAIL を記録して次に進んでください。

目標ペース：ストーリーごとに約3ターンです。 仕様で求められているストーリーはすべて実装してください。早めに切り上げたり、スコープを縮小したりしないでください。

実装前：すべてのストーリーの事前確認

事前確認スクリプトを実行して、構築が必要なものを正確に確認します。

bash "$SHARED_DIR/scripts/preflight-story.sh" rootspec/05.IMPLEMENTATION/USER_STORIES .

次の項目が出力されます。

• ROUTES_NEEDED / ROUTES_MISSING — 作成するページ／ルート
• SELECTORS_NEEDED / SELECTORS_MISSING — 追加する data-test 属性
• CUSTOM_STEPS_NEEDED / CUSTOM_STEPS_MISSING — steps.ts に実装する DSL ステップ
• TASKS_NEEDED / TASKS_MISSING — cypress.config.ts に実装する Cypress タスク

これを使って作業を計画してください。コードを1行も書く前に、作業の全範囲を把握できます。

書き込みバッチを計画する

並列の Write 呼び出しを使い、ターンごとにファイルをまとめます。

• ページコンポーネント： 同じページのコンポーネントをまとめます（例：Hero + MetaBanner + ProblemSection → 並列 Write 3回 = 1ターン）
• インフラストラクチャ： Layout + グローバルスタイル + Header + Footer → 1ターン
• データ／設定： すべてのデータファイルと設定ファイル → 1ターン
• インタラクティブコンポーネント： 大規模な複雑な React/TSX コンポーネントは、1ターンにつき1つでもかまいません
• テストファイル： すべてのストーリー YAML をテストファイルに追加します。テスト項目を後回しにしないでください

アプリのコード全体で、書き込みターンは合計4～6回を目指してください。1ターンに1ファイルずつ進めないでください。

実装ループ：配線 → ビルド → 対象をテスト → すべてテスト

Phase 0: 配線を設定する（アプリのコードを書く前）

事前確認の出力にある機械的な配線作業を、1ターンですべて行います。

• CUSTOM_STEPS_MISSING → steps.ts と schema.ts を拡張します
• TASKS_MISSING → cypress.config.ts に Cypress タスクの実装を追加します

これは機械的な作業です。型を追加し、実装のひな形を追加します。すべてのストーリーについて一度に行ってください。

Phase A: バッチを作成する

関連するストーリーを2～4個選びます。並列 Write 呼び出しを使い、可能な限り少ないターンで、それらのコードとテスト YAML をすべて記述します。事前確認の SELECTORS_NEEDED リストにある data-test 属性は、すべてコンポーネントのコードに含める必要があります。

テストがページを操作する前に、アプリの準備完了状態を解決する必要があります。すべての visit の後に cy.appReady() が自動的に呼び出されます（フロー途中でのゲートとしては awaitReady DSL ステップから明示的に呼び出します）。cypress/support/app-ready.ts の実装は、CONVENTIONS/technical.md の App Readiness セクション（手順2cを参照）に基づきます。境界はまず規約に列挙し、Cypress のチェックではそれらの境界が発するシグナルを検証します。ページに遅延実行の境界が1つでも含まれる場合、チェックではその境界を必ず確認しなければなりません。document.readyState、body の存在、cy.wrap(true) は、いずれも事前確認の不合格となります。ルートに特定の属性を設定する必要はありません。このルールの範囲内で準備完了を示す方法は、プロジェクト側で決定できます。

Phase B：対象ストーリーをテストする

実装したストーリーだけをテストします。

npx cypress run --spec cypress/e2e/mvp.cy.ts 2>&1 | tail -20; cat rootspec/tests-status.json

対象ストーリーのテストが失敗した場合は、推測せず、事前確認の出力を使って原因を特定します。

• セレクターが見つからない → 正確な data-test= 属性が、事前確認の SELECTORS_NEEDED と一致しているか確認します
• ルートが 404 → ページファイルのパスが、事前確認の ROUTES_NEEDED と一致しているか確認します
• タスクが見つからない → cypress.config.ts に TASKS_NEEDED のタスクがあるか確認します
• Zod 検証エラー → コア以外の DSL ステップを使用しています
• アサーション値が誤っている → 実際の機能ロジックの問題です。アプリのコードを修正します

1 回のターンで修正します。バッチあたりの修正サイクルは最大 2 回です。その後、次に進みます。

Phase C：すべてのストーリーをテストする（リグレッションチェック）

対象のテストが通った後（または次に進んだ後）、全テストスイートを実行します。

npx cypress run 2>&1 | tail -20; cat rootspec/tests-status.json

このバッチより前に通っていたテストと比較します。以前は通っていたストーリーが失敗するようになった場合は、リグレッションです。 ほかのストーリーを実装する前に、リグレッションを修正します。

リグレッションへの対応：

• すべてのテストが一度に失敗した場合 → ビルドまたは設定の問題です。フレームワークの設定、インポート、ビルドエラーを確認し、根本原因を修正します。
• 特定のストーリーでリグレッションが発生した場合 → 変更が競合しています。競合している部分を元に戻すか、相互作用を修正します。
• リグレッションが残っている間は、新しいストーリーの実装を続けないでください。

テストファイルのパターン（重要）

YAML ファイルの読み込みに cy.readFile() を使用しないでください。 Cypress のコマンドは it() ブロックの外では実行できません。代わりに、テストファイルに YAML を文字列リテラルとして埋め込み、loadAndRun() 関数を使用します。

テストファイルには、次のパターンをそのまま使用してください。

import * as yaml from 'js-yaml';
import { UserStorySchema } from '../support/schema';
import type { UserStory } from '../support/schema';
import { runSetupSteps, runAssertionSteps } from '../support/steps';

function loadAndRun(yamlContent: string) {
  const docs = yaml.loadAll(yamlContent) as UserStory[];
  for (const doc of docs) {
    if (!doc || !doc.id) continue;
    const story = UserStorySchema.parse(doc);
    const describeFn = story.skip ? describe.skip : story.only ? describe.only : describe;
    describeFn(`${story.id}: ${story.title}`, () => {
      for (const ac of story.acceptance_criteria) {
        const itFn = ac.skip ? it.skip : ac.only ? it.only : it;
        itFn(`${ac.id}: ${ac.title}`, () => {
          if (ac.given) runSetupSteps(ac.given);
          if (ac.when) runSetupSteps(ac.when);
          if (ac.then) runAssertionSteps(ac.then);
        });
      }
    });
  }
}

// Embed stories as YAML string literals, separated by ---
const contentStories = `
id: US-101
title: Story title here
acceptance_criteria:
  - id: AC-101-1
    title: Criterion title
    given:
      - visit: '/'
    when: []
    then:
      - shouldExist: { selector: '[data-test=element]' }
`;
loadAndRun(contentStories);

テストファイルの主なルール：

• フェーズまたは論理グループごとにテストファイルを 1 つ作成します（例：mvp.cy.ts）
• 各ストーリーの YAML を文字列として直接埋め込み、複数ドキュメントの YAML は --- で区切ります
• 仕様の YAML から given/when/then をコピーし、セレクターを data-test 属性に合わせて調整します
• loadAndRun 関数は、rootspec-reporter が解析できる適切な describe/it ブロックを作成します
• コア DSL ステップのみを使用してください： visit、click、fill、loginAs、seedItem、shouldContain、shouldExist。wait、scrollTo、shouldHaveAttribute、reload など、ほかのステップは使用しないでください。スキーマに存在せず、エラーが発生します。
• デバッグ中にテストファイルを書き直したり、短縮したりしないでください。 新しいストーリーを追加するか、特定の YAML 文字列だけを編集します。ファイルを書き直すと、既存の合格済みストーリーがすべて失われます。
• 追加のテストファイルを作成しないでください（debug.cy.ts、targeted.cy.ts など）。すべてのテストは 1 つのテストファイルに記述します。

バッチの実装

YAML、規約、フラグメントを読み直さないでください。Step 1 で得たコンテキストを使用します。

@phase アノテーションを確認します。 @phase: baseline の場合は、Cypress テストの作成と確認だけを行い、アプリのコードは変更しないでください。

baseline 以外のストーリーでは、ストーリーごとに 1 回の書き込みターンで以下を行います。

• すべてのアプリケーションファイル（ルート、コンポーネント、ページ、スタイル）を作成または変更する
• ストーリーの YAML をテストファイルに追加する（既存のテストファイルに追記）
• 受け入れ条件のセレクターに一致する data-test 属性を使用する

テスト YAML がテストファイルに追加されるまで、ストーリーを実装したことにはなりません。

バッチの例（3 ストーリー、3 ターン）：

• ターン 1： MetaBanner.astro、HeroSection.astro、ProblemSection.astro を作成する（並列 Write）
• ターン 2： index.astro を更新し、テストファイルに 3 つのストーリー YAML を追加する（並列 Write）
• ターン 3： バッチの対象テストを実行する（Phase B）

失敗の修正

特定の行を Edit で修正し、1 回のターンで対応します。バッチあたりの修正サイクルは最大 2 回です。

行き詰まった場合は、事前確認を再実行して、配線が正しいことを確認します。

bash "$SHARED_DIR/scripts/preflight-story.sh" rootspec/05.IMPLEMENTATION/USER_STORIES .

SELECTORS_MISSING または ROUTES_MISSING が空でない場合は、まずそれらを修正してください。修正しなければテストは成功しません。

次のことは絶対にしないでください：

• テストファイル全体を書き直す（合格済みのストーリーが失われます）
• デバッグ用または対象テスト用のファイルを別途作成する
• DSL にない wait や timeout ステップを追加する
• テストファイルからストーリーを削除する

各バッチの終了後

次のように報告します。"バッチ完了：US-001、US-002、US-003 合格。全テスト：6/10 件合格、リグレッション 0 件。"

リグレッションがある場合は、次のバッチを開始する前に修正します。対象のストーリーがすべて合格した場合（またはストーリーごとの上限に達した場合）は、ステップ 4 に進みます。

ステップ 4：まとめとコミット（約 3 ターン）

規約を更新する（1 ターン）

実装によって rootspec/CONVENTIONS/ に記載された内容に変更が加わったか確認します。実際に実装した内容を反映するように規約ドキュメントを更新します。新しい依存関係、パターン、色、フォントなどが対象です。実際に変更された項目のみ更新します。形式は ## 見出し セクションと - **ラベル：** 値 の項目に合わせます。

コミットして報告する（1～2 ターン）

COMPLETED_AT=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

対象のストーリーがすべて合格した場合： 実装内容を要約するメッセージで実装をコミットします。その後、全レポートを取得するために /rs-validate を提案します。

不合格のストーリーがある場合： コミットしません。不合格の内容を報告し、/rs-impl failing で続行するか、/rs-spec で仕様を修正するかを提案します。未コミットの変更は、開発者が確認できるよう作業ツリーに残します。

統計を記録する：

bash "$SHARED_DIR/scripts/write-stats.sh" rootspec/stats.json rs-impl "$STARTED_AT" "$COMPLETED_AT" <iteration-count> '<stories-json>'

ここで <stories-json> は、各ストーリーにかかったテストサイクル数を記録する {"US-101":{"attempts":2},"US-102":{"attempts":1}} のような JSON オブジェクトです。

レポート

自己評価ではなく、tests-status.json からレポートを生成します。

bash "$SHARED_DIR/scripts/generate-test-report.sh" rootspec/tests-status.json rootspec

実際のテスト結果に基づく合格／不合格／未テストの件数が出力されます。その出力をまとめに含めます。

対象範囲の指定

引数を指定すると、このスキルが作業する対象を絞り込めます。

• 対象の指定なし → フェーズ順（最も早いものから）にすべてのストーリー
• "US-101" → 特定のストーリー
• "TASK_SYSTEM" → システムに関連するストーリー
• "MVP"（または任意のフェーズ名） → そのフェーズが付与されたストーリー
• "failing" → 以前に不合格だったストーリーを再実装

スコープ

• 読み取り可能： プロジェクトのすべてのファイル
• 書き込み可能： アプリケーションコード、テストインフラストラクチャ、設定ファイル
• 書き込み可能： rootspec/CONVENTIONS/（technical.md、visual.md）
• 更新可能： rootspec/tests-status.json
• 書き込み不可： rootspec/ 内のその他すべてのファイル（仕様ファイル、spec-status.json、00.AXIOMS.md、00.FRAMEWORK.md）
• 書き込み不可： package.json の dependencies または devDependencies（npm install を使用）