$ python agent.py "Why did staging deploys get stuck on September 30, and what changed?"
search ['postmortem September 30 staging deploys'] -> ['Postmortem: staging deploys stuck for 3 hours (2026-09-30)']
answer According to the document **"Postmortem: staging deploys stuck for 3 hours (2026-09-30)"**:

### Why staging deploys got stuck
A deploy job was killed during a node drain while holding the PostgreSQL advisory lock for staging. Because the lock belonged to the database session and the job's connection pooler kept that session open, the lock was never released. As a result, every staging deploy waited indefinitely at the "acquiring environment lock" step.

### What changed
* **Transaction-scoped locking:** Deploy jobs now acquire the lock using `pg_try_advisory_xact_lock` inside a transaction so the lock automatically releases when the transaction ends.
* **Alerting:** An alert was added to trigger if an environment lock is held for longer than 20 minutes.
* **Documentation follow-up:** A follow-up task was assigned to document how to manually release a stuck lock.

$ python agent.py "How do I rotate the release signing key, and when can I revoke the old one?"
search ['rotate release signing key revoke'] -> ['Runbook: rotate the release signing key']
answer Based on the document **Runbook: rotate the release signing key**, here are the steps to rotate the key and when to revoke the old one:

### How to Rotate the Key
1. **Create the new key:**
   ```bash
   shipctl keys create --purpose release-signing
   ```
   This stores the key under a new version while the old version stays valid.

2. **Promote the new key:**
   ```bash
   shipctl keys promote <new-version>
   ```
   From this point on, new releases will be signed with the new key.

---

### When to Revoke the Old Key
* **Wait 7 days** after promoting the new key to ensure every running release has been redeployed or verified with the new key.
* After 7 days, revoke the old key using:
  ```bash
  shipctl keys revoke <old-version>
  ```

> **Note:** Never delete the old version before completing the 7-day wait and revocation step, as any releases signed with it would fail verification and could not be rolled back to.

$ DOCS_TEAM=docs python agent.py "How do I rotate the release signing key?"
search ['rotate release signing key runbook', 'rotate release signing key', 'release signing key rotation'] -> []
answer I found no document on how to rotate the release signing key.

$ DOCS_TEAM=platform python agent.py "How do I rotate the release signing key?"
search ['how to rotate release signing key'] -> ['Runbook: rotate the release signing key']
answer According to the document **"Runbook: rotate the release signing key"**, the release signing key is kept in the secret store as `RELEASE_SIGNING_KEY` and should be rotated every 180 days (or immediately if it may have leaked).

Follow these steps to rotate it:

1. **Create the new key:** Run `shipctl keys create --purpose release-signing`. This creates and stores the key under a new version while the old version remains valid.
2. **Promote the new key:** Run `shipctl keys promote <new-version>`. From this point forward, new releases will be signed with the new key.
3. **Wait 7 days:** Allow 7 days so every running release is redeployed or verified with the new key.
4. **Revoke the old key:** Run `shipctl keys revoke <old-version>`.

*Note: Never delete the old key version before step 4, as releases signed with it would fail verification and could not be rolled back to.*

$ python agent.py "What is our on-call rotation for the docs site?"
search ['docs site on call rotation', 'docs site on-call runbook', 'on-call rotation', 'docs site', 'on-call', 'rotation', 'oncall', 'runbook', 'postmortem'] -> []
answer I found no document about an on-call rotation for the docs site.
