david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Update documentation for memory vault integration and work items, clarifying usage of Obsidian CLI and resolving Fid4 dependency conflicts

Browse Source
This commit is contained in:
David Delagneau
2026-04-17 14:42:00 -06:00
parent 4ea188739d
commit 696a1258b1
7 changed files with 35 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
vault/03-context/process/context-maintenance.md
View File

@@ -20,6 +20,7 @@ Keep this workspace useful as living memory instead of a pile of disconnected no
- Update canonical context when a durable fact changes.
- Prefer correcting stale context over appending contradictory notes.
- If a canonical note appears in an Obsidian Base, update its frontmatter properties together with the prose content.
- When changing frontmatter properties on existing canonical notes, prefer Obsidian CLI property operations through `scripts/obsidian/cli.sh` when available so YAML spacing and property formatting stay clean; fall back to direct Markdown edits only when the CLI is unavailable or the operation is unsupported.
- Keep templates under `vault/09-templates/` out of real-note Bases by filtering the template folder.
- Role mapping files should not use `type: person`; reserve `type: person` for actual people profiles.
- Work-item notes should keep known `systems`, `workstreams`, `people`, and `related` properties current.

1
vault/03-context/workstreams/consumer-integration.md
View File

@@ -90,6 +90,7 @@ Capture the durable release and validation path between XFlow changes and real c
- fixed version references in the Podfile when present
- archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files
- Even those checks are not perfect guarantees because the podspec repo can be edited after publication.
- When a consumer build must be reproduced exactly from an older dependency snapshot, `Podfile.lock` alone may still be insufficient if the private podspec repo changed afterward; the stronger reproduction path is to align the podspec repo revision too.
- A newly published XFlowViewMaker version can still be blocked in Fid4 if downstream podspec constraints in `FTAccountOpen` or `FTTransfer` do not yet accept the new adapter version.
- Historical/current evidence suggests Tauf has resolved similar propagation blocks by updating the relevant constraint directly in the podspec repo.
- Current evidence suggests the effective constraint may live in the podspec repo layer rather than in the FTFrameworks source repo itself.