Skip to content

[Astra] Establish the initial FlossWare Memory service contract and implementation #1

Open

Description

@sfloess

Goal

Build Memory as an independently deployable, project-independent FlossWare service shared by Loom, Claude Ensemble (CE), and future consumers. Consumers must not maintain competing memory implementations.

First implementation slice

  1. Specify language-neutral REST request/response schemas and structured errors.
  2. Implement append, fetch-by-ID, and bounded search operations.
  3. Use PostgreSQL as the initial durable backend behind a storage interface.
  4. Enforce explicit global/project/session-task scopes and project isolation by default.
  5. Support idempotent writes; conflicting reuse of an idempotency key with different content must fail explicitly.
  6. Preserve stable identity, source/provenance, timestamps, scope, and correlation metadata.
  7. Provide distinct liveness and readiness checks; storage failure must not look like an empty successful search.
  8. Add deterministic contract, isolation, idempotency, ranking/limit, and unavailable-storage tests.
  9. Expose MCP as a thin adapter over the same domain/service behavior after the REST contract is stable.

Explicit non-goals

  • No orchestration, model routing, Learning, Thompson, Graph/Knowledge, alerts, or messaging in this repository.
  • No mandatory embeddings/vector database for the baseline. Start with deterministic lexical/full-text retrieval and add hybrid/vector retrieval only behind the same contract and relevance tests.
  • No application-specific Claude Code hooks or installer logic.
  • No local inference or external model calls.

Acceptance criteria

  • REST contract and error model documented.
  • Append/get/search operations implemented and tested.
  • Idempotent retries are safe; conflicting idempotency-key reuse returns a structured conflict.
  • Cross-project reads are denied unless explicitly authorized.
  • Query limits, ordering, and empty-result behavior are stable.
  • Storage unavailability is visible in readiness and produces an actionable operation error.
  • MCP adapter shares the same service logic and contract tests.
  • Java and other language clients can use the HTTP contract without requiring a Python SDK.

Architecture context

FlossWare ADR-0032 establishes language-neutral multi-protocol service contracts: REST is the canonical baseline; MCP is first-class but should be a thin adapter over canonical REST/shared service logic; additional transports can be added without duplicating domain behavior.

Implementation note

The GitHub repository currently appears to be empty. Initial source files could not be committed through the contents API because no parent commit exists. Bootstrap the repository with an initial commit, then implement this issue on a feature branch and submit a reviewable PR.

Activity

  1. sfloess commented on Oct 23, 2026

    @sfloess
    MemberAuthor

    Implementation is now underway in PR #5: initial PostgreSQL-backed REST service, direct ID retrieval, paginated enumeration/export, lexical search as a separate endpoint, project-bound token isolation, idempotency, readiness, and integration tests against PostgreSQL. Messaging is explicitly deferred. The PR is awaiting CI and review; this does not yet satisfy the full issue.

  2. sfloess commented on Oct 23, 2026

    @sfloess
    MemberAuthor

    Update: PR #5 has been squash-merged. The PostgreSQL-backed REST service is now on main. The new PostgreSQL integration workflow passed: 7 tests passed, covering health/readiness, project-token isolation, raw record round-trip, enumeration, idempotency and conflict handling, lexical search separation, and admin-only global writes. The stored-data contract documentation remains in PR #4. This is the initial REST slice; MCP integration and a consistent-snapshot export remain follow-up work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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