The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Thth listing page.
設計: docs/設計_THTH_2026-09-08.md（§8 の裁定済み。現行の設計書）。
承認済み（status: approved）の投稿ファイルを読み、静かな時間帯と最短間隔を守って 1 件だけ投げ、
post_id を書き戻して push し、投稿済みの返信を拾って追記し、走った記録と鮮度を出し、
走らなかったことを外部に知らせるまでを持つ。意味（何を書くか・承認・返信の解釈・採集箱への昇格）は持たない。
watchtower（~/Developer/watchtower）の隣に同じ流儀で並べる。watchtower は POST しないので投稿は混ぜない。
このソースの版は 2.11.0。現在の設計は 自分の泉、導入は 承認を押すだけ、文書の索引は docs/README.md。
版の正本は thth/VERSION（server.json はテストで一致を強制）。開発中の main には未配布の変更も含まれます。インストール済みの版は thth --version、VM の版と revision は thth board で確認してください。
main への push は保存だけ。release を進める操作が配布（VM は release だけを追う。設計 §3.2.1）。
各プロジェクトのセッションが読むのは docs/使い方_プロジェクトのセッション向け_2026-09-09.md だけ。設計書は作った側の記録なので読まなくてよい。
管理者用の サーバー書込、停止・退会、X 読取予算 を追加しています。配布・本番検収とは別です。X の認可・refresh の本人読取も予算対象で、既定 USD 0 のままでは token 交換前に停止します。X 投稿・取得 adapter はまだありません。
招待した利用者は、masaru がサーバー側で始めた認可 URL を開いて承認します。利用者に VM や Meta アプリの準備を求めません。Threads/Mastodon/X は thth auth <account> --by masaru、Bluesky は秘密管理ツールから App Password を thth token set <account> --stdin --by masaru へ渡します。X は認可だけ対応し、投稿・取得は未対応です。「接続」ページはこの版にはありません。
運営者の client 設定、貼付の逃げ道、scope と doctor 観測、X の更新間隔の限界は 統一ガイド にまとめています。認可の成功で承認・digest・production の条件は変わりません。
2.7.0 の実装 revision f331e8c の全件テストは 2743 件（python -m pytest tests/ -q -n auto -p no:cacheprovider・1 skip・rc=0）。開発中の変更の検証は対象 revision の CI を参照してください。
SNS: Threads（稼働）・Bluesky・Mastodon（同席用の台帳あり・未稼働）。
定期実行中: Threads の 3 アカウント（nigamilab・asmon 関東・kopicha）。masaru の Threads は同席用です。
timer（systemd・thth systemd で生成）は10分ごとに実行し、投稿間隔と静かな時間帯を尊重します。返信の取得（thth replies）と数の取得
（thth measured）は稼働、トークン更新は thth maintain が毎日。
入口は 4 つ: 厚い CLI（bin/thth・python -m thth）、薄い MCP（mcp/server.py・読み取りと
同席の投稿・before_you_post）、timer、そして pip install（thth・thth-mcp の entry point・
依存 0。PyPI に公開済み・MCP registry に io.github.aokings/thth として登録済み）。
トピックの棚（thth topics）: 観測者ごとに並ぶ・打ち消し retract-note・history。
台帳の hashtags: true では本文のタグと topic を使えます。topic: 茶 は公開本文の末尾に #茶 を付け、同じタグが既にあれば重ねません。hashtags: false ではタグを追加せず、topic が効かないことを警告します。max_hashtags は公開本文のタグの上限（省略時 3、0 以上の整数）です。承認の指紋はタグを含む公開本文を使うため、以前の本文で承認した原稿は approval_stale になり、再確認・再承認が必要です。
where／topics --search の JSON は by_tag にタグ検索・観測の結果を分けます。ローカルの期間比較は thth analytics-report <account> --compare-previous --by tag --json。API で確認できたタグだけを使い、未観測はタグなしと混ぜません。SNSをまたぐ合算はしません。利用手順・2.8.0 リリースノート。
followers_count_at と staleness_hours を含み、追加APIや過去行の後補完はありません。該当しない場合は context_reason に理由を残します。schema_version=1 のままです。cannot_say_details にコードと既存の説明文を併記。施策レポートには未成熟投稿が24時間に達する予定を添え、取得保証とは分けます。handoff-report --since-last-read で保存済みsnapshotとの差分。cursor保存は CLI の --mark-read --by 名前 を明示したときだけ。MCP・HTTPは読むだけです。analytics-report（活動のスナップショット・--compare-previous で隣接期間の比較）・handoff-report（ローカル運用記録の引継ぎ）・study-report（施策の宣言と本人の観測の結合）。MCP に analytics_report・operations_handoff・study_report。数値は期間・母数・欠測・根拠を連れて歩き、因果や推奨は出しません。serve-reports: 専用環境向けの非公開レポート HTTP（Unix socket 既定・service credential・読むだけ）。開発版で、人の認証・TLS・一般提供は含みません。限界。 2.12 の明示的な user writes: true は 書く口 を追加し、既存の read-only credential は維持します（3.13.0 で承認ページは無くなり、書く口の依頼はその場で行います）。worker（3.13.0 までの名前は approval-worker）: 招待の完了・/activity の要約と操作・ガードを回す常駐。管理者が同じ隔離環境で常駐させます。after の投稿集計、project 指定、topic kind 別集計。台帳を repo の外へ（設計 v2 §3・裁定 §7-1）。正は $THTH_ROOT/accounts/（$THTH_ACCOUNTS_DIR があればそちら）。
repo に台帳は入っていない（2026-09-14 に 6 本を削除）——clone しても他人の台帳は付いて来ないので、
thth account add で自分の 1 本を作るところから始まる。配るのは雛形 accounts.example/ の 3 本だけ。
repo の accounts/ は1 版だけ互換で読む（stderr に警告 1 行・移行前の機械を止めないため）。
thth account migrate が repo の中を外へ copy（移動しない・上書きしない・冪等）、
thth account add <name> --media threads|bluesky|mastodon --project <p> が
accounts.example/<media>.json の雛形から 1 本書く（必ず production: false）。
書く先は互換に落ちていても常に外。doctor・board が置き場を 1 行で言う。
thth ask before-you-post <account> --topic <語>（設計 v2 §1）。この語・この型・この時刻帯で
スレッドがどう伸びたかを、件数と期間つきで返す。読むだけ・手元の台帳だけ（provenance.source
は local。泉のサーバーはまだ無い）。原稿本文は渡さないし、答えにも出ない。
n が閾値（既定 20）に満たない群は中央値を返さず cannot_say に理由を出す——
手元の水ではほとんどが cannot_say になる。それが正しい答えで、rc は 0。MCP からは before_you_post。
読む口（thth where・thth thread・thth who）は取得した投稿本文を保存しません（裁定
2026-09-16「横断の泉はやめる」）。検索語・投稿ID・件数等の最小限のログと、絡みの台帳（自分の行為と反応）は残ります。
英語の文書: README.en.md・docs/usage.en.md・llms.txt。
skill: skills/thth/SKILL.md（wheel にも入る）。
動くもの（thth --help の全サブコマンド）: lint・preview・approve・account・revoke・posts・replies・measured・threads・after・analytics-report・study-report・study・unanswered・handoff-report・observe・morning・serve-reports・worker・topics・forms・queue・schedule・throw・run・systemd・board・collect・pull・auth・refresh・maintain・send・doctor・app・token・ask・mentions・profile・thread・where・who・retract・inflight・location・notifications・report・plaza・map・admin・login・logout。
最初の本番投稿の記録: 2026-09-09、@aoking に疎通確認を 1 本（17916074118445631）。
未着手: X・Facebook ページ・Instagram の各アダプタ。トピック検索の権限（tester には降りない）。泉のサーバー（v2-5）。
権限の制約: tester に降りる scope は 5 つ。削除はできない。
配布: release への反映と version tag の push を分けます。tag の CI が全件テスト後に PyPI と MCP registry へ OIDC で公開します。
registry は「この PyPI の名前を名乗ってよいのは誰か」を、配布物の README にこの 1 行があるかで確かめる（設計 v2-4 §3・一次資料は quickstart・L2）。だから消さないこと——消すと登録（mcp-publisher publish）が通らなくなる。形（server.json と版の一致）は tests/test_server_json.py が見張る。
mcp-name: io.github.aokings/thth
study-report は明示した施策の宣言と本人の投稿観測を結ぶ読み取り専用レポートです。採用者の本人確認や因果効果は主張しません。使い方と契約。
analytics-report はローカル台帳から期間・母数・欠測・根拠を揃えたスナップショットを返します。
形式と使い方。
handoff-report / MCP operations_handoff はローカル運用状態・通知未処理を鮮度の制約付きで返します。形式と使い方。
thth admin inventory|account|log|tokens|timers|release|diff は秘密値を出さない読み取り専用レポートです。開始時は thth admin diff --since-last-read、変化した account は thth admin account <name>、週1回 thth admin tokens。--json で構造化結果を取得できます。既読 cursor の保存は admin diff --since-last-read --mark-read --by <名前> の明示時だけです。VM の admin timers は観測を state/_admin/timers.json に保存します。doctor <name> と admin の明示的な --probe は秘密を除いた診断記録を state/<name>/doctor.json に保存します。HTTP／MCP は時刻付きの記録を読むだけで、観測・保存を実行しません。
account add（--force の上書きも）・app set（旧 flags も）・auth・token set・token revoke には --by <名前> が必須です。既存の作成来歴は上書きしません。token revoke はローカルcredential削除でありリモート側の認可取消ではありません。選定した管理変更は既定で管理者へ通知し、台帳の notify_admin_on_change: false で停止できます。
認証付きMCPの6道具とHTTPのadmin scopeは 管理者skill を参照してください。管理レポートから承認・投稿・設定変更は行いません。ログ追記後のfsync失敗は変更を保持して durability_unconfirmed、部分追記は outcome_uncertain と報告します。再試行前に台帳とログを確認してください。