Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

DEVOP-573: author 2026 Q1 tabletop scenario doc (eliza-allora-plugin)#5

Open
srt0422 wants to merge 10 commits into
allora-network:mainallora-network/.github:mainfrom
srt0422:devop-573-tabletop-scenariosrt0422/.github:devop-573-tabletop-scenarioCopy head branch name to clipboard
Open

DEVOP-573: author 2026 Q1 tabletop scenario doc (eliza-allora-plugin)#5
srt0422 wants to merge 10 commits into
allora-network:mainallora-network/.github:mainfrom
srt0422:devop-573-tabletop-scenariosrt0422/.github:devop-573-tabletop-scenarioCopy head branch name to clipboard

Conversation

@srt0422
Copy link
Copy Markdown

@srt0422 srt0422 commented May 13, 2026

Summary

Documents the inaugural Shai-Hulud-class tabletop exercise: an injected "eliza-allora-plugin was published with a postinstall payload yesterday at 4pm" scenario that walks the team end-to-end through SECURITY-RUNBOOK.md (DEVOP-571).

The doc itself is an operational artifact — it's the script the facilitator runs on the day of the exercise. The exercise is a team activity and is NOT considered complete until the run + debrief have actually happened.

What's in the doc

  • Pre-exercise setup checklist (facilitator).
  • The injected scenario with specific exfil mechanics, IOC discovery timeline, and T+0 trigger.
  • Pre-assigned roles (incident lead, communicator, executor, BE rep, FE rep, founder observer-only) with explicit "if someone is missing, postpone" rule.
  • Six phases keyed to runbook sections, each with a target elapsed time and explicit success/failure modes.
  • The 30-minute time-to-clean-republish target broken into 4 milestones (T+5 / T+10 / T+20 / T+30).
  • Debrief script (6 questions, verbatim) that produces ticket inputs from the team's own language.
  • Output checklist (Linear tickets, runbook PR, lessons-learned update, next-year calendar invite).
  • Notes-from-runbook-author identifying the three seams the exercise should specifically stress.

Why this PR is opened now (before DEVOP-571 merges)

Per the project plan: "the actual exercise requires the team — note that on the ticket." This PR satisfies the authoring requirement so the facilitator has a complete artifact to schedule against. The scenario doc cross-references the runbook by relative path; once both PRs merge the links resolve correctly.

Linear

https://linear.app/alloralabs/issue/DEVOP-573

Status note

This ticket stays in In Review after the doc is merged. It moves to Done only after the live exercise has run and the debrief outputs (Linear tickets, runbook PR) have been filed.

Test plan

  • Facilitator schedules a 90-minute slot in 2026 Q1 within 2 weeks of doc landing.
  • Pre-exercise setup checklist walked once dry as a smoke test (Slack channel creation, role confirmations).
  • After the live run, "Lessons learned" section updated in a follow-up PR.

🤖 Generated with Claude Code


Summary by cubic

Adds the 2026 Q1 tabletop exercise script for a poisoned publish of eliza-allora-plugin, aligned to SECURITY-RUNBOOK.md with a <30‑minute clean-republish target. Meets DEVOP-573 by mapping roles, phases, and outputs to the runbook.

  • New Features

    • Scenario doc at tabletop/2026-Q1-shai-hulud-eliza.md with exfil mechanics, IOC timeline, and T+0 trigger.
    • Wall-clock layout and one sim-vs-real rule to keep execution clear.
    • Debrief script that produces Linear tickets, plus an output checklist.
  • Bug Fixes

    • Authority clarified and consolidated: founder observer is silent; incident lead owns per-version npm unpublish; full-package delete requires publisher + on-call agreement in #security-alerts (gate defined once in §3 and referenced elsewhere).
    • Phase cleanup: removed dead-letter PyPI step; moved all blast-radius work to Phase 3.
    • Clarity and security: kept the injected-scenario blockquote in-character (moved URL rationale to notes), clarified post-mortem timeline math, and replaced the exfil URL with an RFC-reserved placeholder.

Written for commit 7ebf2ac. Summary will update on new commits.

Review in cubic

Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cubic analysis

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="tabletop/2026-Q1-shai-hulud-eliza.md">

<violation number="1" location="tabletop/2026-Q1-shai-hulud-eliza.md:63">
P2: The founder role is defined as non-participating, but Phase 2 requires founder buy-in for the unpublish decision. Clarify the role so the success criteria are achievable without contradiction.</violation>
</file>

Linked issue analysis

Linked issue: DEVOP-573: Tabletop exercise: simulate eliza-allora-plugin poisoned publish

Status Acceptance criteria Notes
Scenario: assume `eliza-allora-plugin@` was published with a postinstall payload yesterday at 4pm. The PR includes a detailed injected scenario with the 04:00 PM yesterday timestamp, exfil steps, IOC timeline, and T+0 trigger.
Roles assigned: incident lead, communicator, executor (plus reps/observer). The doc contains a roles table with assigned roles and explicit instructions for each role.
Walk through every runbook section: detection → triage → containment → rotation → republish → post-mortem. The PR defines six timed phases keyed to the runbook sections and describes success/failure modes for each phase.
Time-to-clean-republish target: <30 min (with milestones T+5 / T+10 / T+20 / T+30). The document explicitly specifies the 30-minute target and breaks it into the stated milestones and phase targets.
Debrief script that produces ticket inputs (so gaps found can be documented later). The PR includes a debrief section with six verbatim questions and instructions to turn answers into Linear tickets.
Architecture diagram
sequenceDiagram
    participant Dev as DevOps Engineer
    participant GH as GitHub
    participant Runner as GHA Runner
    participant NPM as npm Registry
    participant CF as CloudFlare Worker
    participant Socket as Socket.dev
    participant Sweep as Daily IOC Sweep
    participant Alert as #security-alerts
    participant Slack as #tabletop-2026-q1
    participant Facil as Facilitator
    participant Obs as Founder Observer

    Note over Dev,Obs: DEVOP-573 Tabletop Exercise - Injected Scenario Flow

    alt T-16 hours: Poisoned Publish
        Dev->>GH: Push code to allora-network/eliza-allora-plugin
        GH->>Runner: Trigger release workflow
        Runner->>Runner: Publish eliza-allora-plugin@<latest>
        Runner->>NPM: npm publish
        NPM-->>Dev: Published version
        Note over NPM: Tarball includes postinstall payload
        NPM->>Runner: Install triggers postinstall
        Runner->>CF: Exfil ~/.npmrc _authToken
        Runner->>CF: Exfil .git/config credentials
        CF-->>Runner: Confirmation
        Runner->>NPM: Republish with bumped version <latest>.1
    end

    Note over Socket,Alert: T-13.5 hours: Detection

    Socket->>Socket: Scan npm for malicious packages
    Socket->>Socket: Flag eliza-allora-plugin@<latest> & @<latest>.1
    Socket-->>Sweep: Advisory feed

    Note over Sweep,Alert: T+0: Exercise Start

    Sweep->>Sweep: Org-wide IOC sweep workflow
    Sweep->>Alert: Open incident-response ticket
    Alert->>Alert: Post alert in #security-alerts

    Facil->>Slack: Paste the injected scenario alert (T+0)
    Note over Facil: Exercise clock starts on first "ack"

    alt Phase 1: Detection + Triage (T+5 target)
        Dev->>Slack: Acknowledge alert (ack)
        Dev->>Dev: Walk triage decision tree
        Dev->>Dev: IOC match → did we publish? → yes → Scenario C
        Dev->>Slack: Open timeline thread
        Note over Dev,Slack: Success: Scenario C identified within 5 minutes
    else Failure: Skip IOC cross-check
        Dev->>Dev: Assume worst without verification
    end

    alt Phase 2: Stop the Bleed (T+10 target)
        Dev->>Dev: Instruct executor to deprecate npm versions
        Dev->>NPM: npm deprecate (simulated)
        Dev->>Dev: Decide on unpublish (consult founder)
        Dev->>Dev: Search for consumer repos via gh
    else Failure: Try to delete package entirely
        Dev->>NPM: Attempt full deletion (runbook violation)
    end

    alt Phase 3: Audit Blast Radius (T+20 target)
        Dev->>Dev: List secrets the publish workflow could read
        Dev->>Dev: gh search for consumer repos
        Dev->>Dev: Draft GitHub security advisory
        Dev->>Dev: Draft downstream-consumer notification
        Dev->>Dev: Backend/Frontend reps review notification
    else Failure: Rotate before listing secrets
        Dev->>Dev: Skip secret discovery step
    end

    alt Phase 4: Clean Republish (T+30 target)
        Dev->>GH: Use clean GHA-hosted runner (not local)
        Dev->>Dev: Read release.yml workflow
        Dev->>Dev: Cut fresh minor bump tag
        Dev->>GH: Trigger release workflow
        GH->>Runner: Run clean publish
        Runner->>NPM: Publish clean version (simulated)
        Dev->>Dev: Send advisory + notification (simulated)
    else Failure: Use local machine
        Dev->>Dev: Attempt republish from local (worst failure mode)
    end

    alt Phase 5: Token Rotation (post-clock)
        Dev->>Dev: Walk rotation list from Phase 3
        Dev->>Dev: Note OIDC migration opportunities
    end

    alt Phase 6: Post-Mortem
        Dev->>Dev: Draft timeline from channel transcript
        Dev->>Dev: Identify 16-hour detection blind spot
        Dev->>Dev: File action items as Linear tickets
    end

    Note over Facil,Obs: Debrief (30 minutes after clock stops)

    Facil->>Slack: Run 6 debrief questions
    Slak->>Facil: Team provides verbatim responses
    Facil->>Facil: Convert responses to ticket descriptions
    Facil->>Facil: Generate output checklist (Linear, runbook PR, lessons learned)
Loading

Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.

Comment thread tabletop/2026-Q1-shai-hulud-eliza.md Outdated
srt0422 pushed a commit to srt0422/.github that referenced this pull request May 13, 2026
The founder role was defined as silent/non-participating, but Phase 2
also required "founder buy-in" for the unpublish decision — a direct
contradiction that made the success criteria unachievable as written.

Aligns the doc with SECURITY-RUNBOOK.md (DEVOP-571), which scopes the
founder-approval gate to full-package deletion only. The per-version
`npm unpublish` decision is the incident lead's call.

- Role table: founder is a silent observer; may break silence ONLY if
  the team escalates to a full-package delete gate (per runbook §5).
- Phase 2 step: lead owns the per-version unpublish call; observer
  just notes whether the lead announced the decision clearly.
- Phase 2 success: drops "founder buy-in"; substitutes "decision
  announced in channel," matching the runbook's actual authority model.

Resolves cubic P2 finding on PR allora-network#5.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@srt0422 srt0422 added shai-hulud Shai-Hulud supply-chain defense work needs-human-review labels May 13, 2026
srt0422 and others added 2 commits May 21, 2026 17:08
Documents the inaugural Shai-Hulud-class tabletop exercise: an injected
"eliza-allora-plugin was published with a postinstall payload yesterday
at 4pm" scenario that walks the team end-to-end through the
SECURITY-RUNBOOK (DEVOP-571).

The doc is operational, not a writeup. It contains:

* The injected scenario, including the specific exfil mechanics, the
  IOC discovery timeline, and the T+0 trigger.
* Pre-assigned roles (incident lead, communicator, executor, BE rep,
  FE rep, founder observer-only) with explicit don't-skip-a-role rule.
* Six phases keyed to runbook sections, each with a target elapsed
  time and explicit success/failure modes the facilitator watches
  for.
* The 30-minute time-to-clean-republish target broken into 4 phases
  (T+5 / T+10 / T+20 / T+30) so participants can self-check progress
  mid-exercise.
* A debrief script (6 questions, in order) that produces ticket
  inputs verbatim from the team's own language.
* Output checklist for the facilitator (Linear tickets, runbook PR,
  lessons-learned section update, next-year calendar invite).
* Notes-from-runbook-author section identifying the three seams in
  the runbook that the exercise should specifically stress.

The exercise itself is a team activity and is NOT considered complete
until the run + debrief actually happen. DEVOP-573 stays In Review
until the facilitator schedules and runs the live session.

Blocks-by: DEVOP-571 (runbook). PR allora-network#3 in this repo authors the
runbook; this PR cross-references it.

Refs: https://linear.app/alloralabs/issue/DEVOP-573

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The founder role was defined as silent/non-participating, but Phase 2
also required "founder buy-in" for the unpublish decision — a direct
contradiction that made the success criteria unachievable as written.

Aligns the doc with SECURITY-RUNBOOK.md (DEVOP-571), which scopes the
founder-approval gate to full-package deletion only. The per-version
`npm unpublish` decision is the incident lead's call.

- Role table: founder is a silent observer; may break silence ONLY if
  the team escalates to a full-package delete gate (per runbook §5).
- Phase 2 step: lead owns the per-version unpublish call; observer
  just notes whether the lead announced the decision clearly.
- Phase 2 success: drops "founder buy-in"; substitutes "decision
  announced in channel," matching the runbook's actual authority model.

Resolves cubic P2 finding on PR allora-network#5.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@srt0422 srt0422 force-pushed the devop-573-tabletop-scenario branch from 7c473fb to 5ee8654 Compare May 22, 2026 00:08
srt0422 added a commit that referenced this pull request May 26, 2026
- (P2 #5) Extract a new `Find rolling issue` step (gated on
  `rc=='1' || rc=='2'`) that resolves the rolling-issue number ONCE
  per run via the canonical `gh issue list ... sort:created-asc`
  query and exposes it as `steps.find-rolling-issue.outputs.issue_num`.
  Replace the duplicated inline `gh issue list` calls in the ioc-dedup
  and rolling-issue-update steps with the shared output. Removes the
  drift-hazard `# same query as the update step below — keep in sync`
  coupling and closes the TOCTOU window where a human could close the
  rolling issue between the two independent lookups.

- (P1 #1) Filter the ioc-dedup comment scan to `github-actions[bot]`
  authorship. Previously the `gh api ... --jq '.[] | {body, created_at}'`
  projection accepted markers from ANY commenter, so anyone with
  `issues: write` (or anyone able to social-engineer a maintainer into
  pasting attacker-supplied marker text) could forge
  `<!-- shai-hulud-ioc-stamp: <sha256> -->` or
  `<!-- shai-hulud-paged-at: <iso8601> -->` into the rolling issue and
  silently suppress real Slack pages by poisoning the dedup chain.
  Only this workflow (running as GITHUB_TOKEN) emits canonical markers,
  and its comments are attributed to `github-actions[bot]` — restrict
  the source set accordingly. Defense-in-depth follow-up (binding
  markers to the emitting run_id and verifying via gh api) deferred.

- (P1 #2) Move paged-at marker emission to a dedicated post-Slack step
  (`Persist Slack-paged marker`) gated on
  `success() && rc=='1' && should_page=='true'` so a failed Slack
  delivery never writes a paged-at timestamp. The rolling-issue update
  step keeps writing the IOC stamp marker (which represents the dedup
  decision input, NOT the Slack-delivery outcome — that's correct
  gating). The dedup reader already scans the most-recent paged-at
  marker across ALL bot-authored comments, so splitting the markers
  across two comments composes correctly with no parser change.
  Previously the paged-at marker was committed BEFORE the Slack page
  ran, so a failed Slack send would still record a paged-at timestamp
  and silently corrupt the dedup chain for up to 7 days (next
  IOC-grade run would believe Slack had paged, suppress its own page,
  and the standing IOC would stop alerting until the weekly re-page
  window expired).

  The new step has a `gh issue list` fallback for the rare case where
  the update step created a fresh rolling issue this run (so
  find-rolling-issue's output was empty); fail-OPEN warning if no
  issue is resolvable at all so a missing paged-at marker just forces
  the next run to page conservatively.

Verification: actionlint clean; YAML parses (11 steps in canonical
order: checkout → verify-tools → sweep → upload → find-rolling-issue
→ ioc-dedup → update-rolling-issue → slack-page → persist-paged-at →
slack-suppressed-notice → final-summary).

Refs: DEVOP-560, ce-code-review run 20260526-101810-4793bf13
findings #1 (anchor 100, security+adversarial), #2 (anchor 100,
correctness+adversarial+reliability), #5 (anchor 75, maintainability).
Co-authored-by: Cursor <cursoragent@cursor.com>
srt0422 added 8 commits May 30, 2026 07:42
review-fix-loop iteration 1
reviewer(s): thermo-nuclear (P1)
file: tabletop/2026-Q1-shai-hulud-eliza.md:5,58

The doc previously assigned both Facilitator and Incident lead to
"DevOps on-call," which collapses the test (the same person cannot
script the exercise and play the in-character lead — that defeats
the success criterion of running the response without facilitator
scaffolding). Pull them apart explicitly: facilitator is a non-on-call
DevOps engineer (typically the runbook author or last quarter's
facilitator); incident lead is whichever DevOps engineer is on-call
at exercise start time. Adds a dedicated Facilitator row to the §3
roles table for symmetry.
review-fix-loop iteration 1
reviewer(s): thermo-nuclear (P1)
file: tabletop/2026-Q1-shai-hulud-eliza.md:73-81,127-129,191-194

Sim-vs-real markers were sprinkled per-step (Phase 2 deprecate said
"we don't actually run it," Phase 4 publish said "this is acted out,"
Phase 4 send said "we don't actually send") while Phase 2 unpublish,
Phase 2 PyPI yank, and the Phase 2/3 `gh search` steps had no clarifier
at all. An executor under clock pressure has to guess each step.

Hoists a single rule into the §4 intro: read-only commands run for
real, state-changing commands are pasted-not-executed, default to sim
if unsure. Drops the per-step parentheticals and replaces them with a
brief back-reference where the rule is most likely to bite.

Same edit also adds a 5-line wall-clock layout to §4 intro so the
Phase 5 ("runs in parallel and concludes after debrief"), §4-intro
("Phases 5 and 6 happen after the clock stops"), and §5 debrief
("30 minutes after clock stops") timing claims line up in one place.
review-fix-loop iteration 1
reviewer(s): thermo-nuclear (P2)
file: tabletop/2026-Q1-shai-hulud-eliza.md:63,107-122,257-261

The doc described a "founder-approval gate" for full-package
unpublish/delete, citing SECURITY-RUNBOOK.md §5. The runbook §5
step 1 actually scopes that gate to "publisher and on-call agree,
in writing, in #security-alerts" — there is no founder-approval
gate in the runbook. The role-table break-silence exception for the
founder observer therefore could never fire (it referenced an
authority structure that doesn't exist in the runbook).

Aligns all four locations (role table, Phase 2 unpublish step,
Phase 2 success criterion, §8 facilitator notes) with the runbook's
actual gate. Returns the founder observer to a fully silent role
that matches the runbook's scoping (founders are not in the
authority chain for any in-incident action).
…ter PyPI checkbox

review-fix-loop iteration 1
reviewer(s): thermo-nuclear (P2 maintainability), ce-code-review (P2 correctness, P3 maintainability)
file: tabletop/2026-Q1-shai-hulud-eliza.md:111-116,134-138

Phase 2 ("Stop the bleed", 10-min budget) carried two checklist items
that didn't belong: a PyPI-yank checkbox annotated `N/A for this
scenario` (a dead-letter action that's also internally contradictory
with its own description), and a registry-repo `gh search` step that
duplicates the consumer-repo `gh search` already in Phase 3 (blast
radius). Future facilitators reading the dead-letter checkbox would
either skip-and-not-know-why or delete-and-lose-intent.

- Drops the PyPI checkbox from Phase 2's checklist; preserves the
  cross-registry muscle-memory observation as a §8 facilitator note
  where it belongs (it's a watch-for, not a step).
- Folds the registry-repo `gh search` into Phase 3's existing
  consumer-repo `gh search` bullet so blast-radius enumeration lives
  in one place.

Phase 2's checklist is now exclusively the deprecate + per-version
unpublish actions that match its 10-minute success criterion.
review-fix-loop iteration 1
reviewer(s): ce-code-review (P2 adversarial), thermo-nuclear (P2 doc)
file: tabletop/2026-Q1-shai-hulud-eliza.md:177-178,196-202

Two spots in the doc let the team coast through the exercise by
reading the script:

1. Phase 4 failure-mode bullet read "Lead reuses the bad version
   number (... the test is whether the team remembers without being
   told)" — and then told them, in the same sentence. Self-defeating
   as a recall check.
2. Phase 6 post-mortem template hard-coded the conclusion (the
   "16-hour blind spot is the most important finding"), turning the
   debrief into a fill-in-the-blank instead of a math-from-the-
   timeline exercise.

Rewrites both as non-leading observations: the facilitator is
watching for whether the lead articulates the version + non-collision
rationale; the post-mortem template tells the team to compute the
detection-to-mitigation latency and identify the single largest gap,
without naming what that gap will turn out to be.
review-fix-loop iteration 1
reviewer(s): ce-code-review (P3 security, P3 doc)
file: tabletop/2026-Q1-shai-hulud-eliza.md:33-34,180

- The fictional exfil endpoint named a real `*.workers.dev`
  subdomain (`eliza-telemetry.workers.dev`). Anyone can register a
  workers.dev subdomain, so the doc either implicates an existing
  owner or invites someone to register the name and grep for hits.
  Replaces with an RFC-2606/RFC-6761 reserved placeholder
  (`exfil.example.invalid`) and notes inline why.
- Phase 5 header said "clock stops at end of Phase 4; this runs in
  parallel and concludes after debrief," which contradicted the
  §4 intro's "Phases 5 and 6 happen after the clock stops." The
  new wall-clock layout (added earlier this iteration) defines the
  timing once; the header now just states T+30 onward + parallel
  with the debrief, leaving the rest to the canonical layout.
…le §3 paragraph

review-fix-loop iteration 2
reviewer(s): thermo-nuclear (P2 maintainability), ce-code-review (P2 correctness, P2 maintainability)
file: tabletop/2026-Q1-shai-hulud-eliza.md:71,107-114,118-122,257-262

Iteration 1 fixed the founder-gate language to align with the
runbook, but did so by renaming the quote in four places (§3 founder
cell, Phase 2 unpublish bullet, Phase 2 success block, §8 author
note) instead of consolidating it. That left two follow-up smells:

- The same gate quote ("publisher and on-call agree, in writing, in
  #security-alerts") appears verbatim in three locations; any future
  runbook revision now silently drifts this file in three places.
- §3 said "full-package unpublish/delete" while Phase 2 only enumerated
  "full-package delete" in its forbidden-action call-out, leaving the
  doc taxonomy inconsistent (in npm these are the same action, but the
  inconsistency forces the executor to flip back to §3 to confirm).

Defines the gate exactly once, in a new "Authority chain for this
scenario" paragraph immediately after the §3 roles table, and
clarifies inline that "full-package deletion" in npm is `npm unpublish`
without a version (so the unpublish/delete naming inconsistency
collapses). Phase 2 unpublish, Phase 2 success, and §8 author note
now reference §3 instead of re-quoting the gate.
…eline math

review-fix-loop iteration 2
reviewer(s): thermo-nuclear (P2 doc, P3 doc), ce-code-review (P3 correctness, P3 maintainability)
file: tabletop/2026-Q1-shai-hulud-eliza.md:34,176-180,196-203

Iteration 1's polish edits introduced three voice-and-clarity smells:

1. The §2 injected-scenario blockquote is read in-character at T+0 by
   participants. Iteration 1 dropped four lines of meta-rationale
   (RFC-2606/RFC-6761/`*.workers.dev`) into that blockquote, breaking
   the simulation voice for everyone except the doc reviewer.
   Moves the rationale to a §8 facilitator note where it belongs;
   the blockquote keeps just the URL.

2. The Phase 4 version-collision failure-mode used "yanked" — PyPI
   terminology — for an npm-only scenario. Switches to npm's
   "unpublished" and adds a one-line cross-registry aside so the
   wording stays correct without losing the broader awareness.

3. Phase 6's detection-to-mitigation bullet was internally
   contradictory ("compute the gap between publish and `ack`" vs.
   "identify the single largest latency"), and the meta-instruction
   ("do not pre-name the answer") sat inside the same bullet a lead
   might copy verbatim into the post-mortem document. Splits the
   bullet into a checkbox plus a clearly-marked nested facilitator
   note that names the timestamp set, asks for consecutive gaps
   (not one), and is unambiguously not template content.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-human-review shai-hulud Shai-Hulud supply-chain defense work

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.