tegwick
3347aa5469
`ADHOC-YYYY-MM-DD` is unique per date but not per repository, so any two repos
opening an ad-hoc on the same day collide. The 2026-08-26 fleet projection
reset refused 9 records for exactly this reason.
Canon (work-record-types_v0.1, CUST-WP-0066) settled the form as
`{PREFIX}-WP-ADHOC-YYYY-MM-DD`, filename unchanged, and grandfathered existing
ids on the condition they are never *silently* re-derived. This is the explicit
migration that clause allows for.
The hub id is derived from the record id, so a changed id is a different
record: stale state_hub_*_id fields are dropped and fix-consistency re-derives.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
|
||
|---|---|---|
| deploy/k8s/qonto-assistant | ||
| docs | ||
| railiance | ||
| research | ||
| scripts | ||
| specs | ||
| src/qonto_assistant | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .dockerignore | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| Dockerfile | ||
| INTENT.md | ||
| LICENSE | ||
| Makefile | ||
| pyproject.toml | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
qonto-assistant
Policy-governed Qonto domain API and MCP assistant for Binky (and later multi-tenant dogfood).
One choke point for bank access across every coding agent and harness. Clients never hold the Qonto API key. v1 policy: read for awareness only — no spend, no volume-cost actions.
Start here
| Doc | What |
|---|---|
INTENT.md |
Why this exists; boundaries |
specs/ArchitectureBlueprint.md |
Architecture, phases, policy model |
research/2026-07-21-mcp-gateway-and-governed-domain-assistant.md |
External + internal research |
docs/operator-runbook.md |
How to run and verify Phase 1 (REST) |
docs/mcp-integration.md |
How to run and verify Phase 2 (MCP) |
Status
Phase 1 runtime is implemented:
- Python 3.12 service under
src/qonto_assistant/ - default-deny YAML policy
- Qonto read-only client (
organization,transactions) - REST endpoints:
/v1/health,/v1/accounts,/v1/transactions,/v1/snapshot - audit metadata, rate limiting, concurrency bounds, tests
Phase 2 (MCP surface, workplans/QONTO-WP-0003-mcp-surface.md) is
finished: a streamable-HTTP MCP adapter is mounted at /mcp on the same
capability core and policy kernel as REST — proven identical by test, not
just by construction (tests/test_policy.py, tests/test_audit_parity.py)
— with tools qonto_org_summary, qonto_list_transactions, and
qonto_cost_run_rate_hints. The endpoint is gated by a shared-secret bearer
token (QONTO_ASSISTANT_MCP_TOKEN); see docs/mcp-integration.md for the
auth model, its explicit gap vs. the OIDC/workload target (no issuer exists
in this fleet yet), and the shared multi-harness client config snippet. The
finance-qonto-read agent-harness tool profile is documented (qonto-assistant
side) but not yet registered in agent-harness itself — separate repo,
separate workplan.
Current verification:
PYTHONPATH=src ../state-hub/.venv/bin/python -m pytest→31 passedpython3 -m compileall src tests scripts../state-hub/.venv/bin/python scripts/smoke_rest_api.py --python ../state-hub/.venv/bin/python../state-hub/.venv/bin/python scripts/smoke_mcp.py --python ../state-hub/.venv/bin/python
Local fixture-backed smoke mode is available through QONTO_FIXTURE_DIR, so the
service can be exercised without real Qonto credentials. The REST smoke checks
both a 31-day recent snapshot and a 90-day recurring-cost snapshot; the MCP
smoke additionally exercises the bearer-token auth gate and an out-of-catalog
tool deny path.
Phase 3 (flex-auth resource finance.qonto.read, graduated quotas,
redaction profiles) is not started — see workplans/QONTO-WP-0003-mcp-surface.md
closure notes for the seed.
Normal local workflow, when toolchain support exists:
make install-dev
make test
make run
Related
- OpenBao lane:
tenants/binky/qonto-api(ops-wardenbinky-qonto-api) - First pull / CostRunRate:
binky-controlBINKY-WP-0005