docs(customization): add project knowledge base bootstrap recipe

[chris-buckley]

Description

Adds a docs-only how-to recipe for bootstrapping a project knowledge base: a
source-backed, repository-shaped memory for a project, engagement, product, or
workstream, kept as a separate repository and referenced from one or more
working repositories.

The page covers what a project KB is and when to use one, the
separate-repository model, a starter taxonomy (project, people, organizations,
systems, concepts, events, decisions, risks, deliverables, assets), the
event-to-entity update loop that keeps it current, how to point Copilot at
the KB with an instructions file, and maintenance guardrails for stale facts,
conflicting concepts, and misplaced files.

Follows from Discussion #1250 and the docs-first scope agreed on the issue.
Placement under docs/customization/ per the issue; happy to move it if
maintainers prefer another home.

Files changed:

• docs/customization/project-knowledge-base.md (new)
• docs/customization/README.md (File Index entry added, ms.date bump)

Related Issue(s)

Closes #1862

Type of Change

Code & Documentation:

• Documentation update

Testing

Docs-only change. Relying on the PR validation pipeline for markdown lint,
spell check, frontmatter, and link checks; will address any findings. Content
was checked by hand against the frontmatter, style, and table conventions of
the existing docs/customization/ pages.

Checklist

Required Checks

• Documentation is updated (if applicable)
• Files follow existing naming conventions
• Changes are backwards compatible (if applicable)
• Tests added for new functionality (not applicable, docs only)

Required Local Checks

• Local validation aggregate: npm run validate:local
• Documentation validation (if docs changed): npm run validate:docs
• Spell checking: npm run spell-check
• Link validation: npm run lint:md-links

Security Considerations

• This PR does not contain any sensitive or NDA information
• Any new dependencies have been reviewed for security issues (none added)
• Security-related scripts follow the principle of least privilege (not applicable)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.74%. Comparing base (0282ade) to head (1056dbe).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2546      +/-   ##
==========================================
- Coverage   82.75%   82.74%   -0.01%     
==========================================
  Files         155      155              
  Lines       20960    20960              
  Branches       13       13              
==========================================
- Hits        17345    17344       -1     
- Misses       3613     3614       +1     
  Partials        2        2              

Flag	Coverage Δ
docusaurus	94.44% <ø> (ø)
pester	86.18% <ø> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nikolaimak]

This is excellent guidance for a single-project KBs. For teams running multiple projects from one KB, I'd add two patterns: strict upstream-only lifecycle sync + deterministic scripts to prevent drift, and (2) dual-access layers—semantic search for agents and Obsidian-style graph navigation for humans. These ideas are coming from my experience maintaining a KB for the personal use.

1. It works well if the whole knowledge base is for one project, if there are more than 1, the lifecycle fields of a project start drifting very fast - because the KB is not a project management system. Possible mitigations:

• have really strict policy about updating the relevant fields automatically only from the upstream (e.g. AzDevops)
• use determenistic scripts to maintain these data
• store as little as possible about the LifeCycle of the project in the KB

2. KB can be useful both for agents and for humans:

• agents can access it with a semantic search tool over the .md files - like it is organized in OpenClaw - in my case I've added the KB to the index as an additional source. It will get needed once the KB becomes too big.
• humans can query the kb via data, or browse the folder in the repo directly. Additionally, they might benefit from organizing the knowledge as an obsidian vault - it is achieved by adding a frontmatter to each entity, and index files. Then they can use Obsidian as a frontend to view the KB and query/visualize it in interesting ways. For instance, here is how the Scout dev team organized it.