2. Task

タスクレイヤー仕様書

本文書は Li+ プログラムのタスクレイヤー（Li+github.md）の仕様を定義する。 要求（何を満たすか）と仕様（どう振る舞うか）を一体として記述する。

---

作業の起点

すべての作業は issue から始める。issue 番号のない commit / PR は禁止する。関係のない issue を流用せず、必ず新規作成する。

issue 本文は「現在の要求スナップショット」として扱う。履歴ログではない。コメントは補助であり、現在地を理解するためにコメント列を読まなくてよい状態を保つ。

issue 作成時に3項目がすべて埋まっていることは要求しない。話題が永続化すべき作業単位になった時点で、AI が明示指示を待たずに issue を作成できる。人間が「issueから始めて」と起動句を言わなくても issue 化できる。

---

issue の記述

issue は未完成なメモから開始できる。3項目は収束先の最小構文であり、作成時の必須条件ではない。

実装対象として扱う段階では、本文を以下へ収束させる：

• 目的
• 前提
• 制約

issue の完了判断は本文項目ではなく、issue 状態と PR/CI/release flow で管理する。本文に専用の完了条件欄を持たない。

収束後も新しい受理情報が入れば issue 本文を再構築して更新する。issue は「生きた要求定義書」として扱う。

必要な見出しだけを使う。空セクションを強制しない。

---

ラベル定義

ラベルは AI の読みやすさとフィルタリングのためにある。作成時は必ず説明文を書く。

ライフサイクルラベル

「いつ着手するか」を表す。状態変化時に適用する。

ラベル	意味
in-progress	着手中、実装または検証が進行中
backlog	受け入れ済み、着手時期未定
deferred	今回対応しない。あとで見直す

成熟度ラベル

「どこまで収束したか」を表す。issue 本文の収束度に応じて更新する。作成時に付与する。

ラベル	意味
memo	メモとして開始した状態。見出しは必要なものだけでよい
forming	本文を再構築しながら要求を整えている状態
ready	本文が実装開始できる形まで収束している状態。ただし更新は継続可能

memo / forming のまま実装開始の根拠にしない。

タイプラベル

作成時に1つ以上付与する。

ラベル	意味
bug	動いていない、壊れている
enhancement	新機能・改善要望
spec	Li+ の挙動に影響する仕様・ポリシー・定義
docs	ドキュメント変更（挙動への影響なし）

ラベルは運用の中で進化する。詳細な運用ポリシーと廃止履歴はオペレーションレイヤーを参照。

---

親子 issue 構造

親 issue もメモから開始してよい。収束した親 issue は目的・前提・制約を中心にまとめる。

親 issue のクローズ条件は構造的に判断する：子 issue（deferred 扱いのものを除く）がすべてクローズされたらクローズする。

sub-issue

sub-issue は AI が追跡・実行できる作業単位として使う。sub-issue にはブランチを作らない。セッションブランチは親 issue にリンクする。複数の子 issue の作業を同じセッションブランチで進めてよい。

セッションブランチは branch 側の外部記憶であり、引き継ぎ面でもある。別の AI は親 issue とリンク済みブランチを読めば、以前の会話に依存せず途中から継続できる状態を目指す。

分割は責務で行う。粒度で分けない。同じ責務なら1つの issue にまとめる。複数ファイルにまたがっていても責務が同じなら1つでよい。

sub-issue API：

# issue の内部 ID を取得
gh api repos/{owner}/{repo}/issues/{number} --jq '.id'

# 親 issue に sub-issue を追加
gh api repos/{owner}/{repo}/issues/{parent}/sub_issues --method POST -f sub_issue_id={id}

同時タスクは親子 issue 構造を使う。複数タスクを同一セッションで並行進行する場合、issue を個別に作成するとブランチリンクが1件にしか張れない（プラットフォーム制約）。

チェックリスト

チェックリスト = 人間の判断が必要なもの（実機テスト、運用確認など）に限る。AI が判定できる作業単位には sub-issue を使う。

---

issue の自律管理

issue は AI の内部 TODO である。ユーザーからの指示を待たずに管理する。

作成タイミング： バグ発見時、仕様ギャップ発見時、大きな作業のタスク分割時、対話の中で永続化すべき作業メモが生まれた時。

更新タイミング： 受理された要求が変わった時、成熟度が変わった時、タスク分割が必要になった時。

クローズ条件： 実装完了・CI パス・リリース済み、またはユーザーが動作確認を報告した時。

open 保持： 運用テスト中の issue はクローズしない。

触らない： 永続参照系としてクローズ禁止が明記された issue。

情報不足時は必ず人間に確認する。

---

言語レイヤー分離

issue / commit / PR の形式に適用する。

• タイトル：ASCII 英語のみ（識別レイヤー）
• ボディ：日本語（意味レイヤー）+ issue 番号
• 日本語タイトル・英語のみボディを禁止する

---

進化

再構築・削除・最適化はすべて許容する。構造の一貫性のみ維持する。