CurryComb

CurryComb performs asynchronous backlog reconciliation and ratified-plan materialisation across the Ting estate: it continuously reconciles Forgejo issues against curated knowledge, derives structural judgments from versioned Datalog semantics, and declares — never executes — the effects accepted rulings imply. Domain councils decompose work; CurryComb preserves their evidence and mechanically projects the ratified result.

Conceptual reconciliation flow

Forgejo webhook / sweep
        │
        ▼
Issue reconciler ──► HydraMem fact query (Mnestic projection)
        │
        ▼
Datalog closure / ruling          (versioned, reviewed rule files)
        │
        ▼
Effect declaration                (pure data; no credentials, no execution)
        │
        ▼
Credentialed effector             (a separate component holds Forgejo
                                    mutation credentials and executes)

When a ruling needs evidence that does not exist — a missing predicate — the reconciliation does not block. Instead, it routes a human/Rig evidence request to the appropriate curator. The answer is appended to the OKF bundle as an authoritative assertion (or ratification, rejection, retraction) and then projected into Mnestic, where a later, idempotent pass of the reconciler will find it and complete the ruling.

Authority in one sentence

OKF (HydraMem's Markdown bundle) is the authoritative evidence store; Mnestic is a persistent but rebuildable, queryable interpretation of that evidence inside HydraMem — see docs/adr/0001-okf-mnestic-authority-boundary.md.

What CurryComb refuses

• Blocking on humans. Interaction is fully asynchronous; missing evidence becomes a request, not a wait.
• Treating LLM output as authority. Model output is proposal, never knowledge; only OKF records are authoritative.
• Choosing product decomposition. Domain personas and their council own repository, Session, scope, acceptance, and authority boundaries. CurryComb may validate and materialise a ratified split; it never invents one.
• Applying Forgejo mutations from the reasoning process. The reasoning process only declares effects; a separate credentialed effector executes them.
• Requiring embeddings. Embedding indexes are optional and selective, never a default or a correctness dependency.
• Loading the whole estate into memory. Queries run against bounded projections under explicit memory/query budgets.
• Assuming webhook order, exactly-once delivery, or first-comment semantics. Every pass is idempotent and order-tolerant.
• Becoming a central availability dependency. OKF-only and ephemeral in-memory interpretations must always remain possible; no service may be architected to require one shared live Mnestic.

Status

Slice 0: architectural decisions and shared schemas — identifiers, assertions, provenance, judgments, rule digests, questions, and declared effects, with deterministic serialization and bounded default budgets. Effects are only declared here, never executed.

Slice 1: Forgejo convergence without intelligence. The workspace now contains six crates: currycomb-schema, currycomb-forgejo-client, currycomb-projection, currycomb-intake, currycomb-effector, and currycomb-cli. Three binaries are wired together:

$ cc-reconcile --from input.json > declaration.json   # runs the projection
$ cc-apply      < declaration.json > result.json     # applies via Forgejo
$ cc-sweep      --from input.json                    # emits reconcile requests

The canonical-comment projection owns a single logical canonical comment per issue. Concurrent creators race and the lowest comment identifier wins; later marked comments are reduced to a short pointer to the winner. Repeated and reordered events converge to one canonical comment with byte-identical state. The effector is binary-only so no reasoning process can link in mutation code — see docs/adr/0002-canonical-comment-projection.md.

Slice 1 deliberately has no LLM, no Mnestic facts, and no Datalog rules. Those land in Slice 3.