84 lines
2.5 KiB
Markdown
84 lines
2.5 KiB
Markdown
---
|
|
type: process
|
|
project: fidelity
|
|
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.
|