export declare const DEFAULT_INDEX_MD = "# Wiki Index\n\n> Automatically updated catalog of all wiki pages.\n\n## Entities\n<!-- pages about people, organizations, and products -->\n\n## Concepts\n<!-- pages about ideas, techniques, and patterns -->\n\n## Summaries\n<!-- source-document summaries -->\n\n## Comparisons\n<!-- comparative analyses -->\n\n## Overviews\n<!-- landscape views of topic areas -->\n\n## Analysis\n<!-- reasoned topics and syntheses -->\n\n## Validated Requests\n<!-- end-to-end requests validated by development reports -->\n\n## Requirements\n<!-- functional and non-functional requirements -->\n\n## Implementations\n<!-- validated technical summaries -->\n\n## Test Results\n<!-- test and validation results -->\n\n## Releases\n<!-- changelogs and releases -->\n";
export declare const DEFAULT_SCHEMA_MD = "# Wiki Schema and Conventions\n\n> Wiki format: 4. State and derived artifact versions are stored in `.knowledge-rail/state.json`.\n\n> This file defines the structure, workflows, and quality standards for this wiki.\n> Read it at the start of every session. Update it when conventions change.\n\n> MCP navigation: choose one of the eight `knowledge_*` domain tools directly and follow\n> the machine-readable `nextAction` returned by each operation. Normal project work starts\n> with `knowledge_context mode=\"task\"` and a concrete objective.\n\n---\n\n## Language\n\n**Write new wiki content in the language of the user's current request.**\nAn explicit language request overrides inference. When editing an existing page, preserve its language unless the user asks for a translation. If the user's language cannot be inferred safely, ask before writing instead of silently defaulting to English. This policy is open-ended: any natural language understood by the consuming model is valid.\n\nFrontmatter fields (`title`, `tags`, and so on) retain their technical formats (for example ISO dates and lowercase-with-hyphens tags). Model-facing instructions, stable identifiers, and generated control files remain in English; this does not constrain the language of human-readable wiki pages or deliverables.\n\n---\n\n## Directory Layout\n\n```\n{project-root}/\n\u251C\u2500\u2500 docs/                # Document plan: sources, outputs, and evidence state\n\u2502   \u251C\u2500\u2500 client/          # Client-provided sources\n\u2502   \u251C\u2500\u2500 transcripts/     # Transcripts and meeting notes\n\u2502   \u251C\u2500\u2500 reports/         # Validated development reports\n\u2502   \u251C\u2500\u2500 changelogs/      # Technical and functional changelogs\n\u2502   \u251C\u2500\u2500 normalized/      # Normalized Markdown source copies\n\u2502   \u251C\u2500\u2500 deliverables/    # Reviewed Markdown deliverables\n\u2502   \u251C\u2500\u2500 assets/          # Optional deliverable assets\n\u2502   \u2514\u2500\u2500 evidence-ir/     # Durable Evidence IR managed by KnowledgeRail\n\u251C\u2500\u2500 wiki/                # Canonical memory maintained by the agent\n\u2502   \u251C\u2500\u2500 SCHEMA.md        # This contract\n\u2502   \u251C\u2500\u2500 index.md         # Automatically regenerated index\n\u2502   \u251C\u2500\u2500 log.md           # Log append-only\n\u2502   \u251C\u2500\u2500 .knowledge-rail/ # Operational/derived state, not canonical knowledge\n\u2502   \u2514\u2500\u2500 <page-type>/     # Typed directories created on first use\n```\n\nThe typed wiki directories are: `entities`, `stakeholders`, `concepts`, `summaries`,\n`comparisons`, `overviews`, `analysis`, `meeting-notes`, `client-sources`,\n`candidate-requests`, `requests`, `requirements`, `implementations`, `tests`,\n`decisions`, `releases`, `risks`, `data-models`, `automations`, `integrations`\nand `api`. A directory appears only when the first page of that type is written.\n\n---\n\n## Required Frontmatter\n\nEvery wiki page MUST begin with YAML frontmatter. Paths shown as `wiki/...` below are\nproject-relative filesystem locations. For `knowledge_page`, pass a wiki-relative path such as\n`concepts/RAG.md`; a redundant leading `wiki/` is normalized to the canonical root. Never create\nanother directory named `wiki` anywhere below the canonical `wiki/` directory.\n\n```yaml\n---\ntitle: \"Human-readable page title\"\ntype: entity | stakeholder | concept | summary | comparison | overview | analysis | meeting_note | client_source | candidate_request | request | requirement | implementation | test_result | decision | release | risk | data_model | automation | integration | api\ntags: [tag1, tag2, tag3]\ncreated: YYYY-MM-DD\nupdated: YYYY-MM-DD\nsources: [\"docs/filename.md\", \"docs/other.md\"]\nclient: \"Client\"\nproject: \"Project\"\nrequest_id: \"REQ-001\"\nstatus: candidate | validated | implemented | tested | released | superseded | conflict\nauthority: context | client_input | validated_report | test_evidence | deliverable\n---\n```\n\n### Field Rules\n\n| Field     | Required | Notes                                                       |\n|-----------|----------|-------------------------------------------------------------|\n| `title`   | yes      | Human-readable, title case                                  |\n| `type`    | yes      | One of the supported page types below                       |\n| `tags`    | yes      | At least one tag; lowercase with hyphens                    |\n| `created` | yes      | ISO date of first creation                                  |\n| `updated` | yes      | ISO date of last modification \u2014 update on every edit        |\n| `sources` | yes      | Document files under `docs/` this page draws from; empty list `[]` if none. Cite code through Evidence IR code targets (`code://`), never in `sources`; import external documents with `knowledge_files action=\"normalize\"` |\n\n---\n\n## Page Types\n\n### `entity`\nA named real-world thing: person, organization, product, place.\n- File location: `wiki/entities/Name_Of_Entity.md`\n- Contains: description, key facts, relationships, timeline\n- Example: `wiki/entities/OpenAI.md`, `wiki/entities/Sam_Altman.md`\n\n### `stakeholder`\nA person, role, group, or organization that participates in or is affected by the project.\n- File location: `wiki/stakeholders/Stable_Stakeholder_Name.md`\n- Contains: identity, role, organization, responsibilities, influence, concerns, decisions, and transcript provenance\n- Optional frontmatter: `role`, `organization`, `email_domain`, and `affiliation` (`client`, `internal`, `partner`, or `unknown`)\n- `email_domain` contains only a normalized domain; never persist a complete participant email address or local part\n- Update the same page across sources when the identity is unambiguous. Current profile fields use the latest explicit observation while Evidence IR retains prior roles and affiliations with provenance\n- Keep uncertain identities separate and explicit\n- Example: `wiki/stakeholders/Jane_Doe.md`, `wiki/stakeholders/Finance_Approvers.md`\n\n### `concept`\nAn idea, technique, algorithm, or pattern.\n- File location: `wiki/concepts/ConceptName.md`\n- Contains: definition, how it works, use cases, trade-offs\n- Example: `wiki/concepts/Retrieval_Augmented_Generation.md`\n\n### `summary`\nA digest of a single source document.\n- File location: `wiki/summaries/SourceFileName.md`\n- Contains: key points, main arguments, notable quotes (with attribution)\n- Example: `wiki/summaries/attention_is_all_you_need.md`\n\n### `comparison`\nSide-by-side analysis of two or more entities or concepts.\n- File location: `wiki/comparisons/A_vs_B.md`\n- Contains: comparison table, pros/cons, when to use which\n- Example: `wiki/comparisons/GPT4_vs_Claude.md`\n\n### `overview`\nA landscape view of a topic area, linking to many other pages.\n- File location: `wiki/overviews/TopicArea.md`\n- Contains: taxonomy, key players, key concepts, recommended reading order\n- Example: `wiki/overviews/Large_Language_Models.md`\n\n### `analysis`\nA reasoned argument, opinion synthesis, or inference drawn from sources.\n- File location: `wiki/analysis/TopicAnalysis.md`\n- Contains: thesis, evidence (with citations), conclusion, open questions\n- Example: `wiki/analysis/Scaling_Laws_Implications.md`\n\n### Project delivery types\nUse these page types for consulting-project knowledge:\n- `meeting_note`: meeting transcript/summary and contextual notes; authority `context`.\n- `client_source`: client-provided document; authority `client_input`.\n- `candidate_request`: an emerging request that is not yet validated.\n- `request`: a request validated end-to-end by a development report.\n- `requirement`: a functional or non-functional requirement linked to a request.\n- `implementation`: a validated technical summary.\n- `test_result`: test and validation evidence.\n- `decision`: a technical or functional decision.\n- `release`: a changelog or release record.\n- `risk`: a risk, gap, or source conflict.\n- `data_model`, `automation`, `integration`, `api`: specialist details.\n\n### Stakeholder memory\n\nFor normalized `transcripts`, extract every explicitly identified participant or affected\nstakeholder as evidence targeted to a `stakeholder` page. For `client` and `reports` sources,\napply the same extraction when stakeholder evidence is explicitly present.\nUse one stable page per unambiguous person, role, group, or organization under `stakeholders/`\nand update that same page when later sources add or revise evidence. A stakeholder's role,\norganization, email domain, or affiliation can change: keep the newest explicit value as the\ncurrent profile and preserve older observations in the Evidence IR history.\n\nResolve the local user domain from `KNOWLEDGE_RAIL_USER_EMAIL`, then project-root\n`git config user.email`, otherwise use `unknown`. If an explicit participant email is present,\npersist only its domain: the same domain is `internal`, a different domain is `client`, and a\nmissing comparison is `unknown` unless the source explicitly declares `client` or `internal`;\nuse `partner` only when the source explicitly says so. The resolved local identity is cached for\nthe server lifetime, so restart KnowledgeRail after changing the environment variable or Git email. Record\nonly supported identity, role, organization, responsibilities, influence, concerns, decisions,\nand relationships. Do not infer private attributes, copy full email addresses, merge ambiguous\nidentities, or invent a stakeholder when none is present.\n\n---\n\n## Decision Memory\n\nDecision pages are living project knowledge, not an immutable approval ledger. Their purpose is to let people and\nagents recover what was chosen, why it was chosen, when it changed, and where it applies. Keep one bounded page per\ncoherent flow, component, or project context; never aggregate unrelated decisions into a catch-all page.\n\n### Retrieval and use\n\n1. Start normal project work with `knowledge_context mode=\"task\"`.\n2. Inspect the title, heading, retrieval reason, and `changeImpact.decisions` relation before reading decision content.\n3. Materialize only the exact decision resource link that matches the objective. Prefer its selected passage URI; when\n   no passage can be resolved reliably, reading that one bounded page is correct after relevance has been established.\n4. Do not open every returned decision, scan the whole `decisions/` directory, or load unrelated decision history.\n5. If no matching decision exists, return no decision context. Absence is normal and is not a coverage gap.\n6. If the one-page fallback is truncated, issue a targeted decision query for the missing section or report the limit;\n   never compensate with a directory-wide page dump. Before an update, do not overwrite a page whose relevant current\n   sections and history could not be reread; use an exact targeted edit/read or report the limit.\n7. If two decisions match the same context and conflict, materialize only that minimum conflicting set and surface the\n   contradiction instead of silently selecting the higher-ranked result.\n8. Briefly remind the user of an applicable prior choice and rationale only when it constrains or clarifies the current work.\n9. Treat a prior decision as context, not as unquestionable authority; surface conflicts or stale evidence explicitly.\n\n### Capture threshold\n\nRecord a decision only after a durable project choice is clearly accepted by the user or made concrete by an authorized\nimplementation task. Do not record proposals, unresolved options, incidental reversible edits, raw conversation,\nhidden chain-of-thought, secrets, or consent inferred from silence. If no durable decision arose, write nothing.\n\nBefore creating a page, reuse a relevant decision returned by task context or run a targeted search restricted to\n`page_types=[\"decision\"]`. Read the matching page immediately before changing it. Update the existing page only when\nthe flow/component/context is the same; create a separate page for a different context. This keeps one canonical,\ncurrent account of each scoped choice, avoids duplicate ADRs, and keeps retrieval passages small and precise.\n\n### Recommended decision page\n\n- **Context**: the exact flow, component, or request plus its problem, constraints, and boundaries. Put the same\n  identifying terms in the title, tags, links, and `request_id` when available so retrieval can select it precisely.\n- **Current decision**: the accepted choice stated precisely.\n- **Rationale**: concise user-facing reasons, not a transcript or model reasoning trace.\n- **Alternatives considered**: only material options actually discussed, with the reason they were not selected.\n- **Consequences**: positive, negative, and operational effects.\n- **Related evidence**: wiki links, source references, and code evidence that informed or implements the choice.\n- **Decision history**: dated, concise entries for the initial choice and each material change, including why it changed.\n\nOn update, preserve `created`, set `updated`, refresh the current sections, and append one history entry. When the\ncurrent choice changes, retain a concise account of the previous choice and state what changed and why; never silently\nerase its history. Then append one `knowledge_page action=\"append_log\" level=\"DECISION\"` entry naming the page and\nsummarizing the accepted change. The page is canonical; `log.md` is only the timestamped operational register. A log\nfailure does not roll back or invalidate a completed page update and may be retried; there is no cross-file transaction.\nIf wiki writes are not authorized, propose the exact update in the final response instead of mutating the wiki. Report\nany completed decision-page update once in the task summary; do not interrupt the discussion with repeated capture prompts.\n\n---\n\n## Cross-Reference Format\n\nUse `[[Page Name]]` for wiki-internal links. The page name matches the `title` field.\n\n```markdown\nSee also [[Retrieval Augmented Generation]] and [[OpenAI]].\n```\n\nStandard markdown links for external URLs:\n```markdown\n[Attention Is All You Need](https://arxiv.org/abs/1706.03762)\n```\n\n---\n\n## Ingest Workflow\n\n1. Normalize the source when necessary with `knowledge_files action=\"normalize\"`.\n2. Run `knowledge_ingest action=\"start\"` on the normalized file and follow its `nextAction`.\n3. The guided cycle is `next \u2192 apply_claims`: `apply_claims` records, links, validates, and synthesizes Evidence IR before updating canonical pages.\n   When a claim explains implemented behavior, find the relevant class or function with `knowledge_code` and pass its indexed URI as `target.code_resource_uri`. The knowledge page then exposes a direct code link backed by a captured anchor. Omit code targets for claims without relevant code evidence; check drift before relying on an older implementation claim.\n   `relatedEvidence` contains at most eight proposed code neighbors. Open and verify useful candidates before explicitly recording further claims; no proposal is automatically accepted. Call candidates are lexical, not compiler-proven.\n4. A segment without useful claims may be classified only with an allowed state and explicit reason.\n5. Use `knowledge_ingest action=\"source_status\"` to inspect coverage and gaps.\n6. Finalize a source only when the state proposes `action=\"finalize\"` after complete coverage.\n\n`index.md` is regenerated after every page mutation; record significant operations with `knowledge_page action=\"append_log\"`.\n\n---\n\n## Query Workflow\n\nWhen answering a question using the wiki:\n\n1. Call `knowledge_context mode=\"task\"` with the appropriate intent and a concrete objective; compact response detail is the default.\n2. Use `mode=\"search\"` or `mode=\"graph\"` only for targeted diagnostics, not as a mandatory chain.\n3. Materialize only relevant resource links, including applicable entries from `decisions` and `changeImpact.decisions`.\n   For source changes, pass repository-relative files in `changed_paths`. Inspect `changeImpact.codeRoots`, `codeRelations` and `codeWikiPages` as bounded candidates from the existing code index; open only pertinent links and verify current code. Lexical call/reference edges do not prove execution, and an empty result does not prove that a module is unused. If the index is missing or incompatible, refresh it explicitly as suggested by the GAP.\n4. If the response contains a widening `nextAction`, execute it with the suggested budget.\n5. Do not manually chain search, graph, and page dumps.\n6. If knowledge remains insufficient and no further widening is suggested, report `evidenceGaps` as GAP/unknown without hallucinating.\n\n---\n\n## Lint Checklist\n\nRun `knowledge_admin action=\"lint\"` periodically and fix:\n\n- **Orphan pages**: Pages with no inbound `[[links]]` \u2014 connect them to an overview or the index.\n- **Missing pages**: `[[links]]` referencing non-existent pages \u2014 create the page or remove the link.\n- **Broken markdown links**: Fix or remove.\n- **Stale `updated` fields**: If you edited a page, ensure `updated:` reflects today's date.\n- **Empty `sources`**: Every summary page must have at least one source.\n- **Nested wiki paths**: preview recovery with `action=\"lint\" force=true dry_run=true`; apply it\n  with `dry_run=false`. Pages are moved to canonical paths, relative links are updated, and any\n  destination collision blocks the entire repair without overwriting either page.\n\n---\n\n## Naming Conventions\n\n| Item          | Convention                         | Example                          |\n|---------------|------------------------------------|----------------------------------|\n| Entity pages  | Title_Case_With_Underscores.md     | `Sam_Altman.md`               |\n| Concept pages | Descriptive_Name.md                | `Chain_of_Thought.md`         |\n| Summary pages | Match source filename (lowercased) | `attention_is_all_you_need.md`|\n| Tags          | lowercase-with-hyphens             | `large-language-model`        |\n| WikiLinks     | Match the `title` field          | `[[Sam Altman]]`             |\n\n---\n\n---\n\n## Document Generation Workflow\n\nUse this editorial workflow to produce structured documents (functional specifications, architecture documents, and so on) from accumulated wiki knowledge without losing information in long contexts:\n\n1. **Plan as an editor**: call `knowledge_document_context action=\"plan\"` with `document_type` and optional `project_name`, `objective`, and `audience`. The tool returns the contract, sections, checklist, and coverage strategy.\n2. **Prepare targeted context packs**: for each section call `knowledge_document_context action=\"section\"` with `section_title`, a targeted query, optional `page_paths`, `page_types` filters, and budgets.\n3. **Verify code when the wiki is insufficient**: use `knowledge_code` and materialize only relevant `code://` resources. A raw scan is exclusively an explicit fallback that must be recorded.\n4. **Update the wiki before the document**: for gaps or inaccuracies, use `prepare_knowledge_update`, apply the draft with `knowledge_page action=\"write\"`, then `action=\"append_log\"`. Regenerate the context pack afterward.\n5. **Assign writers**: each writer produces one section using only its updated context pack and reports gaps instead of inventing content.\n6. **Assemble as an editor**: merge sections and remove duplication. Diagrams are optional; use only the representation explicitly selected by the user.\n7. **Save the draft**: call `knowledge_document action=\"write\"` with the filename, title, type, and complete content.\n8. **Review**: follow `nextAction` to `knowledge_document action=\"review\"` and resolve every blocker.\n9. **Recover post-review gaps**: use `knowledge_context` or `knowledge_code`, update the wiki, and regenerate the section.\n10. **Complete**: a passing review is terminal. Any conversion or branded rendering is owned by the user and their chosen tools.\n\n### Document types\n\n| Type | Description | Persona |\n|------|-------------|---------|\n| `functional_spec` | Complete functional project specification | Expert PM |\n| `functional_analysis` | Business processes, rules, requirements and expected outcomes | Business Analyst |\n| `technical_analysis` | Current state, proposed implementation and verification strategy | Technical Analyst |\n| `architecture_doc` | System architecture and technical decisions | Solution Architect / Tech Lead |\n| `project_brief` | Executive stakeholder summary | Business Analyst |\n| `user_manual` | Task-oriented guide for end users | Technical Writer |\n| `onboarding_guide` | Onboarding guide for new developers | Senior Developer |\n| `api_reference` | Endpoint and API-interface documentation | Backend Developer / API Specialist |\n| `adr` | Architecture Decision Record | Software Architect |\n| `runbook` | Operational, recovery, and rollback procedure | Site Reliability Engineer |\n| `test_plan` | Traceable test plan | Test Lead |\n| `incident_report` | Incident review and corrective actions | Incident Manager |\n| `release_notes` | Release and upgrade notes | Release Manager |\n| `custom` | Generic custom structure | Senior Technical Editor |\n\nThese are presets, not a closed taxonomy. Any non-empty document type is valid, and callers can provide their own required sections.\n\n### Storage\n\nDocuments are saved under `docs/deliverables/`. They are not wiki pages and **do not require frontmatter**.\n\n---\n\n### Document quality rules\n\n- Use the explicit output language when supplied; otherwise use the language of the user's current request. Translate human-facing template headings and prose instead of treating an English reference template as an English-output requirement.\n- Do not leave placeholders such as `[Describe...]`, `[Name]`, or `{{PROJECT_NAME}}` in the final document.\n- Do not invent details absent from the wiki; report gaps, assumptions, or data to confirm.\n- In client-facing documents, do not mention the wiki, context packs, agents, prompts, MCP tools, `src/`, `tests/`, `docs/` paths, or internal process details.\n- When the wiki is insufficient but code clarifies behavior, first update the wiki with a verified page or section and then regenerate the document.\n- Use tables and verifiable criteria when they aid validation.\n- Diagrams are optional and no representation is enforced when the choice is omitted. Use Mermaid or a relative external SVG/PNG only when the user selected that representation; do not use ASCII diagrams or monospace trees.\n\n*Schema version 4 \u2014 Update this file when conventions evolve.*\n";
export declare const DOCUMENT_PERSONAS: Record<string, string>;
export declare const DOCUMENT_TEMPLATES: Record<string, string>;
export declare function documentPersona(documentType: string): string;
export declare function documentTemplate(documentType: string): string | undefined;
//# sourceMappingURL=templates.d.ts.map