david.delagneau
1ad707373a
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
69 lines
2.5 KiB
Markdown
69 lines
2.5 KiB
Markdown
# AI Workspace Core
|
|
|
|
Reusable operating layer for AI-assisted professional workspaces.
|
|
|
|
The core is project-independent. It defines how an AI agent should maintain file-based memory, ingest communication evidence, draft recurring updates, and adjust its own commands, prompts, and skills when reusable behavior changes.
|
|
|
|
---
|
|
|
|
## Core Responsibilities
|
|
|
|
- Maintain operational memory across sessions
|
|
- Separate imported evidence from promoted memory
|
|
- Provide reusable command and prompt patterns
|
|
- Support project profiles without embedding project-specific facts in the core
|
|
- Keep tooling behavior editable by the agent when the user corrects recurring output
|
|
|
|
---
|
|
|
|
## Project Profiles
|
|
|
|
Each real project should provide a profile under `profiles/<project>/`.
|
|
|
|
A profile declares:
|
|
|
|
- project name and audience
|
|
- active communication sources
|
|
- ticket/work-item system
|
|
- manager or stakeholder mapping
|
|
- domain-specific context files
|
|
- enabled commands and skills
|
|
|
|
The core should never require a specific company, codebase, manager, channel name, ticket prefix, or programming stack.
|
|
|
|
---
|
|
|
|
## Memory Layers
|
|
|
|
- `daily`: facts from a specific workday
|
|
- `state`: current active focus and near-term constraints
|
|
- `work-items`: canonical memory for active units of work
|
|
- `stable-context`: durable system, domain, process, or architecture knowledge
|
|
- `people`: role, stakeholder, and collaboration memory
|
|
- `decisions`: confirmed decisions with ongoing impact
|
|
- `tooling-behavior`: reusable rules that change commands, prompts, skills, or agent behavior
|
|
|
|
See `core/memory/operational-memory.md` for the detailed rules.
|
|
|
|
---
|
|
|
|
## Integration Model
|
|
|
|
Integrations extract evidence. They do not decide what becomes memory.
|
|
|
|
- live communication connectors write recent evidence to `workspaces/<profile>/inbox/`
|
|
- historical archive connectors write selected evidence to `scripts/<source>/generated/`
|
|
- the agent promotes only high-confidence, project-relevant facts into memory
|
|
|
|
See `core/integrations/communication-model.md` for the reusable connector contract.
|
|
|
|
---
|
|
|
|
## Knowledge Navigation
|
|
|
|
Optional navigation layers such as Obsidian should read the same Markdown files instead of copying memory into a second store.
|
|
|
|
See `core/integrations/obsidian-model.md` for the recommended vault model.
|
|
|
|
The project-agnostic memory interface lives in `scripts/memory/` and is documented in `core/integrations/memory-vault-model.md`. Agents should use that interface for note creation, project knowledge search, Base queries, and health checks, while still editing Markdown directly for precise curation.
|