7 Commits

Author SHA1 Message Date
Shohei Ikeda 70ed5f97b0 feat(mcponly): 開業・人事評価を service として分離する
mcp-only なエンドポイントはドメイン横断で 1 ファイル (mcponly.yml) に集約されて
配信される。freee-mcp 側は survey service がその全体を掴んでいたため、
開業 (/hub/launch/) と人事評価 (/hub/employee_evaluation/) のエンドポイントが
service: "survey" として扱われていた。

前 commit で入れた pathPrefix を使い、3 ドメインが mcponly ソースを分け合う形にする。

- SERVICE_METADATA に launch / employee_evaluation を追加し、survey を含む 3 つに
  pathPrefix を設定する。survey の表示名を他サービスに合わせて freeeサーベイ API にする
- serviceSchema / SERVICE_HINT / SERVER_INSTRUCTIONS に 2 サービスを追加する
- generate-references の API_CONFIGS に tagServices を追加する。1 ファイルに複数
  service が同居する場合、prefix はエントリに 1 つしか持てずファイル名も INDEX の
  グルーピングも 1 service に潰れるため、タグごとに service を明示する。
  タグ名からはドメインの区切りを判定できないので導出はしない。未定義のタグは
  生成時にエラーにする
- tagServices の値が SERVICE_LABELS に存在することを検証するテストを追加する。
  綴りが違うとリファレンスは生成されるのに INDEX から黙って漏れるため
- tag-mappings の englishName から、service と重複するドメイン名を落とす
- リファレンスを再生成し、survey-launch-kaigyo-application.md と
  survey-employee-evaluation-evaluation-results.md をサービス名に沿ってリネームする
- 開業のレシピを追加する。PATCH は部分更新だが family_employees だけは
  全件置き換えになるため、取得してから全件送る手順を明記する

FREEE_API_BASE_URL_SURVEY が開業・人事評価の向き先まで変えてしまう問題も解消し、
サービスごとに独立して指定できるようになる。

BREAKING: service: "survey" で開業・人事評価のパスを呼ぶとパス検証エラーになる。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-03 21:34:19 +09:00
him0 da8871950a chore: README の対応操作数を OpenAPI スキーマから自動更新する
README に載せている対応操作数を手で数え直さずに済むよう、
generate:references が OpenAPI スキーマから再計算してマーカー間を置き換える。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-28 10:59:22 +09:00
takutin-f 5faf1d4744 Merge origin/upstream into feat/tax-return-api-skill 2026-08-27 16:31:50 +09:00
inomata137 6153e8db03 fix(skill): anyOf の同一スカラー型を正しく出力する 2026-08-24 16:30:51 +09:00
takutin-f cf04bae735 Merge origin/upstream into feat/tax-return-api-skill 2026-08-12 11:25:34 +09:00
him0 6392a7e758 fix(skill): requestBody の $ref と複数要素 allOf を解決する
`formatRequestBody` が `requestBody.content` を直接参照していたため、
requestBody を `components.requestBodies` に切り出している販売管理 API の
40 エンドポイントで、リクエストボディのセクションが丸ごと欠落していた。

また `resolveSchema` は 1 要素の `allOf` しか解決していなかったため、
共通項目を `allOf` で合成しているスキーマでは `properties` が空になり、
型が `object` と誤表示されたり例・制約が落ちたりしていた。

- `components.requestBodies` への `$ref` を解決する
- 複数要素の `allOf` を合成する(properties は後勝ち、required は和集合、
  それ以外の属性は先勝ち。ラッパー自身の description は参照先より優先)
- 循環参照に備えて解決の深さに上限を設ける

いずれも本 PR で入れた退行ではなく、以前から存在していた不具合。
リファレンス合計は 624,845 → 712,058 文字(元の 1,469,759 比で -51.6%)。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 15:39:53 +09:00
him0 cb2aa22b25 fix(skill): リクエストボディ自体の必須性を保持する
`requestBody.required` は schema の `required`(本文内フィールドの必須性)から
推論できないため、見出しの `*` で表すようにした。未指定の schema が多く無指定を
「任意」と書くと実態と食い違うので、明示的に `true` のときだけ付ける。

見出しは重複判定キーに含まれるので、同じ schema を共有していても required が
異なるエンドポイントは「◯◯ と同じ」に潰れなくなる。実際に該当するのは
`tagParams`(POST /api/1/tags: true / PUT /api/1/tags/{id}: false)と
`transferParams`(POST /api/1/transfers: false / PUT /api/1/transfers/{id}: true)。

回帰テストのため `buildEndpointsMarkdown` を切り出して export し、直接実行時のみ
`main()` を呼ぶようにした。vitest の include に `scripts/` を追加している。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 15:26:11 +09:00