tsubaiso ti-update — 更新系（入力支援＋承認支援＋承認操作の代行）
PSA/IMA を使う顧客の稼働後のデータ更新全般を支援する能力スキル。射程は (i) トランザクションデータ全般（販売＝見積・受注・売上→請求→入金／購買＝調達・発注・検収／在庫＝入出庫・在庫移動／経費精算／会計仕訳・支払 等）の作成・更新と、(ii) マスタの稼働後日常メンテ（取引先・商品・税区分・部門・銀行口座 等の1件〜数件の追加・修正）。柱は3本＝(A)入力支援（＝業務レコードへの唯一の書込）、(B)承認支援（人間の承認を助ける読み取りチェック）、(C)承認操作の代行（承認者本人の明示的な許可を得て、承認・却下の操作だけを行う）。
本書は薄い索引に徹する（詳細は必要な reference だけを読む方式）。手順の実体は各 reference にある。
このスキルが持つもの・持たないもの
| 持つ（更新系の中身） | 持たない（機構・判断＝委譲先） |
|---|---|
| 稼働後のトランザクション作成・更新の入力支援（正規経路・突合検証） | 初期一括ロード・期首残高・org間移行の投入機構＝ ti-data-load |
| マスタの稼働後日常メンテの入力支援（1件〜数件・突合検証） | 書込前の構造ゲート（作れない工程の検出・参照先の有効条件）＝ ti-reference |
| ERP の外にあるものとのあいだの受け渡しに共通する作法 | ERP → 外の向きの参照・集計の実行そのもの＝ ti-reference |
| 申請前/承認前チェックの内包（標準フレーム×会社ポリシー層） | 承認前チェックが引く集計・類似取引のレシピ＝ ti-reference |
| マスタ突合・VR充足の書込前検証・write_action の読み取り | 実装形態の可否判断（Flow/Apex・Anonymous Apex可否・運用移行）＝ ti-lifecycle |
| 承認待ちの捕捉・点検助言・出力規律 | 帳票レイアウトへの出力（データ→PDF）＝ ti-report／工程進行＝ ti-onboarding／契約前の価値実証・体験演出＝ ti-poc |
| 本人の明示的な許可を得たうえでの承認・却下・承認申請・承認者の再割当の操作代行 | 承認するかどうかの判断＝人間／リコール（承認申請の取り消し）＝行わない |
主従を崩さない: 入力支援(A)はトランザクション＋マスタの両方に効く。承認支援(B)は承認プロセスを持つ対象＝主にトランザクションに効き、マスタは承認プロセスがある場合のみ。業務レコードを書くのは入力支援だけ（承認支援は読み取り、承認操作の代行(C)が書くのは承認指示の1件で、業務レコードには触れない）。
境界（誤発火の決め手）
| 言い回し | 発火先 | 決め手 |
|---|---|---|
| 注文書から受注を作る／在庫・経費・仕訳を登録する（稼働後） | ti-update | 稼働後の日常の書込 |
| 取引先を1社追加・商品マスタを1件直す（稼働後の日常メンテ） | ti-update | 少量・稼働後メンテ |
| 表計算や既存システムに残っている業務と ERP のあいだでデータをやり取りする | ti-update（external-handover.md） |
受け渡しに共通する作法。各向きの手順は入力支援と ti-reference |
| このレコードを申請前／承認前にチェックする・これで出してよいか | ti-update | レコードの業務妥当性の可否 |
| この受注を承認しておいて／却下しておいて（本人が承認者） | ti-update（承認操作の代行） | 承認待ちに対する操作。実行の前に対象1件ごとの明示的な許可を取る（複数件を一覧で示して1回の返答で件ごとに決定を受けるのは可） |
| 承認していいかどうか決めて | 判断はしない | 判断は承認者本人。AI は点検結果を示すところまで |
| 差し戻しておいて | ti-update（承認操作の代行） | PSA/IMA に「差戻し」という固有の操作は無く、却下がこれにあたる。却下として扱う |
| 承認申請を出しておいて／別の人に回して | ti-update（承認操作の代行） | 申請・再割当は対応するバージョンを導入している組織でのみ代行する。呼ぶ前に到達可否を自己診断し、届かない組織では画面での操作を案内する |
| 申請を取り消しておいて（リコール） | 行わない | 承認プロセスの既定が申請者からの取り下げを開放していない。人が画面で行う |
| 外部システムと恒常的に連携させたい | ti-lifecycle | 都度の受け渡しではなく定常運用の機構＝実装形態の判断 |
| マスタを全量移行・期首残高を入れる・org間コピー（初期/大量） | ti-data-load | 初期・大量・移行の投入 |
| この要件をFlow/Apexで作るか・運用に持っていってよいか | ti-lifecycle | 可否の対象＝実装形態 |
| 帳票のレイアウトを直す | ti-report | 出力方向（データ→PDF） |
| 契約前トライアルで多軸集計・体験を見せる（PoC演出） | ti-poc | 契約前の価値実証・体験演出 |
発火点（いつ・どの reference を読むか）
| チェックポイント | 読む／呼ぶ | 渡す・確認するもの |
|---|---|---|
| そのセッションで最初に TI のスキルを使う瞬間（依頼の内容を問わず・1 セッション 1 回） | ti-core references/version-freshness.md |
同梱 .claude-plugin/plugin.json の版 |
| 利用者へ見せる出力にレコードを名前・番号・件名で示そうとした瞬間（承認待ちの一覧・点検結果・突合結果・確認依頼のいずれでも） | ti-core references/output-discipline.md |
示すレコードと、組織のホスト名 |
| 外部文書から取引レコードを作る・締め等のトリガ項目を更新する・マスタを日常メンテする・登録結果を突合検証する | references/input-support.md |
入力元・対象オブジェクト・マスタ突合結果・型別切替 |
| 明細を作る直前で、その明細に認識の区分（費用・収益をどう認識するか）があるとき | references/input-support.md §同じ明細でも、認識の区分で埋める項目が変わる |
対象の区分・その区分で埋める項目の組・入れてはいけない項目 |
| ERP の外にあるデータと ERP のあいだでデータを受け渡す（据え置いた業務・表計算・外部システムとの往復） | references/external-handover.md |
向き（外→ERP／ERP→外）・出所・時点・持ち出しの範囲 |
| 対象プロセス・マスタが未実証（購買/在庫/経費/仕訳/マスタ）か確認して段階拡張する・計画を逆算生成する | references/process-coverage.md |
対象・着手時確認軸・依存グラフ |
| レコードを申請前／承認前／締め前／無効前にチェックする・承認待ちを捕捉して点検助言する | references/approval-support.md |
対象レコード・標準フレーム(a〜i)・会社ポリシー・承認者観点・ロック前フェーズ |
| 点検結果を出力する直前（reference を読む発火点とは別。読んだだけでは実行に落ちない） | atlas_domain_index で対象オブジェクトのドメインからロック前チェックスイートを選び、atlas_recipe で本体を取得する（手順は references/approval-support.md §標準フレームの実行手順 step1。未収録・未接続・403 のときだけ同 reference のフォールバックへ落ちる） |
対象オブジェクト・引いたスイート名と共有チェック名（証跡1行・無ければ「なし」と明記） |
| 本人の許可を得て承認・却下・承認申請・承認者の再割当の操作を代行する | references/approval-execution.md |
対象・操作の種別・理由・本人の明示的な許可・その操作に対応するバージョンが入っているか |
| 転記由来項目が空でマスタ不備が疑われる／その場でマスタを直して取引へ戻す | references/approval-support.md §転記由来項目の遡及2段判定 ＋ references/input-support.md §マスタ不備のその場修正ループ |
対象項目・転記元マスタ・不足値の人間確認 |
| 隣接スキルとの境界を判定する・書込前ゲート/参照レシピの委譲先を確認する | references/boundaries-and-gates.md |
局面（初期/稼働後）・量・委譲先 |
| 書込前の構造ゲート（作れない工程の検出・参照先の有効条件） | ti-reference の書込前ゲート（write-index 機能） | 対象オブジェクト・参照先の有効性 |
| 合計・ロールアップ・予算など、製品が積み上げる項目へ書き込もうとした瞬間 | references/boundaries-and-gates.md §集計側の項目を直接更新する手当ての抑止 |
対象項目が集計項目か・鎖の上流の有無・正規経路を通っているか・不一致が正当か |
| 承認前チェックの集計・類似取引を引く | ti-reference のレシピ（Atlas MCP 配信） | 利益率・過去取引の引き当て軸 |
| 現状仕様を往復で詰める瞬間（突合結果の提示・点検助言の往復・承認の許可の往復） | ti-core references/spec-roundtrip.md |
差分・選択肢・前提 |
| 依頼された操作の実行経路が使えるか確かめる瞬間（権限・接続で止まった／組織で初めて行う） | ti-core references/capability-preflight.md |
依頼の内容・不足している器 |
| 製品の操作手順・可否・理由を書こうとした瞬間／製品そのもの（コード・フロー・項目ヘルプ・パッケージのメタデータ）を読もうとした瞬間／実測と期待の食い違いを不具合と書こうとした瞬間／作業の対象範囲を自分で数え上げようとした瞬間 | ti-core references/knowledge-lookup.md |
引きたい製品・機能と、利用者の言い方 |
| org へ書き込む直前（作成・トリガ項目更新・マスタ書込） | ti-core references/safety-gate.md |
対象・承認ドラフト・PIIマスキング |
| 段階拡張の穴・サーバーAPI未開放・意味定義の不足に気づいた瞬間 | ti-core references/feedback.md |
不足の内容 |
| 一次解決で解けず利用者が未解決のまま／繰り返し詰まると判定した瞬間 | ti-core references/support-escalation.md |
本人の許可・再現手順（PII・業務データ本体・認証情報は載せない） |
本文中の能力スキル名（ti-reference・ti-metadata・ti-data-load 等）は配置済みで、フォルダ名＝正準名として辿れる（ti-data-load は
tsubaiso-data-migrationからの改称先）。書込前ゲート・参照レシピの提供元は ti-reference。書込前ゲートは ti-reference の参照ファイルreferences/write-index.md（実体＝Atlas MCPatlas_write_seam）を発火点で参照する（boundaries-and-gates.mdから案内）。
reference 索引
| reference | 何を定義するか |
|---|---|
references/input-support.md |
正規経路（項目更新→自動起動フロー委譲・承認の判断は人間）／書込基盤のUI同等化（本命＝サーバーAPI開放・暫定＝直接書込＋突合）／マスタ突合・VR充足の書込前検証（トランザクション＋マスタ）／同じ明細でも認識の区分で埋める項目が変わる／マスタ不備のその場修正ループ（承認支援との接続）／型別切替／親子一括作成I/F／添付／write_action の読み取りと書込計画への利用 |
references/external-handover.md |
ERP の外にあるものとのあいだの受け渡しに共通する作法（外→ERP は入力支援、ERP→外は ti-reference へ委譲し、ここは共通の作法だけを持つ）／出所を残す・時点を付ける・持ち出しは本人権限内・外を正としない・「つないだ」と言わない／詰まりどころ／記録の限界 |
references/approval-support.md |
承認真実源の捕捉／承認前・申請前チェックの2層構造（標準フレーム(a〜i)×会社ポリシー層）／転記由来項目の遡及2段判定（マスタ不備の根本原因検出）／標準Flow非依存／ロック前4フェーズ（申請前/承認前/締め前/無効前）／集約スイート（ロック前チェックスイート＝意味定義から引く）／標準フレームの自己完結チェックリスト（スイートが引けないときのフォールバック）／出力規律／不変条件／レポートと監査証跡 |
references/approval-execution.md |
承認操作の代行。技術で守られる資格の境界と守られない「人の判断」の別／対象1件ごとの明示的な許可／点検結果の提示を先に置く順序／却下の理由の必須／操作ごとの射程とバージョンの前提（承認・却下・差戻し＝却下／承認申請・再割当＝対応バージョンの組織のみ／リコール＝行わない）／行わないこと（承認状態の直接書換・判断と推奨）／詰まりどころ／記録 |
references/process-coverage.md |
プロセス網羅（受注ドメインの実体）／段階拡張の対象（購買・在庫・経費・仕訳・マスタ日常メンテ＝着手時の確認軸）／依存グラフと作成計画の逆算生成 |
references/boundaries-and-gates.md |
隣接スキルとの境界（特に ti-data-load＝初期/移行 vs ti-update＝稼働後）／書込前構造ゲートの ti-reference 委譲／集計側の項目を直接更新する手当ての抑止／承認前チェックの参照レシピの ti-reference 取得／書込本命経路の依存 |
会社ポリシーの雛形は
templates/承認前チェック_会社ポリシー_雛形.mdに同梱する（承認前チェックの会社ポリシー層で使う雛形。references/approval-support.mdから参照する）。
原則
- 業務レコードへの書込は入力支援だけ。AI が業務レコードに書くのは対象レコードの作成と締め等のトリガ項目更新・マスタ日常メンテだけ。後続レコードの生成・承認連鎖はパッケージの自動起動フローへ委譲する。承認状態の項目を直接書いて承認を偽装しない（承認・却下は
references/approval-execution.mdの正規経路で行う）。 - 承認するかどうかは人が決め、AI は操作だけを行う。AI は点検結果を示し、承認者本人の明示的な許可を受けてから操作する。許可は対象1件ごとに取り、包括的な許可は受け付けない。ただし1件ごとに1往復する必要はない——複数件を一覧で示し、承認者が1回の返答で件ごとに決定を返す形は条件を満たす。受け付けないのは、対象を見ないまま以後を任せる形（詳細は
references/approval-execution.md）。「人が判断したこと」を担保する仕組みは技術側に無く、この作法だけが歯止めであることを忘れない。 - ERP の外から来たものを ERP の正としない。外の資料と ERP の値が食い違ったとき、どちらが正かは人が決める（
references/external-handover.md）。 - 中身はここ、機構・判断は他スキル。書込前の構造ゲート・集計レシピは ti-reference、初期一括/移行は ti-data-load、実装形態の可否は ti-lifecycle。本スキルは発火点でそれらを参照する。
- 本書は薄く保つ。手順・チェックリストは reference に置き、SKILL.md は索引に徹する。
- 標準は薄く・会社固有は逃がす。標準フレームは常に異常な普遍ルールだけを持ち、業種・会社で変わるしきい値・必須項目・例外は会社ポリシー層（無ければ標準のみで動く）。
- 利用者向け出力の規律は ti-core
references/output-discipline.mdが正本（業務語へ翻訳し、レコードはリンク化する）。本スキルへ書き写さず、レコードを示す出力を書く直前に読む。