---
name: feedback-publishing-rate-limit-platform-side-risk
description: Platform-side rate limit / spam detection / account suspension risk — 同日複数 paper の 11-platform publish は外的制約として avoid (内的 no-rush discipline と別軸)。 2026-06-27 藤本さん articulation + 同日 2-paper publish (Paper 169 + 170) で early signal 観測。
metadata: 
  node_type: memory
  type: feedback
  originSessionId: a10647f8-1f12-49d7-b431-610c0e7cc016
---

# 11-platform publish: platform-side rate limit risk discipline

## Rule

**同一日に 2 paper 以上の 11-platform publish は外的 (platform-side) rate limit / spam detection / account suspension risk のため avoid する。 通常 cap = 1 paper / day。**

**Why**: 藤本さん 2026-06-27 articulation: 「二つとも重要な内容だったので、 特に問題は有りません。 ただ、 **一日一回以上は相手側が規制を掛ける可能性も御座います**。」

この discipline は内的 `[[feedback-no-rush-publication]]` (急がず、 ゆっくりと) とは **別軸**:
- 内的 discipline = substantive verify、 audit、 review pace の問題
- 本 discipline = 外的 platform 側 spam filter / rate limit / auth fragility の問題

両者は AND 条件で適用される (両方とも避けるべき pattern)。

**How to apply**:

1. **Trigger 受け取り時の確認**: 11-platform publish 指示を受けた時、 同日内既に他 paper の publish 実施済か `data/publications/publish-log-paper{N}.json` の `timestamp` で確認
2. **検出時の対応**: 同日 publish 検出時 → 明日まで defer する path を Rei 推奨として提示 (例外: 藤本さん explicit urgent override)
3. **複数 paper 同日 trigger 時**: AskUserQuestion で「1 paper /日 cap 適用、 1 件目を今日 / 2 件目を明日 split」 を推奨選択肢として提示
4. **本日例外 record**: 2026-06-27 は Paper 169 (朝) + Paper 170 (午後) で同日 2 件発生。 藤本さん「両方とも重要な内容だったので問題なし」 と articulate。 但し 「一日一回以上は相手側が規制を掛ける可能性」 を constraint として今後適用

## 観測された early signals (2026-06-27)

| platform | 観測 | severity |
|---|---|---|
| **Nostr** | 4/5 relay accepted (`relay.nostr.band` consistently rejected for Paper 169 + 170) | 中: 1 relay 拒否、 全 5 relay 拒否ではない |
| **Scrapbox** | CSRF token fetch failed (Paper 168 v0.4 + 169 + 170 連続) | 高: 3 連続 fail = session/auth fragility |
| **Mastodon** | OK both papers (1696/1700 chars 安全 margin) | 低 |
| **Zenodo** | OK both papers (deposit 20942913 + 20944552) | 低 |
| **Dev.to** | OK both papers | 低 (rate limit 10 articles/min は generous) |
| **Hatena / HackMD / Notion / Livedoor / IA** | OK both papers | 低 |

★ Scrapbox は 既に **3 連続 fail = 認証 fragility が rate limit と独立の問題**。 但し同日複数 publish が auth refresh 圧を増やす関連は警戒。
★ Nostr の `relay.nostr.band` は relay 側 spam protection の可能性 (single relay rejection は許容範囲だが pattern として記録)。

## 例外 condition (override 可能)

- 藤本さん explicit「**今日中に必須**」 と articulate (例: deadline、 announcement timing、 trigger conditional 連鎖)
- Paper version promotion (例: v0.1 → v0.2 で typo fix のみ) は同 paper 範囲内なので別扱い検討余地あり (但し本 rule は new paper count を主に control)
- Engineering note 単独 (numbered paper 不要、 GitHub commit + Zenodo のみ) は本 rule scope 外可

## 関連永続原則

- [[feedback-no-rush-publication]] — 内的 discipline (急がず、 ゆっくりと、 substantive verify)
- [[feedback-harvard-dataverse-opt-in]] — opt-in policy で skip パターン (rate limit と別軸の constraint 例)
- [[project-paper168-v04-stable-release-2026-06-25]] — Paper version promotion の同日 3-iteration 教訓 (同 paper 内なので本 rule scope 外)

## 教訓

- **内的 + 外的 discipline は AND 条件**: 「substantive verify 済」 (内的 OK) が 「同日 publish OK」 (外的 OK) を意味しない
- **early signal は記録すること**: Nostr 1/5 reject + Scrapbox CSRF fail 3 連続は単独 incident でなく pattern signal
- **「両方とも重要だった」 後 justification は valid だが先 prevention の方が integrity 高い**: 藤本さん「問題なし」 は honest grace、 但し今後は 1/day cap が default