@c4a/context 0.6.0-alpha.1

package/package.json

@@ -0,0 +1,11 @@
+{
+  "name": "@c4a/context",
+  "version": "0.6.0-alpha.1",
+  "type": "module",
+  "dependencies": {
+    "yaml": "^2.5.1",
+    "zod": "^3.23.8"
+  },
+  "main": "./index.js",
+  "types": "./index.d.ts"
+}

package/phases.d.ts

@@ -0,0 +1,169 @@
+import { type EntityStatus, type FileCaptureProcessorDefinition, type KnowledgeCollection, type MarkdownTransform, type PackageKind, type PackageSelectDefinition, type DocumentMainlineCollection } from "./contracts.js";
+import { DOCUMENT_COMPILE_ACTION_SCHEMA_VERSION } from "./documentEvidence.js";
+import type { DocumentSourceDefinition, DocumentSourceType, FileSourceDefinition, FileSourceReference, LarkSourceDefinition, LarkSourceReference, RepoProjectSourceDefinition, SourceCollectionReference, SourceDefinition } from "./sources.js";
+export type PhaseResourceReference = {
+    kind: "source";
+    source: SourceDefinition | SourceCollectionReference;
+} | {
+    kind: "source.snapshot";
+    source: DocumentSourceDefinition;
+    sourceType: DocumentSourceType;
+    path: string;
+} | {
+    kind: "unapproved.entities";
+    path: string;
+    collection?: KnowledgeCollection;
+    status?: EntityStatus;
+} | {
+    kind: "unapproved.structure";
+    path: "unapproved/structure.yaml";
+    profileCollection?: DocumentMainlineCollection;
+    status?: "draft" | "confirmed" | "frozen";
+} | {
+    kind: "knowledge.collection";
+    path: string;
+    collection: KnowledgeCollection;
+    status: "approved";
+} | {
+    kind: "knowledge.approved";
+    path: "knowledge";
+    select?: PackageSelectDefinition;
+} | {
+    kind: "package.template";
+    path: string;
+} | {
+    kind: "review.payload";
+    path: string;
+} | {
+    kind: "dist.package";
+    path: string;
+    packageName: string;
+    packageKind: PackageKind;
+};
+export type ContextPhaseContext = {
+    ensureSources: (options?: {
+        source?: SourceDefinition;
+    }) => Promise<void>;
+    extract: {
+        ts: (options: ExtractTsPhaseDefinition) => Promise<void>;
+    };
+    review: {
+        html: (options: ReviewValidityPhaseDefinition) => Promise<void>;
+    };
+};
+export type ContextPhase = (ctx: ContextPhaseContext) => unknown | Promise<unknown>;
+export type ExtractTsPhaseDefinition = {
+    kind: "phase.extract.ts";
+    id: string;
+    reads: readonly PhaseResourceReference[];
+    writes: readonly PhaseResourceReference[];
+    source: RepoProjectSourceDefinition;
+    collection: "codegraph";
+    include: readonly string[];
+    exportedOnly: boolean;
+    transform?: MarkdownTransform | readonly MarkdownTransform[];
+    out: {
+        kind: "codegraph-entities";
+        candidateFile: string;
+        approvedPagesDir: string;
+        initialStatus: "draft";
+    };
+};
+export type CaptureFilePhaseDefinition = {
+    kind: "phase.capture.file";
+    id: string;
+    reads: readonly PhaseResourceReference[];
+    writes: readonly PhaseResourceReference[];
+    source: FileSourceDefinition | FileSourceReference;
+    processors?: readonly FileCaptureProcessorDefinition[];
+};
+export type CaptureLarkPhaseDefinition = {
+    kind: "phase.capture.lark";
+    id: string;
+    reads: readonly PhaseResourceReference[];
+    writes: readonly PhaseResourceReference[];
+    source: LarkSourceDefinition | LarkSourceReference;
+};
+export type AlignProsePhaseDefinition = {
+    kind: "phase.align.prose";
+    id: string;
+    reads: readonly PhaseResourceReference[];
+    writes: readonly PhaseResourceReference[];
+    source: DocumentSourceDefinition;
+    sourceType?: DocumentSourceType;
+    collection: DocumentMainlineCollection;
+};
+export type CompileProsePhaseDefinition = {
+    kind: "phase.compile.prose";
+    id: string;
+    reads: readonly PhaseResourceReference[];
+    writes: readonly PhaseResourceReference[];
+    source: DocumentSourceDefinition;
+    sourceType?: DocumentSourceType;
+    collection: DocumentMainlineCollection;
+    schemaVersion: typeof DOCUMENT_COMPILE_ACTION_SCHEMA_VERSION;
+};
+export type ReviewValidityScope = {
+    kind: "collection";
+    collection: KnowledgeCollection;
+} | {
+    kind: "all";
+};
+export type ReviewValidityPhaseDefinition = {
+    kind: "phase.review.validity";
+    id: string;
+    reads: readonly PhaseResourceReference[];
+    writes: readonly PhaseResourceReference[];
+    collection?: KnowledgeCollection;
+    scope: ReviewValidityScope;
+    status: "draft";
+    payload: string;
+    decisions: readonly ["approved", "rejected"];
+};
+export type CustomPhaseDefinition = {
+    kind: "phase.custom";
+    id: string;
+    reads: readonly PhaseResourceReference[];
+    writes: readonly PhaseResourceReference[];
+    run: ContextPhase;
+};
+export type PhaseDefinition = ExtractTsPhaseDefinition | CaptureFilePhaseDefinition | CaptureLarkPhaseDefinition | AlignProsePhaseDefinition | CompileProsePhaseDefinition | ReviewValidityPhaseDefinition | CustomPhaseDefinition;
+export declare function mdxJsonDocs(options?: {
+    include?: readonly string[];
+    documentExtensions?: readonly string[];
+    routeMetadataFile?: string;
+}): FileCaptureProcessorDefinition;
+export declare const captureFile: (definition: {
+    source: FileSourceDefinition | FileSourceReference;
+    processor?: FileCaptureProcessorDefinition;
+    processors?: readonly FileCaptureProcessorDefinition[];
+}) => CaptureFilePhaseDefinition;
+export declare const captureLark: (definition: {
+    source: LarkSourceDefinition | LarkSourceReference;
+}) => CaptureLarkPhaseDefinition;
+export declare const alignProse: (definition: {
+    source: DocumentSourceDefinition;
+    collection: DocumentMainlineCollection;
+}) => AlignProsePhaseDefinition;
+export declare const compileProse: (definition: {
+    source: DocumentSourceDefinition;
+    collection: DocumentMainlineCollection;
+}) => CompileProsePhaseDefinition;
+export declare const extractTs: (definition: {
+    source: RepoProjectSourceDefinition;
+    collection: "codegraph";
+    include?: readonly string[];
+    exportedOnly?: boolean;
+    transform?: MarkdownTransform | readonly MarkdownTransform[];
+}) => ExtractTsPhaseDefinition;
+export declare const reviewValidity: (definition: {
+    collection: KnowledgeCollection;
+    payload?: string;
+} | {
+    scope: "all";
+    payload?: string;
+}) => ReviewValidityPhaseDefinition;
+export declare const customPhase: (id: string, run: ContextPhase, io?: {
+    reads?: readonly PhaseResourceReference[];
+    writes?: readonly PhaseResourceReference[];
+}) => CustomPhaseDefinition;

package/sources.d.ts

@@ -0,0 +1,138 @@
+export type SourceType = "repo" | "file" | "lark";
+export type DocumentSourceType = Extract<SourceType, "file" | "lark">;
+export declare const DEFAULT_REPO_SOURCES_REGISTRY_PATH = "sources/repo/index.yaml";
+export declare const DEFAULT_FILE_SOURCES_REGISTRY_PATH = "sources/file/index.yaml";
+export declare const DEFAULT_LARK_SOURCES_REGISTRY_PATH = "sources/lark/index.yaml";
+export type RepoSourceDefinition = {
+    kind: "source.repo";
+    id: string;
+    name: string;
+    local?: string;
+    subpath?: string;
+    materializedAt: string;
+    git: {
+        remote: string;
+        ref: string;
+    };
+};
+export type FileSourceDefinition = {
+    kind: "source.file";
+    id: string;
+    name: string;
+    local?: string;
+    materializedAt: string;
+    include?: readonly string[];
+    snapshot?: {
+        manifest: string;
+    };
+};
+export type LarkSourceDefinition = {
+    kind: "source.lark";
+    id: string;
+    name: string;
+    materializedAt: string;
+    url?: string;
+    docToken?: string;
+    wikiToken?: string;
+    title?: string;
+    snapshot?: {
+        manifest: string;
+    };
+};
+export type TypedSourceReference<TType extends SourceType = SourceType> = {
+    kind: "source.ref";
+    type: TType;
+    name: string;
+    materializedAt: string;
+};
+export type RegistrySourceReference = {
+    kind: "source.ref";
+    name: string;
+    materializedAt: string;
+};
+export type SourceReference<TType extends SourceType = SourceType> = TypedSourceReference<TType>;
+export type RepoSourceReference = RegistrySourceReference | TypedSourceReference<"repo">;
+export type FileSourceReference = RegistrySourceReference | TypedSourceReference<"file">;
+export type LarkSourceReference = RegistrySourceReference | TypedSourceReference<"lark">;
+export type DocumentSourceReference = FileSourceReference | LarkSourceReference;
+export type SourceCollectionReference<TType extends SourceType = SourceType> = {
+    kind: "source.collection";
+    type: TType;
+};
+export type RepoSourceRegistryEntry = {
+    id: string;
+    name: string;
+    local?: string;
+    subpath?: string;
+    materializedAt: string;
+    remote: string;
+    ref: string;
+};
+export type FileSourceRegistryEntry = {
+    id: string;
+    name: string;
+    local?: string;
+    materializedAt: string;
+    include?: readonly string[];
+    snapshot?: {
+        manifest: string;
+    };
+};
+export type LarkSourceRegistryEntry = {
+    id: string;
+    name: string;
+    materializedAt: string;
+    url?: string;
+    docToken?: string;
+    wikiToken?: string;
+    title?: string;
+    snapshot?: {
+        manifest: string;
+    };
+};
+export type RepoSourcesRegistry = {
+    kind: "sources.registry.repo";
+    registryPath: string;
+    absolutePath: string;
+    repos: readonly RepoSourceRegistryEntry[];
+};
+export type SourcesRegistry = {
+    kind: "sources.registry";
+    registryPaths: {
+        repo: string;
+        file: string;
+        lark: string;
+    };
+    absolutePaths: {
+        repo: string;
+        file: string;
+        lark: string;
+    };
+    repos: readonly RepoSourceRegistryEntry[];
+    files: readonly FileSourceRegistryEntry[];
+    larks: readonly LarkSourceRegistryEntry[];
+};
+export type LoadSourcesRegistryOptions = {
+    rootDir?: string;
+    registryPath?: string;
+    repoRegistryPath?: string;
+    fileRegistryPath?: string;
+    larkRegistryPath?: string;
+};
+export type SourceDefinition = RepoSourceDefinition | FileSourceDefinition | LarkSourceDefinition | RegistrySourceReference | SourceReference;
+export type DocumentSourceDefinition = FileSourceDefinition | LarkSourceDefinition | DocumentSourceReference;
+export type RepoProjectSourceDefinition = RepoSourceDefinition | RepoSourceReference | SourceCollectionReference<"repo">;
+export type ProjectSourceDefinition = SourceDefinition | SourceCollectionReference;
+export declare function source(name: string): RegistrySourceReference;
+export declare function source(name: string, options: {
+    type: "repo";
+}): RepoSourceReference;
+export declare function source(name: string, options: {
+    type: "file";
+}): FileSourceReference;
+export declare function source(name: string, options: {
+    type: "lark";
+}): LarkSourceReference;
+export declare const loadSourcesRegistry: (options?: LoadSourcesRegistryOptions) => Promise<SourcesRegistry>;
+export declare const resolveSourceReference: (reference: RepoSourceDefinition | RepoSourceReference, registry: Pick<SourcesRegistry, "repos" | "registryPaths">) => RepoSourceDefinition;
+export declare const allSources: <TType extends SourceType>(type: TType) => readonly [SourceCollectionReference<TType>];

package/templates/package-templates/kb/AGENTS.md

@@ -0,0 +1,31 @@
+# {{displayName}}
+
+This package was generated from a Context knowledge workspace.
+
+Package: `{{packageName}}`
+Kind: `{{packageKind}}`
+Approved knowledge files: `{{knowledgeCount}}`
+
+## How To Use
+
+Use the Markdown files in this package as source-linked product and code
+knowledge. Prefer cited facts from the included knowledge pages over memory.
+
+The `skills/knowledge-query/SKILL.md` entry teaches agents how to navigate OKF
+indexes and cite copied OKF root directories, starting with
+`wikis/`. Customize template files before build when the package needs
+product-specific skills or routing rules.
+
+Selected OKF root directories such as `wikis/`, `guides/`, `rules/`, and
+`feats/` follow the C4A OKF Profile: OKF fields and C4A extension fields stay
+at the top level, and no `context` or `schema` field is emitted. Root mapping:
+`wikis/` maps from internal `codegraph`, `business`, `architecture`, `faq`, and
+`decision`; `guides/` maps from `sop` and `incident`; `rules/` maps from
+`product`, `standards`, and `test`; `feats/` maps from `feats`. Customize
+`wikis/index.md` before build to describe the package scope and query guidance;
+other selected OKF root indexes are generated unless this template supplies
+them.
+
+## Included Knowledge
+
+The approved Markdown files are copied into this package during `context build`.

package/templates/package-templates/kb/skills/knowledge-query/SKILL.md

@@ -0,0 +1,204 @@
+---
+name: knowledge-query
+description: Query the approved knowledge bundled with {{displayName}}.
+---
+
+# Knowledge Query
+
+Use this starter skill when the user asks about APIs, components, usage patterns,
+migration details, relationships, or source-linked facts covered by this
+package. Customize it before build if the package needs project-specific
+routing, terminology, or task workflows.
+
+## Non-negotiables
+
+- Structure first: start from OKF indexes and package structure before opening
+  individual pages.
+- Bundled knowledge pages are evidence cards. Do not answer from memory when a
+  copied page exists.
+- Cite every substantive claim with a page path and, when available, a
+  `context:section` id/source_ref.
+- Frontmatter summaries help route the query; reader-visible section content is
+  the evidence for factual answers.
+- If the package does not contain evidence for the requested fact, report a gap
+  instead of inferring from adjacent pages.
+- Do not treat direct grep over bundled OKF root directories as the primary
+  discovery path. Use it only as a fallback after indexes and page structure do
+  not identify a scope.
+
+## Evidence Shape
+
+Treat each opened knowledge page or package artifact as an evidence card:
+
+| Evidence field | Use |
+|---|---|
+| Page path | Citation handle and package-local identity. |
+| Frontmatter `title` / `description` / `node_type` / `tags` | Navigation and scope selection; not enough by itself for factual claims. |
+| `context:section` id / kind / source_ref metadata | Section citation handle and evidence boundary. |
+| Reader-visible section body | Primary evidence for factual answers. |
+| `context-build-inventory.json` `structure.edge_records` | Package-visible relationship evidence when typed edges are selected into this package. |
+| `context-build-inventory.json` | Package scope, counts, selected-by reasons, edge records, and build-time visibility evidence. |
+
+Frontmatter and indexes orient the search; reader-visible section content and
+source-backed edge records support claims. If a source_ref points to evidence
+that is not bundled, cite the approved knowledge section that reviewed it and avoid expanding
+beyond the packaged content.
+
+## Route By Intent
+
+| User intent | First move | Evidence move |
+|---|---|---|
+| Vague topic or unknown name | Open the package's OKF root index, usually `wikis/index.md`, then child indexes such as `wikis/<group>/index.md`. If the package includes other selected OKF roots such as `guides/` or `rules/`, use their indexes too. | Choose candidate pages by title, path, frontmatter, and index grouping. |
+| Process, runbook, SOP, incident, oncall, or troubleshooting question | Start from `guides/index.md` when present. These pages are mapped from internal `sop` and `incident` collections. | Use guide pages for steps, roles, operational context, incident timelines, and action items; cite sections rather than general procedure memory. |
+| Requirement, PRD, standard, spec, acceptance, or test scenario question | Start from `rules/index.md` when present. These pages are mapped from internal `product`, `standards`, and `test` collections. | Use rule pages for requirements, constraints, acceptance criteria, validation scenarios, and normative decisions. |
+| Specific entity/domain/action named | Open the matching page or nearest group index. | Read the page sections and source metadata. |
+| Relationship or impact question | Check `context-build-inventory.json` `structure.edge_records`, then related endpoint pages. | Cite typed edge evidence if available; otherwise cite page sections and mark relation gaps. |
+| Detail within a known page | Read that page's relevant `context:section` block. | Cite the section id/source_ref and quote or summarize only supported text. |
+| Coverage, gaps, or package scope | Check indexes and `context-build-inventory.json`. | Cite those package artifacts plus relevant pages. |
+
+Classify the user's question before opening pages. Structure queries take
+priority over keyword search:
+
+- Vague problem: show the relevant package structure first, then choose or ask
+  for a page/group scope. Do not answer from a package-wide text hit before
+  choosing the likely Node/page.
+- Explicit Node/page name: open the matching page or nearest group index. If
+  several pages normalize to the same name, show the candidates instead of
+  guessing.
+- Relationship/impact: inspect typed edges first, then read both endpoint
+  pages. If an edge is absent, page co-occurrence is not relationship evidence.
+- Detail inside a chosen scope: open only the relevant page sections. Use
+  search only to locate the section inside that page or group.
+- Coverage/gap/audit: use package artifacts first, then supporting pages.
+
+If the package structure returns multiple plausible pages, ask the user to pick
+or state the selection basis before answering. If no page or edge supports the
+requested fact, report a gap; do not broaden search until something vaguely
+matches.
+
+## Workflow
+
+1. Start with the relevant OKF root index, usually `wikis/index.md`, to
+   understand the package scope.
+2. Follow OKF directory indexes such as `wikis/<group>/index.md` before opening
+   pages. If the package includes other selected OKF roots, inspect their
+   indexes the same way.
+3. Open only the candidate pages needed for the question; avoid workspace-wide
+   reading unless the user asks for an inventory.
+4. Inspect frontmatter `node_type`, `sources`, and `context:section` comments to
+   confirm evidence boundaries.
+5. Answer from reader-visible section content. Use source_ref metadata as
+   citation and freshness context, not as a license to invent missing facts.
+6. Cite source-linked facts from the knowledge page when the answer depends on
+   code or reviewed knowledge.
+7. If the indexes and matching pages do not cover the request, return a
+   structured gap: requested topic, indexes/pages checked, and missing source
+   span or source_ref.
+
+For follow-up exploration, stay within the package boundary:
+
+- User asks about dependencies or impact: inspect `context-build-inventory.json`
+  `structure.edge_records` and the endpoint pages.
+- User asks for full detail after a partial answer: continue within the same
+  page or its child index before expanding outward.
+- User asks for a specific feature or behavior: use exact terminology,
+  bilingual terms, product aliases, API names, flags, and error strings from the
+  question to locate a section, then answer from the section body.
+- User mentions another page through a referenced edge or section link: open it
+  only if the relationship question requires it or the user asks to drill down.
+- Do not auto-open every related page, edge endpoint, or search hit just because
+  it is present.
+
+## Search Fallback
+
+Use text search only after the structure path above fails to identify a scope.
+
+- Search with exact product names, API names, bilingual terms, aliases, and
+  error strings from the user's question.
+- Prefer scoped search under a likely group/page over a package-wide scan.
+- A search hit is only a lead. Open the containing page/section and answer from
+  the section body, not from the hit line alone.
+- If search returns only unrelated pages, report the gap instead of broadening
+  until something vaguely matches.
+
+Search is keyword-literal, so use deliberate terms:
+
+- mix Chinese and English names when both may appear in the package;
+- include version numbers, API names, config keys, command flags, and exact
+  error strings when the user provides them;
+- try aliases and synonyms only to locate a candidate page, not to justify a
+  claim;
+- after a search hit, return to structure: identify the page, section, and
+  evidence boundary before answering.
+
+Do not use search for relationship or impact claims when a typed edge is
+available. Relationship answers should cite the edge first; search can only
+find endpoint details.
+
+## Citation Shape
+
+Use compact citations keyed to package artifacts:
+
+```text
+Page identity/title:      <claim> [<okf-root>/path/page.md]
+Section claim:            <claim> [<okf-root>/path/page.md#section-id]
+Source-backed detail:     <claim> [<okf-root>/path/page.md#section-id, source_ref]
+Relationship/edge:        <claim> [context-build-inventory.json#structure.edge_records edge:<type>]
+Package coverage/gap:     <claim> [context-build-inventory.json]
+```
+
+If several sections support the same claim, cite the strongest one or two and
+explain what each supports. Do not list citations without tying them to claims.
+
+For relationship answers, cite the typed edge when present and then cite endpoint
+sections for the facts about each endpoint. If no edge exists, do not infer a relationship from co-occurrence; say that the package lacks a source-backed relationship edge and cite any weaker page-level evidence separately.
+
+Use citation scope conservatively:
+
+- Page identity/title claims can cite the page path.
+- Factual behavior, constraints, examples, warnings, and usage claims need a
+  `context:section` citation when available.
+- Package coverage or known-limit claims need `context-build-inventory.json`
+  and/or the checked indexes/pages.
+- `source_ref` metadata names the reviewed evidence boundary, but the source
+  body may not be bundled. Do not invent source text that is not present in the
+  packaged knowledge page.
+
+## Gap Shape
+
+When the package lacks evidence, say so explicitly:
+
+```text
+Gap: this package did not return evidence for <missing point>.
+Checked: <indexes/pages/artifacts>.
+Next useful source need: <source, page, or source_ref if known>.
+```
+
+Do not fill the gap from general product knowledge, previous conversations, or
+raw source files outside this package.
+
+If the likely cause is that source material was captured but not approved into
+this package, say that the packaged knowledge does not include it. Do not tell
+the user it is false; distinguish "not evidenced here" from "not true."
+
+## Knowledge Boundary
+
+- The bundled OKF root directories, usually including `wikis/`, are the source
+  of truth for this skill.
+- OKF root mapping: `wikis/` maps from internal `codegraph`, `business`,
+  `architecture`, `faq`, and `decision`; `guides/` maps from `sop` and
+  `incident`; `rules/` maps from `product`, `standards`, and `test`; `feats/`
+  maps from `feats`.
+- Bundled OKF root directories follow the C4A OKF Profile.
+- Prefer OKF indexes, `context-build-inventory.json`, package manifests when
+  present, build inventory, and page source span metadata over raw text search.
+- Do not rely on memory when a knowledge page exists.
+- Do not claim the package is complete; it only contains approved knowledge that
+  was selected by the Context workspace.
+- If the package lacks project-specific instructions, state that the default
+  skill is a generic query entry and report gaps instead of inventing workflow
+  guidance.
+
+## Included Knowledge
+
+Approved knowledge files: `{{knowledgeCount}}`

package/templates/package-templates/kb/wikis/index.md

@@ -0,0 +1,43 @@
+---
+type: Knowledge Bundle
+title: "{{displayName}}"
+description: "Approved knowledge bundle generated from a Context workspace."
+tags:
+  - context
+  - knowledge-base
+timestamp: "{{knowledgeTimestamp}}"
+resource: "context://package/{{packageName}}/wikis"
+package: "{{packageName}}"
+package_kind: "{{packageKind}}"
+knowledge_count: {{knowledgeCount}}
+---
+
+<!-- context:template
+This file is a starter template. It is rendered by `context build` and copied to
+`dist/<package-name>/wikis/index.md`.
+
+Template comments that start with `context:template` are removed from build output.
+Read the template variable guide before customizing:
+node_modules/@c4a/context/docs/reference/template-variables.md
+
+Customize this file before calling the package usable. Add the bundle scope,
+intended readers, recommended reading order, known gaps, product scenarios,
+or task-focused entry sections. The default root index lists only the
+next-level directories; context build generates directory-level index.md
+files below it.
+-->
+
+# {{displayName}}
+
+This knowledge bundle contains `{{knowledgeCount}}` approved knowledge page(s).
+Use this index as the entry point, then open the linked knowledge pages for source-linked details.
+
+## Contents
+
+{{knowledgeGroupsMarkdown}}
+
+## How To Use
+
+- Start from the directory list above, then open child indexes and linked knowledge pages for source-linked details.
+- Use `skills/knowledge-query/SKILL.md` when this bundle is installed as an agent knowledge package.
+- Customize `src/package-templates/kb/wikis/index.md` before build to add bundle scope, known gaps, project-specific reading paths, or task entry points.

package/templates/package-templates/llms/llms.txt

@@ -0,0 +1,9 @@
+# {{packageName}}
+
+Generated by Context.
+
+Package kind: {{packageKind}}
+Approved knowledge files: {{knowledgeCount}}
+
+{{knowledge}}
+