david.delagneau
dbc1894e27
- 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.
2.5 KiB
type, status, updated, tags
| type | status | updated | tags | |||
|---|---|---|---|---|---|---|
| agent-integration | active | 2026-04-17 |
|
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:
- State what is known from workspace context.
- Verify current external behavior when the topic is version-sensitive or disputed.
- Separate general best practice from project-safe recommendation.
- Explain tradeoffs and validation path.
- 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.