refactor(ledger): wrap sqlite_store types in domain abstractions

[fagemx]

Problem

`edda-ledger/src/lib.rs` re-exports 12 types directly from `sqlite_store`:

```rust
pub use sqlite_store::{
BundleRow, ChainEntry, DecideSnapshotRow, DecisionRow,
DepRow, DetectedPattern, DeviceTokenRow, ImportParams,
PatternDetectionResult, PatternType, SuggestionRow, TaskBriefRow,
};
```

These are SQL row structs, not domain concepts. Downstream crates like `edda-ask` import `DecisionRow` directly:

```rust
// edda-ask/src/lib.rs:2
use edda_ledger::sqlite_store::DecisionRow;
```

This couples the query engine to the SQLite storage implementation. If the storage backend changes, the blast radius is large.

Proposed Fix

1. Create domain-level types (or use existing `DecisionView`) as the public API
2. Mark `sqlite_store` types as `pub(crate)` where possible
3. Update `edda-ask` and `edda-serve` to use domain types instead of row types
4. Keep `sqlite_store` module public only for types that are genuinely domain concepts (`PatternType`)

Impact

• `edda-ask` — uses `DecisionRow` (1 import)
• `edda-serve` — uses several re-exported types
• Other crates — use `Ledger` methods that return these types

[fagemx]

Research: Wrap sqlite_store Types in Domain Abstractions (GH-378)

Problem Statement

edda-ledger re-exports 12 SQL row structs from sqlite_store as public API. Downstream crates (edda-ask, edda-serve, edda-cli, edda-aggregate, edda-ingestion, edda-bridge-claude) import these types directly, coupling them to the SQLite implementation. If the storage backend changes, every consumer must be updated.

Current Architecture

Module Structure (post PR #382)

sqlite_store/ is now split into 9 sub-modules:

• mod.rs — SqliteStore struct + re-exports pub use types::*
• types.rs — All row structs and enums (the focus of this issue)
• mappers.rs, schema.rs, events.rs, decisions.rs, village.rs, dependencies.rs, entities.rs

Re-exported Types from edda-ledger/src/lib.rs:21-24

pub use sqlite_store::{
    BundleRow, ChainEntry, DecideSnapshotRow, DecisionRow, DepRow, DetectedPattern, DeviceTokenRow,
    ImportParams, PatternDetectionResult, PatternType, SuggestionRow, TaskBriefRow,
};

Additional types in types.rs NOT currently re-exported from lib.rs:

• VillageStats, VillageStatsPeriod, DomainCount, DayCount (used via edda_ledger::sqlite_store::VillageStats path in edda-serve)
• OutcomeMetrics, ExecutionLinked (used via crate::sqlite_store:: paths in ledger.rs)

Existing Domain Abstraction: DecisionView

edda-ledger/src/view.rs already defines DecisionView as a read-side projection of DecisionRow. This is the established pattern — CONTRACT BOUNDARY-01. edda-pack and edda-bridge-claude correctly use DecisionView instead of DecisionRow.

Key differences from DecisionRow:

• Parses affected_paths and tags from JSON strings to Vec<String>
• Renames scope to propagation
• Drops is_active, source_project_id, source_event_id
• Adds #[derive(serde::Serialize)]

Downstream Usage Analysis

Type-by-Type Breakdown

1. DecisionRow — Heaviest coupling, most consumers

Crate	Usage	Fields accessed
edda-ask	ScoredDecision.row, rank_decisions_by_similarity(), to_decision_hit()	event_id, key, value, reason, domain, branch, ts, is_active, tags, village_id
edda-cli/cmd_bridge	find_active_decision() result, supersede logic	value, event_id, key
edda-aggregate	active_decisions() to DecisionRecord	event_id, key, value, reason, domain, branch, ts
edda-bridge-claude/bg_scan	active_decisions() to format for context	key, value, reason
edda-serve/api/events	find_active_decision() to supersede logic	value, event_id

Note: edda-ask accesses is_active directly in to_decision_hit() (line 823). This is a storage-level field that should not leak.

2. DeviceTokenRow — Write + read across 3 crates

Crate	Usage
edda-cli/cmd_pair	Constructs DeviceTokenRow for insert_device_token()
edda-serve/api/auth	Constructs DeviceTokenRow for insert_device_token()
edda-serve/lib.rs (tests)	Constructs DeviceTokenRow in auth tests

Note: Consumers construct row structs directly — they're used as both input and output types.

3. BundleRow — Light usage

Crate	Usage
edda-cli/cmd_bundle	print_bundle_row() — display formatting

4. SuggestionRow — Bidirectional conversion in edda-ingestion

Crate	Usage
edda-ingestion/suggestion	suggestion_to_row() + row_to_suggestion() — full bidirectional mapping

5. VillageStats + PatternDetectionResult — Return types in edda-serve

Crate	Usage
edda-serve/api/snapshots	Json<VillageStats> and Json<PatternDetectionResult> as HTTP response types; also constructs PatternDetectionResult directly

6. DecideSnapshotRow — Write + read in edda-serve

Crate	Usage
edda-serve/api/snapshots	Constructs for insert_snapshot(), reads via reconstruct_snapshot()

7. DetectedPattern + PatternType — Currently re-exported

Re-exported from lib.rs but only used within edda-ledger itself and via edda-serve (through PatternDetectionResult).

Note: edda-bridge-claude/bg_detect.rs has its own completely separate DetectedPattern struct (different shape — LLM-based pattern detection, not SQL-based).

8. DepRow — Internal to edda-ledger + edda-ask

Used by Ledger::deps_of(), dependents_of(), transitive_dependents_of(). edda-ask consumes transitive_dependents_of() which returns Vec<(DepRow, DecisionRow, usize)>.

9. ChainEntry — Internal to edda-ledger

Used by Ledger::causal_chain() which returns Option<(DecisionRow, Vec<ChainEntry>)>. ChainEntry contains a DecisionRow.

10. ImportParams — Write-only input type

Used by Ledger::insert_imported_decision(). Internal to edda-ledger and edda-aggregate conceptually.

11. TaskBriefRow — Internal reads

Used by Ledger::get_task_brief() and list_task_briefs(). Consumers access via Ledger methods.

12. OutcomeMetrics + ExecutionLinked — Not re-exported from lib.rs

Used only internally by Ledger::decision_outcomes() and executions_for_decision(). Not in the re-export list but accessible via edda_ledger::sqlite_store::* path.

Key Observations

1. DecisionView pattern already exists and is correctly used by edda-pack and edda-bridge-claude (BOUNDARY-01). The issue is that other crates bypass this boundary.

2. edda-ask is the worst offender — it imports DecisionRow directly from sqlite_store, uses is_active (storage-level boolean), and structures its entire search around the row type.

3. Some types are genuinely domain concepts, not just SQL rows:

   • PatternType — enum with RecurringDecision, ChiefRepeatedAction, RollbackTrend
   • DetectedPattern — pattern detection result (but note naming collision with bridge-claude)
   • PatternDetectionResult, VillageStats — aggregated analytics results

4. Some types are write-path input types (DeviceTokenRow, DecideSnapshotRow, ImportParams) — consumers construct these to pass to Ledger methods. These need a different strategy than read-path types.

5. edda-serve uses fully-qualified paths like edda_ledger::sqlite_store::DeviceTokenRow in tests and edda_ledger::sqlite_store::VillageStats as return types — even types not in the re-export list.

6. Blast radius: 7 crates directly use sqlite_store types. The Ledger facade returns these types from 15+ methods.

Constraints

• BOUNDARY-01 contract already exists — should extend the pattern, not invent new ones
• 12+ types to categorize and potentially wrap
• Some types (DeviceTokenRow, DecideSnapshotRow) are used as both input AND output
• edda-bridge-claude has its own DetectedPattern — any rename/move must avoid collision
• ChainEntry embeds DecisionRow — nested dependency
• Tests across crates construct row structs directly — major refactor surface

[fagemx]

Innovation: Wrap sqlite_store Types in Domain Abstractions (GH-378)

Type Classification

Based on research, the 16 types in sqlite_store/types.rs fall into four categories:

Category A: True Domain Concepts (already well-shaped)

Types that represent domain concepts, not SQL row details. They already have proper serde derives and field names. Strategy: relocate, do not wrap.

• PatternType — enum, pure domain
• DetectedPattern — pattern detection output (note: different from bridge-claude's DetectedPattern)
• PatternDetectionResult — aggregated result container
• VillageStats, VillageStatsPeriod, DomainCount, DayCount — analytics types
• OutcomeMetrics, ExecutionLinked — decision outcome analytics

Category B: Read-side Row Types (need view projection)

Types returned from Ledger queries where consumers access raw SQL fields. Strategy: create view projections (extend BOUNDARY-01 pattern).

• DecisionRow — already has DecisionView, but many crates bypass it
• BundleRow — needs a BundleView or direct re-export if fields are clean enough
• TaskBriefRow — needs a TaskBriefView or stays as-is if only accessed via Ledger
• SuggestionRow — edda-ingestion does bidirectional conversion already
• ChainEntry — contains DecisionRow, needs to reference domain type instead
• DepRow — dependency edge, accessed by edda-ask

Category C: Write-path Input Types (need input structs)

Types consumers construct to pass to Ledger methods. Strategy: rename to domain-oriented input types or keep as-is with better naming.

• DeviceTokenRow — used as insert input in cmd_pair, serve/auth
• DecideSnapshotRow — used as insert input in serve/snapshots
• ImportParams — used for cross-project import

Category D: Internal-only (make pub(crate))

Types that should never leak outside edda-ledger. Strategy: restrict visibility.

• (After analysis: none are truly internal-only — all are used via Ledger methods)

Solution Approaches

Approach 1: "View Layer Extension" (Recommended)

Extend the existing DecisionView pattern to cover more types. Create a views module alongside the existing view.rs.

Strategy by category:

Category A (domain types):

• Move PatternType, DetectedPattern, PatternDetectionResult, VillageStats family, OutcomeMetrics, ExecutionLinked to a new edda-ledger/src/domain.rs module
• Re-export from lib.rs directly — these are domain types, not SQL artifacts
• Keep sqlite_store/types.rs importing from domain.rs for internal use (or type alias)

Category B (read types):

• DecisionRow — Ledger methods that return Vec<DecisionRow> should return Vec<DecisionView> instead. This is the biggest win.
• BundleRow — Create BundleView if field transformations needed, otherwise re-export with Row suffix removed
• ChainEntry — Change to contain DecisionView instead of DecisionRow
• DepRow — Rename to DependencyEdge and re-export from domain module
• TaskBriefRow — Already uses edda_core::types::TaskBriefIntent/Status, so it's semi-domain already
• SuggestionRow — Keep as-is; edda-ingestion has its own Suggestion domain type

Category C (write types):

• DeviceTokenRow — Rename to NewDeviceToken (input-only)
• DecideSnapshotRow — Rename to SnapshotRecord (used both ways)
• ImportParams — Keep name, it's clear and internal

Migration of Ledger methods:

• active_decisions() → returns Vec<DecisionView> instead of Vec<DecisionRow>
• find_active_decision() → returns Option<DecisionView>
• decision_timeline() → returns Vec<DecisionView>
• domain_timeline() → returns Vec<DecisionView>
• get_decision_by_event_id() → returns Option<DecisionView>
• shared_decisions() → returns Vec<DecisionView>
• causal_chain() → returns Option<(DecisionView, Vec<ChainEntry>)> with updated ChainEntry
• transitive_dependents_of() → returns new tuple type

Pros:

• Follows established pattern (BOUNDARY-01)
• DecisionView already exists and is battle-tested
• Incremental — can migrate one method at a time
• Downstream crates that already use DecisionView need zero changes

Cons:

• Many Ledger methods to update (15+)
• Performance cost: to_view() clones + parses JSON for every row
• Tests that construct DecisionRow directly won't break (row stays internal)

Approach 2: "Type Aliasing + pub(crate)"

Keep types in sqlite_store/types.rs but create type aliases in a domain module.

// domain.rs
pub type Decision = sqlite_store::DecisionRow;
pub type Bundle = sqlite_store::BundleRow;

Pros:

• Zero runtime cost
• Minimal code changes
• Easy to implement

Cons:

• Type aliases are transparent — consumers can still see all Row fields
• Does NOT actually hide storage details (is_active, scope vs propagation)
• Feels like cosmetic renaming, not real abstraction

Approach 3: "Trait-based Abstraction"

Define traits for each domain concept and have row types implement them.

pub trait Decision {
    fn key(&self) -> &str;
    fn value(&self) -> &str;
    // ...
}

Pros:

• Maximum flexibility for future backends
• Enforces interface contracts

Cons:

• Over-engineered for current needs (YAGNI)
• Loses struct field access, requires getters everywhere
• Significant refactor of all consumer code
• Dynamic dispatch overhead (or complex generic bounds)

Recommended Approach: Approach 1 (View Layer Extension)

Phased Execution

Phase 1: Relocate domain types (low risk, no breaking changes)

• Create edda-ledger/src/domain.rs
• Move Category A types there
• Re-export from lib.rs
• Update edda-serve to use new import paths

Phase 2: Migrate DecisionRow to DecisionView (medium risk, most impact)

• Change Ledger methods to return DecisionView
• Update edda-ask, edda-cli/cmd_bridge, edda-aggregate, edda-bridge-claude, edda-serve
• Fix ChainEntry to embed DecisionView
• Remove is_active leak in edda-ask

Phase 3: Clean up remaining types (low risk)

• Rename DeviceTokenRow to NewDeviceToken or similar
• Rename DepRow to DependencyEdge
• Make sqlite_store module pub(crate) (the big payoff)
• Remove direct sqlite_store:: paths from downstream crates

Performance Consideration

The to_view() conversion involves:

• Cloning all string fields
• Parsing two JSON arrays (affected_paths, tags)

For hot paths like active_decisions_limited() (called by edda-ask with 500 candidates), this could be noticeable. Options:

1. Accept the cost (probably fine — these are in-memory clones, not I/O)
2. Do the conversion inside SqliteStore at query time, before returning
3. Cache parsed views (over-engineering for now)

Option 1 is recommended — the clone cost is negligible compared to SQLite query time.

Key Design Decision

Where should the Row→View conversion happen?

Option A: In Ledger methods (current to_view() approach)

pub fn active_decisions(...) -> Result<Vec<DecisionView>> {
    let rows = self.sqlite.active_decisions(...)?;
    Ok(rows.iter().map(view::to_view).collect())
}

Option B: In SqliteStore methods (push conversion deeper)

// SqliteStore returns DecisionView directly
pub fn active_decisions(...) -> Result<Vec<DecisionView>> { ... }

Recommendation: Option A — keeps SqliteStore focused on SQL ↔ Rust mapping, and Ledger as the boundary layer. This matches the existing query_active_with_paths() and query_by_paths() methods that already do this conversion.

[fagemx]

Plan: Wrap sqlite_store Types in Domain Abstractions (GH-378)

Approach

View Layer Extension -- extend the existing DecisionView pattern (BOUNDARY-01) to cover all publicly leaked sqlite_store types. Three-phase rollout, each phase a separate PR.

---

Phase 1: Relocate domain types + create domain.rs (1 PR)

Goal: Move types that are already domain-shaped out of sqlite_store/types.rs into a proper domain module. No behavioral change.

Step 1.1 -- Create edda-ledger/src/domain.rs

Move the following types (Category A -- already have serde::Serialize, no storage-specific fields):

Type	Current location	Rationale
PatternType	sqlite_store/types.rs:97-103	Pure enum, no SQL coupling
DetectedPattern	sqlite_store/types.rs:106-120	Pattern output, well-shaped
PatternDetectionResult	sqlite_store/types.rs:123-130	Aggregated container
VillageStats	sqlite_store/types.rs:73-85	Analytics, not a DB row
VillageStatsPeriod	sqlite_store/types.rs:88-94	Sub-struct of VillageStats
DomainCount	sqlite_store/types.rs:133-137	Simple count pair
DayCount	sqlite_store/types.rs:140-144	Simple count pair
OutcomeMetrics	sqlite_store/types.rs:220-237	Aggregated metrics
ExecutionLinked	sqlite_store/types.rs:240-251	Event projection

Step 1.2 -- Update sqlite_store/types.rs

Replace moved types with pub use crate::domain::* re-imports so internal sqlite_store code still compiles without changes.

Step 1.3 -- Update lib.rs re-exports

pub mod domain;
pub use domain::{
    PatternType, DetectedPattern, PatternDetectionResult,
    VillageStats, VillageStatsPeriod, DomainCount, DayCount,
    OutcomeMetrics, ExecutionLinked,
};

Step 1.4 -- Update downstream import paths

• edda-serve/src/api/snapshots.rs:222 -- change edda_ledger::sqlite_store::VillageStats to edda_ledger::VillageStats
• edda-serve/src/api/snapshots.rs:255 -- change edda_ledger::sqlite_store::PatternDetectionResult to edda_ledger::PatternDetectionResult
• edda-serve/src/api/snapshots.rs:275 -- same for construction site

Step 1.5 -- Verify

cargo fmt --check
cargo clippy --workspace --all-targets
cargo test --workspace

Files touched: edda-ledger/src/domain.rs (new), edda-ledger/src/lib.rs, edda-ledger/src/sqlite_store/types.rs, edda-serve/src/api/snapshots.rs

---

Phase 2: Migrate DecisionRow to DecisionView in Ledger API (1 PR)

Goal: Change 10 Ledger methods to return DecisionView instead of DecisionRow. This is the highest-impact change -- it removes is_active leakage and makes storage opaque to consumers.

Step 2.1 -- Change Ledger method return types

The following methods currently return DecisionRow. Change to return DecisionView by applying view::to_view() conversion:

Method	Current return	New return	Line
active_decisions()	Vec<DecisionRow>	Vec<DecisionView>	L212
active_decisions_limited()	Vec<DecisionRow>	Vec<DecisionView>	L226
decision_timeline()	Vec<DecisionRow>	Vec<DecisionView>	L239
domain_timeline()	Vec<DecisionRow>	Vec<DecisionView>	L252
find_active_decision()	Option<DecisionRow>	Option<DecisionView>	L292
shared_decisions()	Vec<DecisionRow>	Vec<DecisionView>	L359
get_decision_by_event_id()	Option<DecisionRow>	Option<DecisionView>	L462
active_dependents_of()	Vec<(DepRow, DecisionRow)>	Vec<(DepRow, DecisionView)>	L419
transitive_dependents_of()	Vec<(DepRow, DecisionRow, usize)>	Vec<(DepRow, DecisionView, usize)>	L453
causal_chain()	Option<(DecisionRow, Vec<ChainEntry>)>	Option<(DecisionView, Vec<ChainEntry>)>	L473

Pattern (same for all):

pub fn active_decisions(...) -> anyhow::Result<Vec<DecisionView>> {
    let rows = self.sqlite.active_decisions(...)?;
    Ok(rows.iter().map(view::to_view).collect())
}

Step 2.2 -- Update ChainEntry to use DecisionView

In sqlite_store/types.rs:38-43, ChainEntry contains DecisionRow. Two options:

Recommended: Create ChainEntryView in domain.rs with DecisionView inside. Keep original ChainEntry in sqlite_store for internal use. Convert in Ledger causal_chain() method. This avoids coupling sqlite_store to domain.rs.

// domain.rs
pub struct ChainEntryView {
    pub decision: DecisionView,
    pub relation: String,
    pub depth: usize,
}

Step 2.3 -- Update edda-ask

edda-ask/src/lib.rs -- the biggest consumer change:

1. Change use edda_ledger::sqlite_store::DecisionRow to use edda_ledger::DecisionView (L2)
2. Change ScoredDecision.row: DecisionRow to ScoredDecision.row: DecisionView (L10)
3. Change rank_decisions_by_similarity parameter candidates: Vec<DecisionRow> to Vec<DecisionView> (L606)
4. Change tokenized_docs: Vec<(DecisionRow, Vec<String>)> to Vec<(DecisionView, Vec<String>)> (L614)
5. Update field access in rank_decisions_by_similarity (L616-619):
   • row.branch, row.domain, row.key, row.value, row.reason -- all exist on DecisionView, no change needed
6. Update to_decision_hit() (L813-827):
   • row.tags -- already a Vec<String> on DecisionView (no JSON parsing needed -- simplification!)
   • Remove serde_json::from_str(&row.tags) call, use row.tags.clone() directly
   • row.is_active -- derive from row.status: matches!(row.status.as_str(), "active" | "experimental")
   • row.ts.clone().unwrap_or_default() -- stays (same field shape)
7. Keep DecisionHit.is_active field for API compatibility, derive from status

Step 2.4 -- Update edda-serve

• edda-serve/src/api/events.rs -- find_active_decision() now returns DecisionView:
  • existing.value -- stays (field exists)
  • existing.event_id -- stays (field exists)

Step 2.5 -- Verify

cargo fmt --check
cargo clippy --workspace --all-targets
cargo test --workspace

Files touched: edda-ledger/src/ledger.rs, edda-ledger/src/domain.rs, edda-ask/src/lib.rs, edda-serve/src/api/events.rs

---

Phase 3: Clean up remaining types + restrict sqlite_store visibility (1 PR)

Goal: Move remaining types to domain.rs, rename DepRow, and seal the sqlite_store module.

Step 3.1 -- Rename DepRow to DependencyEdge

Only DepRow has a genuinely unclear name. Others (DeviceTokenRow, DecideSnapshotRow, SuggestionRow, BundleRow, TaskBriefRow) are clear enough -- YAGNI on renaming them.

Step 3.2 -- Move bidirectional types to domain.rs

Move DeviceTokenRow, DecideSnapshotRow, SuggestionRow, BundleRow, TaskBriefRow, DependencyEdge (ex-DepRow), ImportParams to domain.rs. Leave pub use crate::domain::* re-imports in sqlite_store/types.rs for internal use.

Step 3.3 -- Change sqlite_store visibility to pub(crate)

In edda-ledger/src/lib.rs:

pub(crate) mod sqlite_store;  // was: pub mod sqlite_store

This is the payoff -- no downstream crate can reach sqlite_store::* directly anymore.

Step 3.4 -- Update lib.rs re-exports

All types formerly accessed via edda_ledger::sqlite_store::Foo must now be re-exported from lib.rs:

pub use domain::{
    // Category A (already done in Phase 1)
    PatternType, DetectedPattern, PatternDetectionResult,
    VillageStats, VillageStatsPeriod, DomainCount, DayCount,
    OutcomeMetrics, ExecutionLinked,
    // Category B (Phase 2 + 3)
    ChainEntryView, DependencyEdge,
    // Category C (write-path)
    DeviceTokenRow, DecideSnapshotRow, SuggestionRow, BundleRow, TaskBriefRow,
    ImportParams,
};

Remove the existing pub use sqlite_store::{...} block entirely.

Step 3.5 -- Fix downstream import paths

Crate	File	Old path	New path
edda-serve	src/lib.rs:3788,3819	edda_ledger::sqlite_store::DeviceTokenRow	edda_ledger::DeviceTokenRow
edda-serve	src/api/auth.rs:158	edda_ledger::DeviceTokenRow	no change (already correct)
edda-serve	src/api/snapshots.rs:129	edda_ledger::DecideSnapshotRow	no change
edda-ingestion	src/suggestion.rs:93-109	edda_ledger::SuggestionRow	no change
edda-cli	src/cmd_bundle.rs:454	edda_ledger::BundleRow	no change

Main fix: edda-serve/src/lib.rs tests use edda_ledger::sqlite_store::DeviceTokenRow -- change to edda_ledger::DeviceTokenRow.

Step 3.6 -- Verify

cargo fmt --check
cargo clippy --workspace --all-targets
cargo test --workspace

Files touched: edda-ledger/src/domain.rs, edda-ledger/src/lib.rs, edda-ledger/src/sqlite_store/types.rs, edda-serve/src/lib.rs

---

Visibility Summary (End State)

Type	Current visibility	Target visibility
DecisionRow	pub (re-exported from lib.rs)	pub(crate) -- internal to edda-ledger
DecisionView	pub (re-exported from lib.rs)	pub -- the domain contract
ChainEntry	pub (re-exported)	pub(crate) -- internal
ChainEntryView	(does not exist)	pub -- new domain type
PatternType	pub (re-exported)	pub -- domain enum (moved to domain.rs)
DetectedPattern	pub (re-exported)	pub -- domain type (moved to domain.rs)
PatternDetectionResult	pub (re-exported)	pub -- domain type (moved to domain.rs)
VillageStats family	pub (via sqlite_store path)	pub -- domain types (moved to domain.rs)
OutcomeMetrics	pub (not re-exported from lib.rs)	pub -- domain type (moved to domain.rs)
ExecutionLinked	pub (not re-exported from lib.rs)	pub -- domain type (moved to domain.rs)
DeviceTokenRow	pub (re-exported)	pub -- domain input type (moved to domain.rs)
DecideSnapshotRow	pub (re-exported)	pub -- domain input type (moved to domain.rs)
SuggestionRow	pub (re-exported)	pub -- domain type (moved to domain.rs)
BundleRow	pub (re-exported)	pub -- domain type (moved to domain.rs)
TaskBriefRow	pub (re-exported)	pub -- domain type (moved to domain.rs)
DepRow	pub (re-exported)	Renamed to DependencyEdge, pub
ImportParams	pub (re-exported)	pub -- kept (moved to domain.rs)
sqlite_store module	pub mod	pub(crate) mod -- sealed

---

Risk Assessment

Risk	Impact	Mitigation
Phase 2 to_view() performance on hot paths	Low -- clone cost negligible vs SQLite I/O	active_decisions_limited already caps at 500 rows
ChainEntry to ChainEntryView naming	Aesthetic	Follow established *Row to *View pattern
edda-ask is_active field in DecisionHit	API change if removed	Keep field, derive from status -- backward compatible
Phase 3 breaking sqlite_store:: imports	Compilation error	Caught by cargo check, fixed in same PR
edda-bridge-claude DetectedPattern name collision	None -- bridge has its own separate struct	Confirm no import path conflict

---

PR Sequence

1. PR A -- refactor(edda-ledger): extract domain types to domain.rs (GH-378) -- Phase 1
2. PR B -- refactor(edda-ledger): migrate DecisionRow to DecisionView in Ledger API (GH-378) -- Phase 2
3. PR C -- refactor(edda-ledger): seal sqlite_store module, clean up type visibility (GH-378) -- Phase 3

Each PR is independently shippable and verifiable. Phase 2 is the riskiest; Phases 1 and 3 are mechanical.

[fagemx]

Work completed. PR created: #385

All 3 phases implemented in a single PR:

• Phase 1: domain types extracted to domain.rs
• Phase 2: Ledger API returns DecisionView instead of DecisionRow
• Phase 3: sqlite_store sealed as pub(crate), DepRow renamed to DependencyEdge

All CI checks passing locally (cargo check, clippy -Dwarnings, fmt, 106 tests).