scaffold: ルート境界をまたぐ import を root alias に統一する

[mk3008]

背景

現在のディレクトリ整理では、src/features、src/libraries、src/adapters、tests/support などを canonical root として扱っている。

一方で、scaffold されるコードや template には、たとえば以下のような深い相対 import が残っている。

import type { SqlClient } from '../../libraries/sql/sql-client.js';

この形は、ルート境界をまたぐ参照であるにもかかわらず、ディレクトリの深さに依存しており、今回整理した taxonomy の意図と少しズレている。

問題

• ルート境界をまたぐ import がディレクトリ深さに依存してしまう
• canonical root に分けた意味が、参照記述上は薄れてしまう
• #features や #tests だけ alias 的に見え、libraries / adapters だけが相対参照のままなのは非対称な
• dogfooding 時に「どの境界をまたいでいるのか」が見えづらい
• 将来的な移動や再編時に、相対パスの修正コストが増える

提案

ルート境界をまたぐ import は、相対パスではなく root alias で統一したい。

たとえば以下のような方針を取りたい。

• #features/*
• #libraries/*
• #adapters/*
• #tests/*

同一 boundary 内や同一ルート内のローカルな参照までは一律に禁止しない。
ただし、canonical root をまたぐ参照については alias を既定としたい。

期待する効果

• import を見ただけで、どの root boundary を参照しているか分かりやすくなる
• ディレクトリ深さへの依存が減り、移動や再編に強くなる
• starter / smoke / feature scaffold の dogfooding 時の認知負荷が下がる
• 今回の taxonomy の意図が、コード上の記述にも反映される

Acceptance Criteria

• generated project の tsconfig.json / package.json などで、root alias が定義されている
• scaffold/template で、ルート境界をまたぐ import に深い相対パスを使わない
• starter / smoke / feature scaffold を含む generated-project verification が通る
• README か architecture guide に、root boundary をまたぐ import は alias を使う 方針が明記される
• 既存の #features / #tests との整合が取れている

Non-goals

• すべての相対 import を全面禁止することではない
• repo 全体の既存コードを今回一気に全置換することは必須ではない
• boundary.ts を増やすこと自体は目的ではない