ACTIVE仕事repo / 整備2026-07-15 実装済み

求職者管理の単一入口・KPI統合と実行記録基盤

候補者に関する依頼はすべて candidate から始める。 KPIは独立した入口ではなく、候補者イベントを処理するworkflowへ統合した。管理表・KPI表の正本は保ったまま、実行の証跡は仕事repoのローカルログへ残す。Turso接続は別承認の将来作業である。

要点

唯一の入口

candidate に集約し、求職者・管理表・KPIを同じ候補者イベントとして扱う。

正本を増やさない

現在状態は既存表に残す。ログやTursoは候補者状態を複製しない。

安全な記録

ローカルを先に確定する。Tursoは未接続で、別承認の最小監査イベントに限定する。

全体像

候補者の現在状態をTursoへ複製しない。現在はローカル一次ログだけを実装し、Tursoは本番承認後の別作業で最小の監査イベントだけを追加する。

設計原則

「何を更新するか」と「どう実行されたか」を分離すると、AIの入口もデータの正本も迷わない。

決定入口は candidate だけ

KPIは候補者イベントの一部として判定する。利用者も他Skillも、KPIだけを理由に別入口を選ばない。

現在状態の正本は既存の表

管理表とKPI表が業務データの正本である。ローカルログとTursoは更新結果を追跡する派生記録で、状態を再構成するDBにはしない。

不足値は推測せず止める

雇用形態・実行日・KPI経由が未確定なら質問する。 流入元や面談形式から経由を推測しない。

candidateの内部はworkflowで拡張する

SKILL.md は軽いrouterに保ち、KPIの詳細判定を入口へ再び詰め込まない。

candidate/
├── SKILL.md                         唯一の公開入口・router
├── workflows/
│   ├── モード1-現状確認.md
│   ├── モード2-進展報告.md
│   ├── モード3-新規追加.md
│   ├── モード4-対応終了-成約.md
│   └── 候補者イベントとKPI記録.md    共通判定・確認・再読込
└── references/
    ├── 管理表構造.md
    ├── 候補者イベント契約.md
    └── KPIライブ判定規則.md          ライブ表から入力先を特定

候補者イベントに含める判断材料

雇用形態、段階ステータス、流入元、実行事実、実施または設定日、KPI経由、根拠、次の行動、承認状態を共通契約にする。候補者の profile_url は本人照合の処理時だけ使い、実行ログ・Tursoには残さない。

実行記録はローカルを先に確定する

外部表の更新を二重実行しないため、記録・書込み・再読込・同期の順序を固定する。

1
提案と承認を記録
scripts/candidate/output/logs/ に event_id、操作種別、承認状態を残す。Gitには追跡しない。
2
管理表・KPI表を更新
確認済みの差分だけを書き込み、区分行・数式・集計欄には触れない。
3
対象セルを再読込
結果を同じ event_id に追記し、成功・失敗を外部表の状態と照合する。
4
Tursoは未接続のまま止める
接続・spool・同期状態は実装していない。Turso本番承認後に、最小監査イベントだけを別作業で追加する。

旧入口は互換期間を経て終了する

移行中にKPI規則を二重に持たず、すべてのcallerが切り替わったことを確認してから旧入口の扱いを決める。

移行前二つの入口

candidate と旧KPI入口が近いKPI依頼を受けた
固定セル・既定経由が専門Skillに残り得た
近い発話でAIの選択が曖昧だった

実装済み一つの入口

candidate にKPI workflowを一本化した
専門Skillは確定済みイベントだけを渡す
旧KPI入口・CATALOG行・runtime露出を削除した

終了前に確認するcaller

mendan-kanri、haken-mendan、claim、eod、morning、line、work-skill-guide、CATALOG、runtime設定を検索する。旧入口の削除・移動・改名・runtime露出変更は、対象diffと戻し方を示したうえで個別承認を得る。

並列実装はworktreeと専有pathを固定する

最初に契約を凍結してから、KPI統合とログ基盤を別worktreeで並列に実装する。既存の 仕事 worktreeには書き込まない。

Lead  仕事-candidate-orchestrator  01・統合・05のみ
  │  contract-base
  ├── Agent A  仕事-candidate-kpi      .agents/skills/candidate/**
  └── Agent B  仕事-candidate-records  scripts/candidate/**
             │
             └── Leadが順に統合 → integration-base
                                      │
                                      └── Agent C  仕事-candidate-callers
                                           caller・CATALOG・旧入口の互換案内

Reviewer  worktreeなし・read-onlyで05を独立確認

並列中の約束

01で候補者イベントとログ呼出しインターフェースを固定する。Agent AはSkill本体だけ、Agent Bはログ用スクリプトだけを変更し、相手のworktreeへ書き込まない。Leadがテスト結果とdiffを確認して一つずつ統合する。Turso本番、外部表、旧Skillの削除は、どのサブエージェントの担当にも含めない。

5つの子計画で順に実施する

入口の統合だけを先走らせず、事実の契約と記録の安全性を先に確定してから移行判定へ進む。

順序	子計画	完了の焦点
01	正本・候補者イベント契約	完了：データ所有と不足時の停止
02	candidateワークフローへのKPI統合	完了：判定・確認・再読込の一本化
03	実行ログ・Turso監査イベント	完了：local-first。Tursoは未接続
04	呼出元移行と旧入口の終了判定	完了：caller移行・互換案内化
05	検証と移行判定	静的検証完了：実データ検証は承認待ち

TURSOの停止線

候補者の実行ログをTursoへ送るのは、既存のTurso local-first移行が本番承認された後だけです。それまでは仕事repoの output/logs/ を一次記録として運用し、candidateからTursoへ接続しません。

参照

正本計画 — 同階層の program.md と plans/01〜05
Skill正本 — .agents/skills/candidate/
実行記録の配置 — 仕事repoの scripts/**/output/（Git非追跡）
更新原則 — このHTMLは人間向けの派生物。計画変更時はMarkdown正本から再生成する。