Files
dotfiles/claude/memory/feedback-bmf-ingestion-rate.md
T
David F GliddenandClaude Opus 4.7 e9e772d69c memory: bundle accumulated 04-17/26 + lock ARC about-page architecture
Safety checkpoint before deep-audit Phase 0 of the ARC repo. Steward-authorized
commit-everything for rollback safety.

ARC architectural locks (2026-04-26 evening):
- Path 1 enfilade structure (separate Colophon and Lex items)
- 8-door enfilade locked: Colophon · Lex · Framework · Vignette · Attention ·
  Chamber · Tools · Now (+ Bio quiet link)
- Adsum and threshold-hic as two distinct texts on the reflowed About page
  (steward verbatim: "They are certainly not the same text")

ARC consolidation pass (canonical tracker project-arc-rework.md, +~700 lines):
fold 04-23 evening (Norris read), 04-24 (lex-method authored, posture cluster,
§XII Sidenotes, ARC CLAUDE.md cleanup), 04-25 (marks cluster, colophon-at-scale,
full Vico/Harrison lex-chain), 04-26 (chamber-library walk, cluster scaffolds,
canonical-tracker discipline surfaced).

Sibling-file integration: four 2026-04-26 frame files folded into the canonical
tracker (Integrations A/B/C/D) with INTEGRATED redirect notices retained as
audit trail.

New durable feedback memories:
- feedback-canonical-workstream-tracker-discipline (umbrella drift surfaced
  2026-04-26 by steward; proposes /wake-up + /wrap-up amendments)
- feedback-catalogues-stale-walk-trees (steward feedback on chamber-library
  catalogue currency)

Implementation plan drafted for the coming week: Phase 0 deep audit → Phase 5
cleanup, with steward additions on second pass (deep audit; Chamber v1 as own
browsable archive; clean rebuild of cluster sources rather than moving test
artifacts as canon).

Also bundled (untracked accumulation since 04-17):
- ~24 session memory + ledger files for 04-17 through 04-26 work
- ~10 feedback memories (BMF + ARC + working-method)
- 5 project memories (lex-as-method, strunk-white queue, plus today's four)
- 4 user memories (duality-rules, formation-practice, foundation-work, humic-layer)

Steward-side modifications also in this commit: ~/CLAUDE.md, bin/bmf-start.sh,
open-tasks.md, project-focus-april-may.md, session-2026-04-17 — all
pre-existing, not from today's session.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 14:52:14 +02:00

1.4 KiB

name, description, type, originSessionId
name description type originSessionId
BMF connector_status rate/ETA is unreliable Don't quote the `rate` or `eta_minutes` from BMF connector_status as a time estimate — ingestion is bursty, rate changes substantially, linear extrapolation misleads. feedback e60f4993-8250-41bb-a95f-c288da448be5

BMF connector_status rate/ETA — don't trust the extrapolation

Rule: When reading mcp__capablemind__connector_status, do not report the rate or eta_minutes fields to the steward as if they were reliable predictors of completion time.

Why: BMF ingestion exhibits a burst pattern — periods of slow steady throughput interleaved with rate surges. The eta_minutes is computed by linear extrapolation from instantaneous rate, which doesn't capture the burst behavior. Steward has observed this repeatedly across vault ingestion runs. Quoted observation (2026-04-18): "the ETA is not a good indicator because the rate will change with the burst ingestion pattern that seems to take hold."

How to apply: When reporting progress during long-running ingestion:

  • Report processed / total_estimated and entities_extracted (raw counts — informative)
  • Skip rate and eta_minutes unless explicitly asked — or caveat them heavily
  • Frame duration in coarse terms ("several hours" / "let it run overnight") based on total size, not fine-grained ETAs
  • Poll intermittently if asked; don't build plans around a specific finish time