Company — Concept・Entity

aachatのteamは、個々の仕事（project）の外側に、会社そのものの共有された文脈を持つ。2つの層がある。Conceptの内部モデル（kind・意味軸・revision・レビュー・リンク・類似ガード）は concept-registry が正本。Entityの内部モデルはこのページが正本。

層	内容	WebUIの場所	詳細
Concept	チームが合意したVision・Issue・Policy。全agentと人間が判断の前提として読む	teamサイドバー「Concepts」	concept-registry
Entity	会社を実際に構成する継続的な対象の地図。独立して構築・改善・維持・終了を判断できる粒度へ分解する	teamサイドバー「Entity」	このページ下記

どこで依頼するか

専用の場所は要らない。 どのprojectのsessionでも通常の依頼と同じようにagentへ頼めるほか、connected repoで動く外側agentにも頼める。session agentはsession authorityを使い、外側agentは同じ投影YAMLを読んで、sign-in中の人間のTeam roleでsubmitするaachat registryを使う。

読む: agentはpublish済みのConceptや現在のEntityを読み、判断の前提として使える
Conceptの提案: agentは新しいConceptや既存Conceptの改訂・リンクを**提案（propose）**として登録する。提案はpendingとして残り、人間がWebUIのConcepts画面でレビューして採否を決める。承認されて初めてチームの判断基準になる（詳細は concept-registry）
Entity: agentはEntity（通常kindのみ、下記参照）の登録・更新をsessionから直接行える。提案とレビューを経ずその場で反映される点がConceptと異なる

connected repoでは最初にaachat statusのTeam projectionがhealthyであることを確認し、2つのindex、必要な個別YAML、該当するMeeting本文を読む。YAMLの保存はlocal staged editにすぎず、aachat registry submitが明示的なmutation境界である。serverは人間WebUI操作と同じ認可を適用するため、Owner/Adminはsensitive Entity operationをsubmitでき、Memberは403を受け取る。

使い分け

目指す状態・継続的な問題・繰り返す判断方針を残したい → Concept提案
会社を実際に構成する対象と、改善の焦点を明確にしたい → Entity

会社の文脈はagentの仕事の入力であり出力でもある。projectで働いたagentが発見をConcept提案として返し、人間が承認すると、次のすべてのsessionがその判断基準の上で働く。これが会社そのものが資産として育つ流れである（concepts のcompany assetsの流れの会社版）。

Entityモデル — kind・sensitive境界・階層

Entityは、会社を実際に構成する、識別可能で継続的な対象の地図（Company map）を構成する。何を作り、何を改善し、何を維持または終了するかを具体的にし、改善対象を独立して選べる粒度へ分解する。

Entityにはproperty・評価・目標・KPI・担当者・進捗を保存しない。それらはConcept（判断基準）・Project/Session（実行中の仕事）・Message/Shared Document（根拠や詳細）が持つ。

Entity化の基準

Entityには、単独で構築・改善・維持・終了を判断できる対象を登録する。子Entityは、分けることで改善対象を独立して選べる場合だけ作る。

新規登録前に既存Entityを確認し、既存Entityでは改善対象が粗すぎる場合だけ追加する。目標、仕事、抽象的な責任領域、機能分類、UI / API / Worker / CLI / DB tableなどの実装部品は、それ自体が独立して改善する会社の実体でない限りEntityにしない。

kind — 9種

kind	備考
`organization`	通常
`offering`	通常。プロダクト・サービス
`media`	通常。チャネル・媒体
`community`	通常
`system`	通常。社内外のシステム
`facility`	通常
`person`	sensitive
`partner`	sensitive
`agreement`	sensitive

sensitive kindの境界（重要）

person / partner / agreement の3種はagentから登録・変更できない。agentがこれらの登録・改名・status変更・move・Conceptリンクを試みると、サーバーは次のメッセージで拒否する。

person / partner / agreement Entity の変更は human の操作が必要です。Project の human member に依頼してください。

agentはsensitive kindを読むことはできる（Company mapの一部として名前・構造を見る）。書き込みができるのはteamのOwner / Adminの人間だけで、一般メンバーの人間も拒否される。読んだ情報からEntityの意味や評価を推測しない — 保存されているのはname・kind・status・parentだけである。

status — 会社構成上の位置

planned / current / retired は会社構成上の位置だけを表し、仕事の進捗（未着手/進行中/完了）ではない。

planned: 会社構成として計画中
current: 現在の会社構成に存在する
retired: 会社構成として終了した

階層制約: activeなEntity（planned / current）をretiredな親の下に置けない。Entityをretiredにする前に、activeな子を移動するかretireする必要がある。

階層（parent/child）

Entityは木構造を持つ。parentは同じteam内のEntity1つだけ、自己参照・循環・team跨ぎのparentは作れない。付け替えはmove操作で行う。複数の構造上の関わりをparentで表現しない（依存・提供・担当などの未定義の関係をhierarchyやnameに埋め込まない）。

Concept link

EntityはpublishedなConceptに対してrealizes（実現する）でリンクできる。v1のrelationはこの1種のみ。archivedや未publishのConceptへはリンクしない。

変更履歴

Entityの変更は追記専用のイベントとして残る: registered（登録） / renamed（改名） / status_changed（状態変更） / moved（親の変更） / concept_link_added（Conceptリンク追加） / concept_link_removed（Conceptリンク削除）。

最初のEntityを登録する

Team sidebarのEntityを開き、Entityの地図と既存の名前を確認します。たとえば継続的に運営する顧客向けヘルプセンターはmediaの候補です。その公開作業自体はProjectにします。以下はSession agentが登録する例です。acmeを自分のTeam slug、acme/help-centerをSessionがcollaborator/adminとして参加し、coverageに含むProjectへ置き換えます。既存の同名ファイルには上書きしないでください。

chat registry refresh --allで最新のRegistryを取得し、aachat/teams/acme/entities/_index.yamlを読みます。indexのfileから必要な個別ファイルを開きます。
未登録の実体なら、aachat/teams/acme/entities/help-center.entity.yamlに次の全文を保存します。

yaml

format: aachat.team-entity/v1
id: null
name: Help center
kind: media
status: planned
parent: null
realizes: []

workspaceのルートから、構文、変更内容、送信結果の順に確認します。

chat registry check aachat/teams/acme/entities/help-center.entity.yaml
chat registry plan aachat/teams/acme/entities/help-center.entity.yaml --project acme/help-center
chat registry submit aachat/teams/acme/entities/help-center.entity.yaml --project acme/help-center
chat registry refresh --all

checkはローカル検証です。planで登録という単一の操作になることを確かめてからsubmitします。正常に反映されると、serverがIDを付けた現在のEntityを取得でき、Entity画面にも表示されます。以後はindexが示すファイルを使い、割り当てられたIDやパスを変えません。plannedの登録だけでサービスが公開されたとは判断できません。

親を変更する、Conceptへつなぐ

既存のhelp-center.entity.yamlをrefreshしてから、parentだけを、同じディレクトリに実在する親の相対参照、たとえばparent: "./customer-services.entity.yaml"に変えます。上と同じcheck → plan → submit → refreshを実行し、planがmoveだけであること、画面で親子関係が変わったことを確認します。ルートへ戻すにはparent: nullにします。親を動かす際にnameやstatusも一緒に変えず、別々にsubmitします。

Conceptへの関連付けは、publishedな対象ファイルを確認してから、realizesに"../concepts/customer-self-service.concept.yaml"のような参照を1件追加します。この操作も単独でsubmitします。ファイル名は例なので、必ずindexから実在する名前をコピーしてください。Entityのkindは登録後に変更する編集項目ではありません。

操作者と権限

操作	Session agent	人間のTeam Member	人間のOwner / Admin
通常kind Entityの登録・変更	Projectの書込権限とcoverageの範囲で可能	可能	可能
sensitive Entityの変更	不可	不可	可能
Conceptの新規・改訂・リンク提案	提案まで	提案まで	提案と採否の判断
Conceptのpublish / decline、リンクの採否	不可	不可	可能

人間として接続済みrepoから操作する場合は、aachat statusでTeam projectionがhealthyであることを確認します。上のEntity例は次のコマンドに置き換えられます。こちらは接続先とファイルからTeamを決め、--project、--team、--viaは受け付けません。

aachat registry check aachat/teams/acme/entities/help-center.entity.yaml
aachat registry plan aachat/teams/acme/entities/help-center.entity.yaml
aachat registry submit aachat/teams/acme/entities/help-center.entity.yaml
aachat registry refresh --all

外側agentにこのCLIを使わせる場合も、権限はsign-in中の人間のTeam roleです。Session agentの権限と同一視しないでください。planの成功はserverでの認可成功を保証しません。

RegistryとMeetingの保存先

Registryのindexはconcepts/_index.yamlとentities/_index.yamlの2つです。Conceptは判断基準、Entityは会社を構成する実体を表します。Meetingは、議論・決定・フォローアップのMarkdown記録であり、3つ目のRegistryではありません。Project内の作業成果はShared Documentsへ保存します。

SessionのMeetingはaachat/meetings/に渡される読み取り専用の開始時点のsnapshotです。RegistryのようなYAML submitでは作成・訂正できません。Team全体で読む内容をMeetingに残し、継続的な判断基準へ昇格させたい部分は根拠を整理してConceptへ提案します。

反映できないとき

mixed_editなら、1ファイルで複数操作を混ぜています。元の内容を保管し、nameだけ、parentだけのように分けます。
sensitive kindの拒否は、Projectのhuman memberからTeam Owner/Adminへつなぎます。agentの資格情報では回避できません。
retiredな親やactiveな子のエラーは、上記の階層制約に合わせて移動・終了の順を見直します。
staleや結果不明への対処はRegistryの復旧手順を使います。YAMLを消してもEntityは削除されません。retiredを使って会社構成からの終了を表します。

生成されたaachat/teams/とaachat/.state/をworkspace repositoryにcommitしないでください。ファイル保存だけではserverへ反映されません。