Add project-knowledge structure and templates
- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People." - Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views. - Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation. - Updated scripts and prompts to reflect the new project-knowledge directory structure. - Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps. - Ensured all references in workflows and scripts point to the new project-knowledge paths.
This commit is contained in:
34
agent-memory/integrations/communication-sources.md
Normal file
34
agent-memory/integrations/communication-sources.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
type: agent-integration
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- communication
|
||||
- evidence
|
||||
---
|
||||
|
||||
# Communication Sources
|
||||
|
||||
Communication connectors extract evidence. The agent decides what to promote.
|
||||
|
||||
---
|
||||
|
||||
## Live Communication
|
||||
|
||||
Mattermost is the current live communication connector.
|
||||
|
||||
- Fresh output goes to `ai/inbox/mattermost-latest.md`.
|
||||
- Generated extraction artifacts stay under `scripts/mattermost/generated/`.
|
||||
- Failed syncs must not update project knowledge.
|
||||
- Latest-message requests must refresh Mattermost before answering.
|
||||
|
||||
---
|
||||
|
||||
## Historical Archive
|
||||
|
||||
Slack export import is the current historical archive connector.
|
||||
|
||||
- Archive evidence stays outside `project-knowledge/`.
|
||||
- Promote only durable project facts, people context, process rules, or historical architecture lessons.
|
||||
- Do not promote dated status details unless they explain current context.
|
||||
|
||||
34
agent-memory/integrations/memory-interface.md
Normal file
34
agent-memory/integrations/memory-interface.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
type: agent-integration
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- memory
|
||||
- integration
|
||||
---
|
||||
|
||||
# Memory Interface
|
||||
|
||||
Use `scripts/memory/memory.sh` as the project-agnostic interface to project knowledge.
|
||||
|
||||
---
|
||||
|
||||
## Default Root
|
||||
|
||||
The primary project knowledge directory is `project-knowledge/`.
|
||||
|
||||
Environment variable precedence:
|
||||
|
||||
1. `AIW_PROJECT_KNOWLEDGE_DIR`
|
||||
2. `AIW_MEMORY_VAULT_DIR`
|
||||
3. `AIW_OBSIDIAN_VAULT_DIR`
|
||||
4. `<workspace-root>/project-knowledge`
|
||||
|
||||
`AIW_MEMORY_VAULT_DIR` and `AIW_OBSIDIAN_VAULT_DIR` are transition aliases only.
|
||||
|
||||
---
|
||||
|
||||
## Agent Rule
|
||||
|
||||
Prefer the memory interface for typed note creation, search, Base queries, and health checks. Use direct Markdown edits when the adapter fails or when precise edits are simpler and safer.
|
||||
|
||||
153
agent-memory/integrations/obsidian.md
Normal file
153
agent-memory/integrations/obsidian.md
Normal file
@@ -0,0 +1,153 @@
|
||||
---
|
||||
type: guide
|
||||
audience: workspace-user
|
||||
tags:
|
||||
- onboarding
|
||||
- obsidian
|
||||
---
|
||||
|
||||
# Obsidian Adapter
|
||||
|
||||
Use Obsidian to navigate and review project knowledge. Do not use it as a separate memory database.
|
||||
|
||||
Obsidian is the current interface over canonical Markdown memory. The workspace-level abstraction is `scripts/memory/`, so agents should use Obsidian-specific commands only through that adapter when possible.
|
||||
|
||||
---
|
||||
|
||||
## Recommended Start
|
||||
|
||||
Open the `project-knowledge/` folder as the Obsidian vault, not the repository root and not `agent-memory/`.
|
||||
|
||||
Open:
|
||||
|
||||
- [Start Here](../../project-knowledge/00-start/start-here.md)
|
||||
- [New Member Onboarding](../../project-knowledge/00-start/onboarding.md)
|
||||
- [Knowledge Maps](../../project-knowledge/07-maps/index.md)
|
||||
|
||||
---
|
||||
|
||||
## Best Views
|
||||
|
||||
### New Member View
|
||||
|
||||
Start with:
|
||||
|
||||
- [New Member Onboarding](../../project-knowledge/00-start/onboarding.md)
|
||||
- [Glossary](../../project-knowledge/00-start/glossary.md)
|
||||
- [Current Work Map](../../project-knowledge/07-maps/current-work.md)
|
||||
- [Fidelity Domain Map](../../project-knowledge/07-maps/fidelity-domain.md)
|
||||
|
||||
### Daily Work View
|
||||
|
||||
Start with:
|
||||
|
||||
- [Current Work Map](../../project-knowledge/07-maps/current-work.md)
|
||||
- [Work Items Map](../../project-knowledge/07-maps/work-items.md)
|
||||
- [Daily Notes Index](../../project-knowledge/06-daily/index.md)
|
||||
|
||||
### System Understanding View
|
||||
|
||||
Start with:
|
||||
|
||||
- [Fidelity Domain Map](../../project-knowledge/07-maps/fidelity-domain.md)
|
||||
- [Fidelity Apps Map](../../project-knowledge/07-maps/fidelity-apps.md)
|
||||
- [People Map](../../project-knowledge/07-maps/people.md)
|
||||
|
||||
---
|
||||
|
||||
## Graph Guidance
|
||||
|
||||
Use the graph to find clusters, not to infer truth.
|
||||
|
||||
High-value graph hubs:
|
||||
|
||||
- `start-here`
|
||||
- `onboarding`
|
||||
- `current-work`
|
||||
- `fidelity-domain`
|
||||
- `work-items`
|
||||
- `people`
|
||||
- `fidelity-apps`
|
||||
- `fidelity-domain`
|
||||
|
||||
If a node is isolated, it may still be valid. It may be:
|
||||
|
||||
- a daily log
|
||||
- raw evidence
|
||||
- a command/prompt file
|
||||
- a file that needs to be linked from a map
|
||||
|
||||
---
|
||||
|
||||
## Global Graph Defaults
|
||||
|
||||
The global graph is configured for onboarding and project navigation, not full filesystem inspection.
|
||||
|
||||
It intentionally hides generic technical filenames such as:
|
||||
|
||||
- `index`
|
||||
- `README`
|
||||
- `AGENTS`
|
||||
- `SKILL`
|
||||
- `08-bases`
|
||||
- `09-templates`
|
||||
|
||||
Those files still exist and remain valid workspace files. They are hidden from the graph because Obsidian displays only the basename, which creates many indistinguishable nodes.
|
||||
|
||||
Use the file explorer or search when you need a specific technical file. Use the graph when you want to understand relationships between project concepts.
|
||||
|
||||
---
|
||||
|
||||
## When To Show Technical Files
|
||||
|
||||
Temporarily remove these filters from the graph search when debugging workspace internals:
|
||||
|
||||
```text
|
||||
-file:index -file:README -file:AGENTS -file:SKILL
|
||||
```
|
||||
|
||||
For normal onboarding, keep them hidden and navigate through the named maps.
|
||||
|
||||
---
|
||||
|
||||
## Editing Rules
|
||||
|
||||
- Edit canonical memory files when the fact is clear.
|
||||
- Prefer updating existing notes over adding duplicate summaries.
|
||||
- Do not edit generated files as durable memory.
|
||||
- Do not treat inbox files as confirmed truth.
|
||||
- Use maps to improve navigation, not to store detailed facts.
|
||||
|
||||
---
|
||||
|
||||
## Daily Notes, Templates, And Bases
|
||||
|
||||
- Daily notes live under `06-daily/` and use `09-templates/daily.md`.
|
||||
- Templates live under `09-templates/`.
|
||||
- Bases live under `08-bases/` and use simple `type` properties plus a folder exclusion for `09-templates/`.
|
||||
- Templates may contain the final note `type` so newly created notes are useful immediately, but Bases must exclude the template folder so template files do not appear as data rows.
|
||||
- Role mapping files such as `04-people/manager.md` should use `type: role-map`, not `type: person`.
|
||||
- Bookmarks should keep `00-start/start-here.md`, `00-start/onboarding.md`, current work, work items, people, and high-value Bases easy to open.
|
||||
|
||||
---
|
||||
|
||||
## CLI And Templates
|
||||
|
||||
The official Obsidian CLI can create notes from templates, query Bases, inspect properties, and search the vault.
|
||||
|
||||
In this workspace, prefer the platform-agnostic memory wrapper:
|
||||
|
||||
```bash
|
||||
bash scripts/memory/memory.sh create work-item pdiap-15999 "Example title"
|
||||
bash scripts/memory/memory.sh search "PDIAP-15765"
|
||||
bash scripts/memory/memory.sh base-query work-items
|
||||
bash scripts/memory/memory.sh health
|
||||
```
|
||||
|
||||
The wrapper owns note type routing, so a `work-item` goes to `02-work-items/`, a `person` goes to `04-people/`, a `decision` goes to `05-decisions/`, and so on.
|
||||
|
||||
Use Obsidian CLI directly only when debugging Obsidian-specific behavior:
|
||||
|
||||
```bash
|
||||
bash scripts/obsidian/cli.sh help
|
||||
```
|
||||
82
agent-memory/integrations/technical-verification.md
Normal file
82
agent-memory/integrations/technical-verification.md
Normal file
@@ -0,0 +1,82 @@
|
||||
---
|
||||
type: agent-integration
|
||||
status: active
|
||||
updated: 2026-04-17
|
||||
tags:
|
||||
- process
|
||||
- engineering
|
||||
- verification
|
||||
---
|
||||
# Technical Verification
|
||||
|
||||
## Goal
|
||||
|
||||
Ensure the agent gives senior-engineer technical advice instead of relying on stale model memory or generic best-practice claims.
|
||||
|
||||
---
|
||||
|
||||
## When To Verify
|
||||
|
||||
Verify against primary/current documentation before making strong claims about:
|
||||
|
||||
- dependency managers and package managers
|
||||
- CocoaPods, podspecs, private specs repos, trunk/CDN behavior, and migration strategy
|
||||
- Swift Package Manager behavior or migration strategy
|
||||
- Xcode, Swift, SwiftUI, Swift concurrency, Swift Testing, XCTest, or Apple framework behavior
|
||||
- CI/build systems and release propagation
|
||||
- security, authentication, networking, or migration practices
|
||||
- any claim that a pattern is a bad practice when project constraints may change the recommendation
|
||||
|
||||
---
|
||||
|
||||
## Source Priority
|
||||
|
||||
Prefer:
|
||||
|
||||
- official vendor documentation
|
||||
- language or framework documentation
|
||||
- official migration guides
|
||||
- source repository documentation when it is the canonical project source
|
||||
- current project memory when the question is project-specific
|
||||
|
||||
Use blogs, forum posts, or third-party guides only as supporting context, not as the primary basis for a strong recommendation.
|
||||
|
||||
---
|
||||
|
||||
## Answering Pattern
|
||||
|
||||
For technical recommendations:
|
||||
|
||||
1. State what is known from workspace context.
|
||||
2. Verify current external behavior when the topic is version-sensitive or disputed.
|
||||
3. Separate general best practice from project-safe recommendation.
|
||||
4. Explain tradeoffs and validation path.
|
||||
5. If context is missing, ask the smallest material clarification question.
|
||||
|
||||
---
|
||||
|
||||
## Bad Practice Claims
|
||||
|
||||
Avoid blanket claims such as:
|
||||
|
||||
- "CocoaPods is bad practice"
|
||||
- "SPM is always better"
|
||||
- "This architecture is an anti-pattern"
|
||||
- "This should be removed"
|
||||
|
||||
Instead explain:
|
||||
|
||||
- what risk the pattern introduces
|
||||
- whether the risk is current or theoretical
|
||||
- whether the project has constraints that justify it
|
||||
- what a safer migration path would look like
|
||||
|
||||
---
|
||||
|
||||
## Agentic Self-Improvement
|
||||
|
||||
The agent should be aware it is maintaining a workspace, not just answering chat prompts.
|
||||
|
||||
If a conversation reveals a recurring gap in technical quality, source verification, command behavior, or memory routing, the agent should propose or apply a workspace improvement in the correct file.
|
||||
|
||||
Do not store tool failures or one-off uncertainty as project facts. Store reusable rules and source anchors when they improve future technical answers.
|
||||
Reference in New Issue
Block a user