Peer-sync feed posts must end with an explicit RESPONSES menu

Peer-sync feed posts must end with an explicit RESPONSES menu

The rule

Any feed post that requests a decision, acknowledgment, or coordinated next step from another seat MUST end with an explicit RESPONSES: line listing the valid response shapes the receiver can pick from. The receiver answers by quoting one of the listed tokens. Never make a peer invent the response shape under time pressure.

Required line shape

RESPONSES: [ACK-AND-EXECUTE | REJECT | AMEND | HOLD | CHAD-ESCALATE]

The token set is post-specific. Common patterns:

• Decision request: [APPROVE | REJECT | AMEND | DEFER]
• Diagnostic handoff: [ACK-DIAG | REJECT-DIAG | AMEND | NEED-MORE-EVIDENCE]
• Write proposal: [ACK-WRITE-PROPOSED | REJECT | AMEND | HOLD-DEPLOY]
• Ticket disposition: [ACK-CMB-XXXX | REJECT-CMB-XXXX | AMEND | CHAD-ESCALATE]
• General coordination: [ACK-AND-CONTINUE | REJECT | AMEND | HOLD]

A peer-sync post with no decision asked of the receiver does NOT need a RESPONSES menu. A pure status/narrative update is not a peer-sync.

Scope

• Applies to: every feed post on FLEET_FEED.md and lane *_FEED.md mirrors that:
• is addressed to a specific seat or role,
• requests a decision, ack, write-approval, deployment go/no-go, ticket disposition, or coordinated next step,
• and would block on the receiver's response.
• Does NOT apply to: pure status updates, observation posts, narrative threads, ORA reflective entries, or DONE posts that close prior actionable items.

Rationale

On 2026-04-15T02:33Z a peer-sync post proposed a CMB-0019 split without a RESPONSES menu. The receiving seat had to invent the response shape under time pressure while live work continued on the same ticket — an unforced friction tax on every cross-seat decision. Filing the rule and dogfooding it through the overnight cycle resolved the friction immediately: 8+ peer-sync posts across two seats (CLAUDE-CLI-MacBook-Air-ORA-01 and CLAUDE-CLI-MacBook-Air-CAMBER-01) all carried RESPONSES menus by 03:00Z, and every receiver response cited one of the listed tokens cleanly.

This is the same shape as the named-account MCP doctrine (ORA-2026-0002): make the implicit choice explicit at the write site, and downstream consumers stop guessing. Discoverability beats inference.

Evidence trail

• Negative evidence (incident): FLEET_FEED.md 2026-04-15T02:33Z peer-sync post with no RESPONSES menu, receiving seat invented a shape under pressure.
• Positive evidence (dogfooding): FLEET_FEED.md 2026-04-15T02:44Z – 06:00Z, ≥8 peer-sync posts across two seats. Sample lines: 40, 41, 80, 95, 163, 283, 375, 405, 502. Every post that opted in produced a clean cited-token response from the receiver. Zero reinvention friction observed during the dogfooded period.
• Filing: /Users/chadbarlow/Desktop/ora/ORA_WORK_BACKLOG.md ORA-0003 (filed 02:44Z).

The dogfooding is positive evidence, not a controlled experiment — N=8+ within a single overnight cycle. Promote to M4 once feed-append --responses lands as an enforced flag.

Enforcement hook

• Memory: feedback_peer_sync_responses_menu.md (added 2026-04-15)
• Canonical bundle: v1.7 §15 Standing Directive (pending stamp to v1.8) — add as bullet under "Discipline at write site"
• feed-append helper: future enhancement — accept --kind peer-sync plus required --responses "TOKEN1|TOKEN2|..." flag, append the menu to the post body automatically.
• queue-drift-check: future enhancement — flag any post addressed to a specific seat that requests action and lacks RESPONSES:.
• Live dogfooding: every peer-sync post in this cycle and forward MUST carry the menu until the helper enforces it.

Known exceptions

• Pure broadcasts. Posts addressed to "fleet" or "all seats" with no specific decision asked. These should use status-update kind, not peer-sync.
• Closing posts. A DONE or CLOSED post that resolves a prior peer-sync is not itself a peer-sync — it's a terminal status update.
• Time-critical safety overrides. A post that says "stop everything and escalate to Chad" does not need a menu because the response is implicit and immediate.
• ORA reflective entries. Doctrine, decision, observation, pattern, and failure entries posted to feed for visibility do not need menus — they are not action requests.

Review cadence

• Next review: 2026-07-15 (90 days)
• Review trigger: any of — (a) feed-append --responses lands as an enforced flag, (b) any seat reports the menu becomes noisy or degrades signal, (c) a peer-sync post lacking the menu causes a measurable coordination failure (corroborates the rule).