# ADR-001: Introduce a PRODE Wiki for Production Engineering Operational Memory ## Status Proposed ## Date 2026-07-01 ## Context Production engineering work in this repository is increasingly agent-assisted. The current production engineering skill defines a strong evidence-first workflow: - fetch the Linear ticket before reading source code - collect live evidence from Sentry, AWS/CloudWatch, vendor/integration sources, support context, release metadata, and production read-only DB checks - route bounded investigation specialists - classify the issue from evidence - implement only after the evidence gate - hand off through Linear and PR comments - monitor after merge That workflow is deliberately conservative. It prevents agents from guessing from code before understanding production behaviour. It also creates structured outputs: ticket snapshots, specialist findings, evidence bundles, classification results, PR handoffs, and post-merge monitor results. Those outputs are valuable beyond a single ticket. They capture: - known failure modes - useful Sentry tags and payload shapes - CloudWatch log groups and query patterns - safe read-only production DB query recipes - release/deploy correlation methods - vendor-specific error and retry behaviour - false leads that wasted time - fix patterns that worked - fix patterns that did not work - approval boundaries and escalation rules Today, that knowledge is scattered across Linear tickets, PRs, comments, local skill files, and individual agent context. Future humans and agents have to rediscover it. This causes repeated investigation cost and increases the chance of stale assumptions. The "LLM Wiki" idea popularised by Andrej Karpathy is a lightweight pattern for maintaining an LLM-readable knowledge base in structured markdown. The useful part for this repo is not a generic wiki. It is the discipline of keeping operational knowledge as plain-text, schema-guided, source-backed pages that agents can read, update, lint, and cross-link. For PRODE, this should become a **PRODE Wiki**: a curated operational memory layer for production engineering. ## Decision Introduce a repository-local PRODE Wiki under `docs/prode-wiki/`. The PRODE Wiki will be a structured markdown knowledge base for production engineering operational memory. It will be maintained from completed production engineering runs, not used as primary proof for active incidents. The PRODE Wiki will: - guide investigation by surfacing known failure modes, query recipes, service maps, vendors, and prior incident patterns - preserve source-backed learnings from Linear tickets, PRs, evidence bundles, and post-merge monitors - help agents choose the right specialists and evidence pivots faster - provide implementation-independent context for humans and agents - explicitly distinguish current live evidence from historical operational memory The PRODE Wiki will not: - replace live Sentry, AWS, DB, Linear, vendor, or release evidence - store raw secrets, tokens, direct personal contact details, payment identifiers, full DB rows, or full request/response payloads - auto-promote every run artifact into durable guidance - allow agents to make production mutations - act as an authoritative incident record when source systems disagree ## Goals The goal is to reduce repeated investigation cost while preserving evidence discipline. Specifically: 1. Make prior PRODE knowledge available before specialist routing. 2. Encode safe query recipes for Sentry, CloudWatch, DB read-replica, release/deploy, and vendor investigations. 3. Capture failure mode pages that explain known production symptoms and how to prove or disprove them. 4. Preserve false leads and negative controls so agents do not repeat weak investigations. 5. Improve PR handoffs by linking fixes to previous related incidents. 6. Give automated runners a safe place to write proposed learnings for human review. 7. Keep the current Linear-first evidence gate intact. ## Non-Goals This decision does not introduce: - a production incident management system - a replacement for Linear, Sentry, AWS, GitHub, or vendor dashboards - a general company wiki - a customer support knowledge base - an automated production remediation engine - a vector database or RAG service - automatic mutation of production systems - automatic publication of unreviewed learnings as durable policy The first version should be plain markdown in git. If retrieval needs later justify indexing, that should be a separate ADR. ## Proposed Directory Structure ```text docs/prode-wiki/ .gitignore README.md SCHEMA.md index.md log.md redacted-artifacts/ README.md ticket-summaries/ evidence-bundle-summaries/ pr-handoff-summaries/ post-merge-monitor-summaries/ systems/ invest-api.md auth-api.md notification-api.md cur8-mobile-prod.md cur8-client-prod.md failure-modes/ request-aborted.md user-cancelled.md vendor-timeout.md stale-mobile-version.md db-state-mismatch.md release-regression.md infra-capacity.md specialists/ sentry.md aws-cloudwatch.md db-read-replica.md vendor-integrations.md product-support-context.md release-deploy-correlation.md reproduction.md code-path.md review.md query-recipes/ sentry-release-correlation.md sentry-request-id.md cloudwatch-request-id.md cloudwatch-outbound-vendor-failures.md cloudwatch-version-error-counts.md db-user-investment-state.md db-transaction-state.md release-window-correlation.md vendors/ payments.md kyc.md banking.md broker.md notifications.md email.md sms.md analytics.md crm.md decisions/ noise-classification-rules.md approval-boundaries.md db-read-only-boundaries.md vendor-escalation-boundaries.md ``` `redacted-artifacts/` is for short, sanitized summaries and stable source references only. Unredacted production artifacts, full evidence bundles, complete Sentry payloads, complete CloudWatch logs, vendor payloads, support transcripts, and DB-derived row dumps must not be committed to git unless a separate human-approved storage decision explicitly allows it. `docs/prode-wiki/.gitignore` allowlists curated Markdown and blocks common export formats such as JSON, CSV, SQL, logs, HAR, spreadsheets, PDFs, and images. Do not bypass it with `git add -f` for production evidence. ## Core Concepts ### Source-Backed Operational Memory Every durable wiki page must cite where the knowledge came from: - Linear ticket ID - PR link - Sentry issue or event ID when applicable - AWS log group and query window when applicable - DB query recipe name, not sensitive result data - vendor/provider status page or provider correlation ID when safe - post-merge monitor result The wiki may summarize evidence, but it must not preserve unredacted sensitive payloads. ### Evidence Versus Memory The PRODE Wiki is memory. It helps agents ask better questions. It is not evidence for the current ticket. For every active PRODE ticket, the runner must still fetch fresh evidence from the current source systems. A wiki page can say: > This looks like the previous `request-aborted` pattern. Check Sentry mechanism, CloudWatch request lifecycle, and the negative control query. It cannot say: > This is request-aborted noise because the wiki says similar cases were noise. ### Candidate Learning An active run may propose a candidate learning. Candidate learnings should be written to the repository's existing learning inbox, `docs/learnings/inbox.md`, not directly merged into durable PRODE Wiki pages. PRODE Wiki learnings must include `destination: prode-wiki` so the existing `learning-framework` drain can route them into durable wiki pages or discard them. Example: ```markdown - 2026-07-01 | PRODE-1234 | symptom: mobile crash after stale release | root: stale app version emitted retained crash despite would_drop tag | fix: preserve crash, do not silence; document stale-version branch | destination: prode-wiki | tier?: failure-mode ``` Candidate learnings become durable pages only after review. ### Durable Guidance Durable guidance is reviewed, source-backed, and safe for future agents to rely on as investigation context. Durable pages must include: - summary - when to suspect this pattern - when not to suspect this pattern - required live evidence - safe queries - negative controls - remediation patterns - known false positives - source links - last verified date - confidence level - owner or review path ## Page Schema Every durable wiki page should use this frontmatter: ```yaml --- title: "Human-readable page title" kind: "system | failure-mode | specialist | query-recipe | vendor | decision" status: "draft | active | deprecated | superseded" owner: "production-engineering" applies_to_services: - "invest-api" symptom_tags: - "request-aborted" last_verified: "YYYY-MM-DD" next_review_due: "YYYY-MM-DD" reviewed_by: "human reviewer, PR, or learning-framework run" reviewed_at: "YYYY-MM-DD" confidence: "low | medium | high" sensitivity: "low | medium | high" sources: - "Linear PRODE-1234" - "PR #1234" - "Sentry ISSUE-ID" superseded_by: --- ``` Each page should then follow this structure: ```markdown # Page Title ## Summary One short explanation of what this page teaches. ## Use When Signals that make this page relevant. ## Do Not Use When Signals that rule this page out or require another path. ## Required Live Evidence Fresh evidence that must be fetched before making a claim. ## Investigation Recipe Ordered steps, including specialist routing and safe queries. ## Negative Controls Queries or checks that prevent false classification. ## Remediation Patterns Fix shapes that have worked, with caveats. ## Failure Modes Known ways this page can mislead an agent. ## Sources Links or IDs for source-backed history. ## Change Log Short dated updates. ``` ## Run Integration The PRODE workflow should integrate the wiki at four points. ### 1. After Linear Fetch, Before Specialist Routing Once the Linear ticket has been fetched and the evidence source is known, the coordinator may read the wiki index and relevant pages. Retrieval starts from `docs/prode-wiki/index.md`. The index must list every active page with its `kind`, `status`, `sensitivity`, `applies_to_services`, `symptom_tags`, `last_verified`, and `next_review_due`. A durable page is not active unless it is registered in the index. The coordinator should match the Linear ticket against the index first, then read only the smallest relevant page set. If no page matches, record `no relevant operational memory` and continue with live evidence. Allowed reads: - `docs/prode-wiki/index.md` - relevant `systems/*` - relevant `failure-modes/*` - relevant `specialists/*` - relevant `query-recipes/*` - relevant `vendors/*` - relevant `decisions/*` Blocked before evidence gate: - broad source-code reads - treating wiki claims as proof - adding durable wiki guidance during active diagnosis Output: - likely specialist routes - suggested queries - required negative controls - known approval boundaries - known false positives ### 2. During Evidence Bundle Creation The evidence bundle may reference relevant wiki pages under a separate `Operational memory consulted` section. Example: ```markdown ### Operational memory consulted - `failure-modes/request-aborted.md`: suggested checking client disconnect shape and CloudWatch lifecycle. - `query-recipes/cloudwatch-request-id.md`: used as the starting query. These pages informed the investigation route only. Classification is based on current live evidence below. ``` Wiki pages must not be cited in the classification evidence section. If wiki guidance changed the investigation route, state that separately under `Operational memory consulted`. ### 3. During PR Handoff The PR body may link relevant wiki pages if they help reviewers understand the fix. The PR must still include current evidence and verification output. ### 4. After Post-Merge Monitor When the post-merge monitor completes, the runner may write a candidate learning to `docs/learnings/inbox.md` with `destination: prode-wiki`. The candidate should include: - date - ticket ID - symptom - root cause - fix shape - verification result - post-merge monitor result - suggested destination page - sensitivity notes The runner should not directly rewrite active wiki pages unless the task is explicitly a documentation update. ## Specialist Integration ### Sentry Specialist Relevant wiki pages: - `specialists/sentry.md` - `query-recipes/sentry-request-id.md` - `query-recipes/sentry-release-correlation.md` - failure mode pages for the suspected classification Useful wiki content: - required tag fields - known project names - stale version handling - crash retention rules - negative controls for noise classifications ### AWS / CloudWatch Specialist Relevant wiki pages: - `specialists/aws-cloudwatch.md` - `query-recipes/cloudwatch-request-id.md` - `query-recipes/cloudwatch-outbound-vendor-failures.md` - `query-recipes/cloudwatch-version-error-counts.md` - `systems/invest-api.md` Useful wiki content: - canonical log groups - retired log groups to avoid - request lifecycle query shapes - version comparison query shapes - timeout and 5xx investigation patterns ### DB Read-Replica Specialist Relevant wiki pages: - `specialists/db-read-replica.md` - `decisions/db-read-only-boundaries.md` - safe query recipe pages Useful wiki content: - approved query style - redaction rules - entity identifiers that are safe to use - table-level gotchas - examples of narrow predicates DB specialist rules remain strict: - the canonical DB investigation boundary lives in `.agents/skills/prode-triage/references/specialists.md` - production read-only access is available for this workflow - `SELECT` only - prefer read replica - query recipes may include table names, column names, and placeholder predicates when needed for repeatability - query recipes must not include real customer IDs, payment identifiers, account numbers, tokens, request bodies, or copied result rows - narrow predicates based on IDs already present in persisted evidence - explicit `LIMIT` on row-returning queries - no `SELECT *` - no broad table scans - prefer counts, statuses, timestamps, and aggregate checks over full entity rows - no copied row output in Linear, PRs, wiki pages, or run summaries - query timeout guidance must be included in DB query recipes - no writes - no locks - no migrations - no backfills - no advisory lock calls - no direct personal contact details, payment identifiers, tokens, cookies, or full request bodies in output ### Vendor / Integration Specialist Relevant wiki pages: - `specialists/vendor-integrations.md` - `vendors/*` - `query-recipes/cloudwatch-outbound-vendor-failures.md` - `decisions/vendor-escalation-boundaries.md` Useful wiki content: - provider error taxonomies - retry and idempotency behaviour - webhook delivery patterns - incident/status page locations - escalation criteria - actions that require human approval ### Product / Support Context Specialist Relevant wiki pages: - `specialists/product-support-context.md` - relevant system and failure mode pages Useful wiki content: - how to convert support reports into time windows - screenshot and screen-name mapping - expected behaviour summaries - questions to ask when the report is incomplete ### Release / Deploy Specialist Relevant wiki pages: - `specialists/release-deploy-correlation.md` - `query-recipes/release-window-correlation.md` - `failure-modes/release-regression.md` Useful wiki content: - release tag conventions - app build versus backend deploy differences - feature flag rollout checks - stale version handling ### Code Path Specialist The code path specialist may use the wiki only after the evidence bundle exists. Relevant wiki pages: - system pages - failure mode pages - previous PR links Useful wiki content: - likely files or modules from previous incidents - known traps - test coverage gaps The wiki must not allow code-path investigation before the evidence gate. ## Write Policy ### Who Can Write Interactive agents may write: - ADRs when explicitly asked - candidate learnings to `docs/learnings/inbox.md` with `destination: prode-wiki` - wiki pages when explicitly asked to update docs Automated PRODE runners may write: - run artifacts outside the wiki - candidate learnings to `docs/learnings/inbox.md` with `destination: prode-wiki` Automated PRODE runners must not directly promote candidate learnings into active pages unless a future ADR explicitly allows that workflow. The existing `learning-framework` process owns candidate review, routing, promotion, and deletion of processed inbox lines. ### Review Path Candidate learnings should be reviewed at task boundaries through the existing `learning-framework` drain. Review should decide: - discard because it is too ticket-specific - merge into an existing page - create a new failure mode page - create a new query recipe - update a vendor page - update a specialist page - update an approval boundary decision page Promotion rules: - `draft` pages may be created by agents but must not be treated as durable guidance. - `active` pages require review through a PR or an explicitly recorded `learning-framework` review. - `reviewed_by`, `reviewed_at`, `next_review_due`, `sensitivity`, and `sources` are required before a page becomes `active`. - high-sensitivity pages require human review before becoming `active`. - automated agents may propose `last_verified` updates from post-merge monitors, but promotion of that update follows the same review path. Staleness rules: - if `next_review_due` is in the past, the page may still be read as historical memory - stale pages must be reported as stale in `READ_PRODE_WIKI` output - stale pages must not be used to raise investigation relevance without fresh corroborating evidence - if a stale page conflicts with live evidence, live evidence wins and the page should be marked for review ### Redaction Requirements Before writing any wiki content or candidate learning, run a redaction checklist and record the result in the candidate learning or PR description. Remove: - secrets - tokens - cookies - authorization headers - direct personal contact details - payment identifiers - full request/response bodies - full DB rows - complete stack traces containing sensitive payloads - unnecessary customer identifiers Use stable internal IDs only when needed for source traceability and when safe under repo policy. If redaction cannot be completed confidently, do not write the wiki update. Record a blocker in the run artifact or PR description and ask for human review. Redaction is enforced by two layers: - Existing gitleaks checks catch many secret-shaped values, but they do not reliably detect customer emails, investor names, account or entity IDs, balances, KYC data, or all production identifiers. They must not be treated as sufficient redaction coverage for PRODE Wiki content. - `scripts/prode-wiki-redaction-lint.sh` and `.github/workflows/prode-wiki-redaction.yml` provide a PRODE-specific lint for `docs/prode-wiki/**` and `docs/learnings/**`. This lint must run before seed pages or candidate learnings are promoted. It blocks non-curated artifact formats and common sensitive markers including emails, auth headers, bearer tokens, private-key headers, IBAN-like values, and UK sort-code-shaped values. The PRODE-specific lint is intentionally conservative and incomplete. A green lint result does not prove content is safe; it is a mandatory backstop plus a prompt for human review on medium- and high-sensitivity pages. ## Evidence Bundle Changes Add this optional section to the PRODE evidence bundle: ```markdown ### Operational memory consulted - Wiki pages: - Prior incidents: - Query recipes reused: - Known false positives checked: Note: operational memory informed the investigation route only. Current classification is based on live evidence. ``` Add this optional section to final handoff: ```markdown ### Candidate learning - Suggested wiki update: - Destination: - Sensitivity review: - Post-merge monitor result: ``` ## Automation Runner Changes The automation runner should add a `READ_PRODE_WIKI` activity after `FETCH_LINEAR` and before `ROUTE_SPECIALISTS`. Proposed state transition: ```text FETCH_LINEAR -> READ_PRODE_WIKI -> ROUTE_SPECIALISTS -> WAIT_FOR_EVIDENCE ``` `READ_PRODE_WIKI` input: - ticket ID - title - labels - redacted description excerpt - known evidence sources - service/project hints - time window - known vendor names - known request/customer/internal IDs when safe `READ_PRODE_WIKI` output: - pages read - suggested specialist routes - suggested query recipes - required negative controls - relevant prior incidents - investigation relevance - stale pages - skipped pages and reasons - gaps The activity must be read-only. Persist the full `READ_PRODE_WIKI` output as a run artifact. Linear and PR handoffs may include only a redacted summary of pages consulted and query recipes reused; prior incident titles, sensitive page names, and customer-specific context must stay in artifacts unless explicitly safe to disclose. After `POST_MERGE_MONITOR`, the runner may add `WRITE_CANDIDATE_LEARNING`. Proposed state transition: ```text POST_MERGE_MONITOR -> WRITE_CANDIDATE_LEARNING -> RUN_COMPLETE ``` `WRITE_CANDIDATE_LEARNING` output: - `docs/learnings/inbox.md` entry path - source ticket - source PR - source evidence bundle - sensitivity review result - suggested durable page This activity writes only to `docs/learnings/inbox.md` unless explicitly approved otherwise. Entries intended for the PRODE Wiki must include `destination: prode-wiki`. ## Alternatives Considered ### Keep Knowledge Only in Linear and PRs Pros: - no new documentation surface - source systems remain canonical - no additional review process Cons: - hard for agents to search consistently - prior incidents are not normalized - query recipes are buried in comments - repeated investigation cost stays high - false leads are rediscovered Rejected because production engineering relies on repeatable operational patterns, and those patterns need a curated layer. ### Store Everything in Notion or an External Wiki Pros: - richer editing UX - easier for non-engineers to read - permissions and comments may already exist Cons: - less reliable for local coding agents - harder to version with code changes - harder to enforce schema and linting - more risk of drift from repository skills - may require connector availability for every run Rejected for the first version. External docs can link to the PRODE Wiki later if needed. ### Use a Vector Database or RAG Service Immediately Pros: - semantic retrieval over many incidents - potentially better recall - can scale beyond markdown Cons: - more infrastructure - harder to audit exact context used by agents - risk of source-less or stale retrieval - premature before the schema stabilizes Rejected for the first version. Markdown should be sufficient until volume and retrieval pain prove otherwise. ### Let Automated Runs Directly Update Durable Wiki Pages Pros: - lower manual overhead - faster knowledge accumulation Cons: - high risk of encoding wrong conclusions - high risk of promoting ticket-specific context into general rules - harder to protect sensitive data - harder to distinguish candidate learning from accepted guidance Rejected. Automated runs may write candidate learnings only. ### Do Nothing Pros: - no implementation work - no maintenance burden Cons: - agents continue to rediscover known patterns - stale individual memory drives decisions - repeat incidents remain harder than necessary - operational knowledge remains unstructured Rejected because the PRODE workflow already creates the source material needed for a lightweight wiki. ## Consequences ### Positive - Faster specialist routing. - Better query reuse. - Better negative controls for noise classifications. - More consistent production DB read-only investigations. - Safer vendor/integration triage. - Better continuity between agents. - Less repeated debate about known production patterns. - Clearer distinction between evidence, memory, and policy. ### Negative - More markdown to maintain. - Requires review discipline. - Risk of stale pages if `last_verified` is ignored. - Risk of agents over-trusting historical patterns. - Requires careful redaction before writing learnings. ### Mitigations - Keep wiki reads after Linear fetch, not before. - Require live evidence for every active ticket. - Add `last_verified`, `next_review_due`, `confidence`, `sensitivity`, `status`, and `sources` metadata. - Keep candidate learnings in `docs/learnings/inbox.md` until reviewed by the existing learning framework. - Start advisory schema/redaction linting in Phase 1, then make it required after the wiki stabilizes. - Prefer small, focused pages over long narrative incident reports. ## Implementation Plan ### Phase 1: Skeleton and Rules Create: - `docs/learnings/inbox.md` if it is absent - `docs/prode-wiki/.gitignore` - `docs/prode-wiki/README.md` - `docs/prode-wiki/SCHEMA.md` - `docs/prode-wiki/index.md` - `docs/prode-wiki/log.md` - `docs/prode-wiki/redacted-artifacts/README.md` - `scripts/prode-wiki-redaction-lint.sh` - `.github/workflows/prode-wiki-redaction.yml` Update: - `.agents/skills/prode-triage/SKILL.md` - `.agents/skills/prode-triage/references/automation-runner.md` - `.agents/skills/prode-triage/references/specialists.md` - `learning-framework` routing docs, if needed, so `docs/learnings/inbox.md` entries with `destination: prode-wiki` can be promoted into the PRODE Wiki Add the rule: > Read PRODE Wiki pages only after fetching Linear. Use them to route investigation and choose queries. Never use them as proof for the current classification. Add the redaction rule: > No unredacted production artifacts are committed to git. Candidate learnings for the PRODE Wiki use `docs/learnings/inbox.md` with `destination: prode-wiki`. ### Phase 2: Seed High-Value Pages Seed pages that are immediately useful: - `specialists/sentry.md` - `specialists/aws-cloudwatch.md` - `specialists/db-read-replica.md` - `specialists/vendor-integrations.md` - `query-recipes/cloudwatch-request-id.md` - `query-recipes/cloudwatch-outbound-vendor-failures.md` - `query-recipes/db-user-investment-state.md` - `failure-modes/request-aborted.md` - `failure-modes/vendor-timeout.md` - `decisions/db-read-only-boundaries.md` Each seeded page should include `status: draft` until used and verified against a real ticket. ### Phase 3: Runner Integration Add runner states: - `READ_PRODE_WIKI` - `WRITE_CANDIDATE_LEARNING` Update evidence bundle and final handoff templates. Persist: - wiki pages read - query recipes reused - prior incidents considered - candidate learning output ### Phase 4: Review and Promotion Create a repeatable review workflow for `docs/learnings/inbox.md` entries with `destination: prode-wiki`. At task boundaries: - drain candidate learnings - merge into durable pages when appropriate - delete processed inbox lines - update `log.md` ### Phase 5: Required Linting Extend the Phase 1 lint once the wiki stabilizes. It should check: - required frontmatter fields - valid `kind` - valid `status` - `last_verified` format - `next_review_due` format - review metadata for active pages - missing source links - forbidden sensitive terms or full payload markers - broken wiki links The lint must keep blocking promotion of durable active pages that miss review metadata, source links, or redaction checks. ## Open Questions 1. Which production DB query recipes are safe enough to seed first? 2. Should vendor pages be generic initially, or should they map named providers once redaction rules are agreed? 3. Where should full evidence bundles live when they are too sensitive for git but need durable retention? 4. Is production DB access physically constrained to a read-only role, or is `SELECT`-only currently enforced only by workflow policy? 5. What customer, account, entity, and KYC identifier patterns should the redaction lint recognize? 6. What is the retention policy for stale or superseded operational memory? 7. What `next_review_due` interval should apply to high-sensitivity pages? ## Acceptance Criteria This ADR is implemented when: - `docs/prode-wiki/` exists with schema, index, log, `.gitignore`, and redacted artifact guidance - `docs/learnings/inbox.md` exists as the single candidate-learning inbox - PRODE Wiki candidate learnings use `docs/learnings/inbox.md` with `destination: prode-wiki` - the PRODE triage skill reads the wiki after Linear fetch and before specialist routing - the automation runner records wiki pages consulted - specialist routing can use wiki query recipes without treating them as proof - final handoff can write candidate learnings - candidate learnings are reviewed through the existing `learning-framework` process before promotion - sensitive data is explicitly blocked from durable wiki pages - `scripts/prode-wiki-redaction-lint.sh` and `.github/workflows/prode-wiki-redaction.yml` exist before seed pages are committed - active pages require review metadata, sensitivity metadata, source links, and `next_review_due` - DB read-only boundaries are documented in the wiki - at least five seed pages pass the schema/redaction checks ## Related Files - `.agents/skills/prode-triage/SKILL.md` - `.agents/skills/prode-triage/references/automation-runner.md` - `.agents/skills/prode-triage/references/specialists.md` - `docs/learnings/inbox.md` - `docs/prode-wiki/.gitignore` - `scripts/prode-wiki-redaction-lint.sh` - `.github/workflows/prode-wiki-redaction.yml` - `AGENTS.md` - `CLAUDE.md` ## Decision Owner Production engineering maintainers for this repository. ## Review Notes This ADR should be revisited after the first five PRODE tickets use the wiki. The review should answer: - Did the wiki reduce investigation time? - Did agents over-trust historical pages? - Were candidate learnings useful? - Were any redaction issues found? - Which pages became stale fastest? - Is markdown still enough, or is indexed retrieval justified?