Longhouse Backend
FastAPI backend and CLI package for Longhouse.
Install
uv tool install longhouse
longhouse-server serve
Full docs and the recommended hosted/self-host flows live in the main repository README: https://github.com/cipher982/longhouse
Provider capability evidence
Reference-based factory proofs use a dedicated read-only S3-compatible store,
configured through PROVIDER_CAPABILITY_BLOB_S3_* in the root .env.example.
This is separate from tenant media storage; no ambient AWS credentials are used.
An unconfigured resolver rejects reference-proof publication explicitly.
The Runtime Host verifies every referenced object's length and SHA-256 before acceptance, retaining attested metadata rather than copying evidence bytes. Existing inline proofs remain immutable and readable. Evidence downloads require owner-capable authentication; managed-session credentials cannot read them.
Repairing held interactions
The live catalog owns provider-wait lifecycle. Execution end revokes held permissions and managed-push provider questions, but does not delete history or expire durable Longhouse questions merely because activity is stale. Run-less legacy exits are matched only to an unambiguous owning thread/run that started before the exit; later executions remain untouched.
Catalog maintenance also repairs historical no-expiry waits, stale runtime
pointers, and run/connection rows contradicted by recorded execution exits.
Run this in the Runtime Host's environment so catalogd_paths() uses its active
live-store configuration. It talks to the single catalog writer, not SQLite:
import json
from datetime import UTC, datetime
from zerg.catalogd.client import call_catalogd_sync
from zerg.services.catalogd_supervisor import catalogd_paths
report = call_catalogd_sync(
catalogd_paths()[1],
"interaction.expire_due.v2",
params={"now": datetime.now(UTC).isoformat(), "dry_run": True},
timeout_seconds=60,
)
print(json.dumps(report, indent=2))
Set dry_run to False to apply the currently evidenced repairs, or add
session_id to scope either operation to one session. Reports name affected
interactions and runs. Repeated application is idempotent. Neither this repair
nor normal lifecycle cleanup edits archive transcripts or activity timestamps.
Repairing imported Cursor activity clocks
Older Cursor imports could use ingestion time as session activity. The engine
now reads provider metadata and matching managed turn receipts instead.
longhouse-engine parse <agent-transcripts/...jsonl> prints last_activity
from that same source resolver; a missing source clock is not evidence for a
historical correction.
After verifying the source clock, use the same catalog client with method
storage.cursor.activity.repair.v2 and parameters session_id,
expected_started_at, expected_last_activity_at (the current stored values),
source_started_at, source_last_activity_at (the verified provider values),
now, and dry_run. Timestamps are ISO-8601. Preview with dry_run=True,
then apply with False. Both clocks are compared before writing, preventing
an older audit from overwriting concurrent updates. Source creation may move
earlier, never later, and must precede source activity. Source activity cannot
exceed the expected stored activity. This also repairs old imports that
fabricated both creation and activity clocks.
This corrects timeline recency without rewriting immutable transcript objects.
1 maintainer
Release files for longhouse 0.1.50
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| longhouse-0.1.50-py3-none-any.whl | Python 3 | none | any | Details |
Release files / longhouse-0.1.50-py3-none-any.whl
| Download URL | longhouse-0.1.50-py3-none-any.whl |
|---|---|
| Size | 12.8 MB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
857e9028252a70dbb7d604820988764e0858d5bce2d46db51634a7a9ef12f726
|
|
BLAKE2b-256 checksum How to use checksums |
700936e9c38e137fb501634a877a2b5b30f45eccb4d3713d5ac5c26ceb49c080
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 26, 2026.
Transparency log
