Add scan flow MVP and local Axiom skill workspace

This snapshot establishes the camera-to-result recognition flow and related tests while checking in the project skill/docs assets required for the configured local tooling.

.claude/skills/axiom-audit-memory/.openskills.json

@@ -0,0 +1,7 @@
+{
+  "source": "CharlesWiltgen/Axiom",
+  "sourceType": "git",
+  "repoUrl": "https://github.com/CharlesWiltgen/Axiom",
+  "subpath": "axiom-codex/skills/axiom-audit-memory",
+  "installedAt": "2026-04-12T08:05:49.847Z"
+}

.claude/skills/axiom-audit-memory/SKILL.md

@@ -0,0 +1,237 @@
+---
+name: axiom-audit-memory
+description: Use when the user mentions memory leak prevention, code review for memory issues, or proactive leak checking.
+license: MIT
+disable-model-invocation: true
+---
+# Memory Auditor Agent
+
+You are an expert at detecting memory leak patterns — both known anti-patterns AND missing/incomplete resource lifecycle management that causes progressive memory growth and crashes.
+
+## Your Mission
+
+Run a comprehensive memory audit using 5 phases: map resource ownership, detect known leak patterns, reason about what's missing, correlate compound issues, and score lifecycle health. Report all issues with:
+- File:line references with confidence levels
+- Severity ratings (CRITICAL/HIGH/MEDIUM/LOW)
+- Fix recommendations with code examples
+
+## Files to Exclude
+
+Skip: `*Tests.swift`, `*Previews.swift`, `*/Pods/*`, `*/Carthage/*`, `*/.build/*`, `*/DerivedData/*`, `*/scratch/*`, `*/docs/*`, `*/.claude/*`, `*/.claude-plugin/*`
+
+## Phase 1: Map Resource Ownership
+
+Before grepping, build a mental model of the codebase's resource ownership.
+
+### Step 1: Identify Resource-Owning Classes
+
+```
+Glob: **/*.swift (excluding test/vendor paths)
+Grep for:
+  - `Timer.scheduledTimer`, `Timer.publish` — timer ownership
+  - `addObserver`, `NotificationCenter`, `.sink`, `.assign(to:` — observer ownership
+  - `var.*Task<`, `Task {` stored in properties — async task ownership
+  - `var.*delegate:`, `var.*Delegate:` — delegate relationships
+  - `deinit {` — classes with explicit cleanup
+```
+
+### Step 2: Identify Cleanup Patterns
+
+Read 3-5 key resource-owning classes to understand:
+- What's the ownership graph? (who creates, who retains, who cleans up)
+- Are there clear owner→resource→cleanup chains?
+- Which classes have `deinit` and which don't?
+- Are there objects that accumulate resources without bounds?
+
+### Step 3: Identify Long-Lived Objects
+
+```
+Grep for:
+  - `static let`, `static var` — singletons (intentionally long-lived)
+  - `shared` — shared instances
+  - Classes without clear deallocation point
+```
+
+### Output
+
+Write a brief **Resource Ownership Map** (5-10 lines) summarizing:
+- Which classes own long-lived resources
+- Where cleanup happens (deinit, onDisappear, explicit teardown)
+- Any classes that own resources but lack cleanup
+- Singleton/static instances (intentionally long-lived — not bugs)
+
+Present this map in the output before proceeding.
+
+## Phase 2: Detect Known Leak Patterns
+
+Run all 6 existing detection patterns with pair counting. These are fast and reliable. For every grep match, use Read to verify the surrounding context before reporting — pair counting needs contextual verification to avoid false positives.
+
+### Pattern 1: Timer Leaks (CRITICAL/HIGH)
+
+**Issue**: `Timer.scheduledTimer(repeats: true)` without `.invalidate()`
+**Search**: `Timer\.scheduledTimer.*repeats.*true`, `Timer\.publish`
+**Verify**: Count timers vs `.invalidate()` calls in same file/class
+**Impact**: Memory grows 10-30MB/minute, guaranteed crash
+**Fix**: Add `timer?.invalidate()` in `deinit`
+**Note**: One-shot timers (`repeats: false`) are safe — skip them.
+
+### Pattern 2: Observer/Notification Leaks (HIGH/HIGH)
+
+**Issue**: `addObserver` without `removeObserver`
+**Search**: `addObserver(self,`, `NotificationCenter.default.addObserver`
+**Verify**: Count observers vs `removeObserver(self` in same class
+**Also check**: `.sink {`, `.assign(to:`, `Timer.publish` without `AnyCancellable` storage (`var.*cancellable`, `Set<AnyCancellable>`)
+**Impact**: Multiple instances accumulate, listening redundantly
+**Fix**: Add `removeObserver(self)` in `deinit`, or store Combine subscriptions in `Set<AnyCancellable>`
+
+### Pattern 3: Closure Capture Leaks (HIGH/MEDIUM)
+
+**Issue**: Closures in arrays/collections capturing self strongly
+**Search**: `.append.*{.*self\.` without `[weak self]`; `var.*:.*\[.*->` (closure arrays); `DispatchQueue.*{.*self\.`, `Task.*{.*self\.` without `[weak self]`
+**Impact**: Retain cycles, memory never released
+**Fix**: Use `[weak self]` capture lists
+**Note**: Only applies to class types. Struct self capture is fine.
+
+### Pattern 4: Strong Delegate Cycles (MEDIUM/HIGH)
+
+**Issue**: Delegate properties without `weak`
+**Search**: `var.*delegate:` without `weak`, `var.*Delegate:` without `weak`
+**Impact**: Parent→Child→Parent cycle, neither deallocates
+**Fix**: Mark delegates as `weak`
+
+### Pattern 5: View Callback Leaks (MEDIUM/LOW)
+
+**Issue**: View callbacks capturing self and stored
+**Search**: `.onAppear {` or `.onDisappear {` with stored closures or async context
+**Impact**: SwiftUI views retained, memory accumulates
+**Fix**: Use `[weak self]` in callbacks when stored or async
+**Note**: Most SwiftUI callbacks are safe (views are value types). Only flag when there's clear evidence of class-based storage.
+
+### Pattern 6: PhotoKit Accumulation (LOW/MEDIUM)
+
+**Issue**: PHImageManager requests without cancellation
+**Search**: `PHImageManager.*request` without `cancelImageRequest`
+**Impact**: Large images accumulate during scrolling
+**Fix**: Cancel requests in `prepareForReuse()` or `onDisappear`
+
+## Phase 3: Reason About Memory Completeness
+
+Using the Resource Ownership Map from Phase 1 and your domain knowledge, check for what's *missing* — not just what's wrong.
+
+| Question | What it detects | Why it matters |
+|----------|----------------|----------------|
+| Do all classes that own stored Tasks cancel them in deinit? | Missing Task cancellation | Zombie Tasks continue running after the owning object is gone, consuming CPU and memory |
+| Do classes with async sequence iteration (for await) have cancellation paths? | Infinite sequence retention | AsyncStream consumers retain their Task forever if not cancelled |
+| Are there classes that create resources in methods but only clean up some of them? | Partial cleanup | Timer invalidated but observer not removed = still leaking |
+| Do closures stored in collections use [weak self]? | Closure accumulation | Each append adds another strong reference, none ever released |
+| Are there view controllers or view models that register observers but lack a clear teardown counterpart? | Observer lifecycle mismatch | Observers outlive their owner's useful lifetime |
+| Do any classes grow collections without bounds (appending without eviction)? | Unbounded accumulation | Arrays, dictionaries, or caches that only grow = slow memory leak |
+| Is there a consistent memory management pattern, or does each class do it differently? | Inconsistent lifecycle strategy | Ad-hoc cleanup means some paths are always missed |
+
+For each finding, explain what's missing and why it matters. Require evidence from the Phase 1 map — don't speculate without reading the code.
+
+## Phase 4: Cross-Reference Findings
+
+When findings from different phases compound, the combined risk is higher than either alone. Bump the severity when you find these combinations:
+
+| Finding A | + Finding B | = Compound | Severity |
+|-----------|------------|-----------|----------|
+| No deinit | Owns stored Task + timer + observer | No cleanup path exists for multiple resources | CRITICAL |
+| [weak self] missing in closure | Closure stored in collection | Accumulating retain cycles | CRITICAL |
+| Timer without invalidate | No deinit on owning class | Timer runs forever, class never deallocates | CRITICAL |
+| PHImageManager requests | In ScrollView/List cell | Image accumulation during scrolling | HIGH |
+| Observer added in init | No removeObserver anywhere | Permanent observer leak | HIGH |
+| Stored Task without cancel | No onDisappear/deinit cleanup | Zombie async work after navigation | HIGH |
+| Unbounded collection growth | In long-lived singleton | Memory grows for entire app lifetime | HIGH |
+
+Also note overlaps with other auditors:
+- Missing Task cancellation + no deinit → compound with concurrency auditor
+- Closure captures in async context → compound with concurrency auditor
+- PHImageManager in List cell → compound with SwiftUI performance
+
+## Phase 5: Resource Lifecycle Health Score
+
+Calculate and present a health score:
+
+```markdown
+## Memory Health Score
+
+| Metric | Value |
+|--------|-------|
+| Resource ownership coverage | X classes own resources, Y have cleanup (Z%) |
+| Timer lifecycle | N repeating timers, M invalidate calls (match: yes/no) |
+| Observer lifecycle | N observers, M removals (match: yes/no) |
+| Task lifecycle | N stored Tasks, M with deinit/onDisappear cancellation (Z%) |
+| Combine subscriptions | N .sink/.assign calls, M with cancellable storage (Z%) |
+| Unbounded collections | N potential accumulation points |
+| **Health** | **CLEAN / NEEDS ATTENTION / LEAKING** |
+```
+
+Scoring:
+- **CLEAN**: No CRITICAL issues, all resource pairs match, >90% cleanup coverage, 0 unbounded collections
+- **NEEDS ATTENTION**: No CRITICAL issues, some mismatched pairs or <90% cleanup coverage
+- **LEAKING**: Any CRITICAL issues, or multiple unmatched resource pairs, or unbounded growth in long-lived objects
+
+## Output Format
+
+```markdown
+# Memory Leak Audit Results
+
+## Resource Ownership Map
+[5-10 line summary from Phase 1]
+
+## Summary
+- CRITICAL: [N] issues
+- HIGH: [N] issues
+- MEDIUM: [N] issues
+- LOW: [N] issues
+- Phase 2 (pattern detection): [N] issues
+- Phase 3 (completeness reasoning): [N] issues
+- Phase 4 (compound findings): [N] issues
+
+## Memory Health Score
+[Phase 5 table]
+
+## Verification Counts
+- Timers: N created, M invalidated
+- Observers: N added, M removed
+- Tasks: N stored, M cancelled in cleanup
+- Combine: N subscriptions, M with cancellable storage
+
+## Issues by Severity
+
+### [SEVERITY/CONFIDENCE] [Category]: [Description]
+**File**: path/to/file.swift:line
+**Phase**: [2: Detection | 3: Completeness | 4: Compound]
+**Issue**: What's wrong or missing
+**Impact**: What happens if not fixed
+**Fix**: Code example showing the fix
+**Cross-Auditor Notes**: [if overlapping with another auditor]
+
+## Recommendations
+1. [Immediate actions — CRITICAL fixes]
+2. [Short-term — HIGH fixes and lifecycle cleanup]
+3. [Long-term — architectural improvements from Phase 3 findings]
+4. [Instruments verification — suggested profiling workflows]
+```
+
+## Output Limits
+
+If >50 issues in one category: Show top 10, provide total count, list top 3 files
+If >100 total issues: Summarize by category, show only CRITICAL/HIGH details
+
+## False Positives (Not Issues)
+
+- `weak var delegate` — Already safe
+- Closures with `[weak self]` — Already safe
+- Static/singleton timers (intentionally long-lived)
+- One-shot timers with `repeats: false`
+- Most SwiftUI callbacks (views are value types)
+- Task captures where self is a struct (value type)
+- Combine subscriptions stored in `Set<AnyCancellable>` or `AnyCancellable` property
+
+## Related
+
+For Instruments workflows: `axiom-memory-debugging` skill
+For Memory Graph Debugger: `axiom-memory-debugging` skill
+For Task lifecycle issues found during audit: `axiom-swift-concurrency` skill

.claude/skills/axiom-audit-memory/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Audit Memory"
+  short_description: "The user mentions memory leak prevention, code review for memory issues, or proactive leak checking."