Skip to content

refactor(memory,P1): provider-neutral distill backend and real extractor readiness #951

Description

@seoseo-ai

Problem

Piri remains the user-facing runtime for the affected bridges, but PR #948 currently uses codex exec as the secondary structured-fact extractor. That creates an independent Codex credential and CLI-version dependency even when the active conversation model is Kimi K3 or GLM-5.2.

The first four-node live round-trip exposed two false-ready states:

  • soonwook: Codex 0.137.0 had the required flags and codex login status reported logged in, but a body-free live extraction failed authentication.
  • dungae: Codex 0.121.0 both lacked --ignore-user-config / --ignore-rules and had the same live authentication failure.

The bridge and doctor still reported provider=Piri and readiness=ready because they did not validate the secondary extractor contract.

Goal

Define one provider-neutral distill contract so Piri, Codex, Claude, or another approved extractor can produce the same validated fact envelope without changing sink semantics. Keep Codex as a compatible backend/fallback, not a mandatory hidden dependency.

Acceptance criteria

  • Introduce an explicit distill backend interface and configuration with a safe, backwards-compatible default.
  • Require the same strict JSON schema, provenance, bounds, body-free error taxonomy, cost gates, idempotency keys, and local/Honcho/Wiki sink behavior for every backend.
  • Support a Piri-native extractor path so K3/GLM nodes do not require a separate Codex login when policy selects Piri.
  • Make doctor/readiness report conversation-provider and distill-provider health separately.
  • Validate minimum CLI capabilities and perform an approved body-free live-auth probe; do not treat login status alone as proof.
  • Add a backend matrix and hermetic plus isolated live round-trip tests.
  • Do not change existing production defaults until parity and privacy tests pass.

Related: ccc-node #948, #950, seoyoon-family-wiki #3193, jinwon-int/piri#1.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions