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>
1.4 KiB
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_estimatedandentities_extracted(raw counts — informative) - Skip
rateandeta_minutesunless 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