Add the design spec for reaching strata-qa from Slack

[baonguyenNava]

What

Lands the approved design for answering Strata questions from a Slack channel, so the commits that follow can argue about code rather than architecture. No implementation yet.

Issue #30 built the Q&A engine and #39 deployed it, but #30 explicitly deferred "the Slack bot itself, or any other external caller/integration". This is the design for that deferred piece.

Closes #40

This targets baonguyenNava/30-strata-qa-cli (#38) rather than main, because everything the spec reasons from — strata-qa/NOTES.md, the deployed function's reserved concurrency, .dockerignore — exists only on that branch. Review the diff against #38; this lands in main behind it.

How

Two files.

docs/superpowers/specs/2026-07-27-strata-qa-slack-bot-design.md is the design. Its shape is forced by two facts already recorded in strata-qa/NOTES.md: Slack demands an HTTP 200 within 3 seconds against an answer that takes 9 to 90, and a question costs roughly 190,000 tokens, which is why the deployed function carries a reserved concurrency of 3. Those rule out both a synchronous design and a single shared function, since three simultaneous questions would occupy every slot and starve the acknowledgements behind them, and Slack's retries would then convert load into more spend.

So: a thin public gateway that verifies the Slack signature, acknowledges, and asynchronously invokes the existing function, which answers in-thread. Both deploy from the same image with different entrypoints, so they cannot drift to different commits, and the existing Function URL stays on AWS_IAM. The function that spends money is never reachable from the internet.

.dockerignore had a comment asserting that nothing under docs/superpowers was in git, which this PR makes false. The exclusion rule itself is unchanged; only the comment explaining it is.

Test plan

• python -m scripts.lint_manifest, python -m scripts.lint_docs, and python -m scripts.build_graph all pass (MANIFEST_OK, DOCS_OK 56 docs, GRAPH_OK 56 docs). The two GAP: lines about platform-cli template components are pre-existing and unrelated.
• build_graph leaves the tree clean, confirming the new spec sits outside the corpus the graph is built from and does not perturb docs/INDEX.md or docs/graph.json.
• The docs/superpowers rule in .dockerignore is unchanged, so the spec still stays out of the Lambda image and out of the retrieval agent's search space.
• Not run: npm test under strata-qa/, since no TypeScript changed in this PR. It becomes required as soon as the implementation lands on this branch.

Notes for reviewers

Review the spec, not just the diff. Once implementation starts, disagreeing with the architecture gets expensive, so this is the cheap moment to push back on the two-function split, the reaction-based progress signal, or the decision to fail closed on an empty channel allowlist.

This PR is deliberately a draft that will grow: the implementation commits land on this branch. Because the base is not the default branch, Closes #40 will not fire on merge — #40 stays open until someone closes it once the stack reaches main.

Three things in the spec are worth a reviewer's specific attention. The reserved replyTo field in handler.ts is deleted rather than kept, because a bare URL cannot carry the channel, thread, and message timestamp an in-thread reply needs, and it turned out to be a placeholder that guessed wrong. Retry deduplication uses Slack itself as the store, by treating an already_reacted response as proof the previous delivery succeeded, which avoids adding DynamoDB for one boolean. And a question dropped after 180 seconds of queueing leaves its progress reaction stuck with no explanation, which is an accepted v1 limitation rather than an oversight.

#40 carries four open questions that are not blocking for review but are blocking for implementation. The long pole is workspace-admin approval to install a Slack app at Nava, which is worth starting now rather than when the code is ready.

[baonguyenNava]

Note that I reviewed this plan. This plan is for if we decide that we want to have our Slack bot run through an AWS infrastructure and to run more deterministic code. It would also have very low cost, as we would be using a Lambda, which in itself has low cost, as well as running GPT-5.6 Luna. Typically, in my runs, each question is answered with $0.10 to $0.15 of spend. I believe that if our organization moves to limit cloud spending, then this would be an alternative that we could pursue to provide functionality that would come in at much lower cost.