- snoozeItem: write status:"pending" + snoozed_at (audit trail) instead
of status:"snoozed", which was invisible to findDue/findUpcoming
- findDue/findUpcoming: include status==="snoozed" for backward compat
with any pre-existing snoozed entries in the store
- listItems default filter: show snoozed entries (they are active)
- _findEntry: remove dead exact-match branch (exact ⊆ startsWith)
- ScheduleEntry typedef: add optional snoozed_at field
- Tests: add coverage for snoozed-entry visibility in findDue,
findUpcoming, and the list command
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tracks a future review item gated on M010 (schedule system) — two
weeks after M009 closes, assess promote-only rule adoption.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previous fix commit (e0d1352c4) only updated .gitignore to allow
src/resources/extensions/**/*.d.ts but did not actually re-commit
the file contents that were deleted in snapshot 405381985. Restoring
from bcf79a713 (the latest version with all exported symbols).
Files restored:
- remote-questions/config.d.ts
- search-the-web/url-utils.d.ts
- sf/agentic-docs-scaffold.d.ts
- sf/code-intelligence.d.ts
- sf/doc-checker.d.ts
- sf/doctor.d.ts
- sf/gitignore.d.ts
- sf/native-git-bridge.d.ts
- sf/paths.d.ts
- sf/preferences-models.d.ts
- sf/preferences.d.ts
- sf/repo-identity.d.ts
- sf/trace-collector.d.ts
- sf/types.d.ts
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The acquiring-skills skill was a personal developer workflow with
hardcoded paths that did not apply to general sf users.
Rationale for removal rather than generalization:
- SF bundled skills are already generic and installed for all users.
- External skills are consumed via the Anthropic marketplace.
- Per-project custom skills are covered by the creating-skills skill.
Resolves self-feedback sf-mookqlyr-snco79.
Replace the developer-specific acquiring-skills skill with a generic
version that any SF user can follow.
Changes:
- Removed all personal references (/home/mhugo/code/, mikki-bunker,
ace-coder, letta-workspace, dr-repo, singularity-package-intelligence)
- Replaced Method 2 (rsync from local repos) and Method 3 (rsync from
bunker) with a generic local-project porting workflow
- Replaced Trusted Sources table with only public, universally
accessible repositories (anthropics/skills, singularity-forge)
- Kept all safety rules (inspect scripts, no curl|bash, untrusted
sources require approval)
- Kept the Adaptation Checklist for porting foreign skills to sf
- References the Anthropic skills marketplace as the primary source
Resolves self-feedback sf-mookqlyr-snco79.
Prevents pi runtime flow-audit from emitting false-positive stale-dispatch
warnings for slices that completed successfully on retry.
Problem: when a complete-slice unit is cancelled (e.g. provider quota error)
and then retried successfully, the prior cancelled journal/runtime state can
still trigger a flow-audit warning on the next session start. The detector
reads the cancelled unit-end event but does not check for later successful
retries or existing artifact files (#sf-moqv5o7h-vaabu6).
Fix: at auto-mode bootstrap, after cleanStaleRuntimeUnits, run a new
reconcileStaleCompleteSliceRecords() pass that:
- Lists all unit runtime records for complete-slice units
- Filters for terminal non-completed states (cancelled, failed, stale,
runaway-recovered)
- Checks DB slice status === 'complete'
- Checks SUMMARY.md exists with valid completed_at frontmatter
- Clears stale runtime records that pass both checks
Files changed:
- src/resources/extensions/sf/unit-runtime.js: add reconcileStaleCompleteSliceRecords
- src/resources/extensions/sf/auto-start.js: call it after cleanStaleRuntimeUnits
- src/tests/unit-runtime-reconcile.test.ts: unit tests for the new function
When offset or limit are specified, use Node.js readline streaming instead of
loading the entire file into memory. This fixes the truncation issue for large
files (>50KB) where the read tool would return truncated content even when
requesting a small slice.
- Add readLinesStreamed() for memory-efficient line reading
- Add countLines() for total line count without full read
- Use streaming path when offset !== undefined || limit !== undefined
- Keep existing full-file read path when no offset/limit specified
- Add tests for streaming behavior with large files
Fixes the long-standing issue where reading large files like src/headless.ts
(~50KB) with offset/limit would still hit truncation limits.
Adds three layers of defense against the M008/S03 failure mode where
bug-hunt findings referenced .ts files that had been deleted in a prior
corrupted snapshot commit (f712c339b), but .js versions with fixes survived.
1. Prompt-level safeguards:
- research-slice.md: researchers must verify file existence before listing
paths in findings
- plan-slice.md: planners must confirm files exist before including them
in task plans
- execute-task.md: executors must verify files exist before editing;
escalate as blocker if missing
2. Runtime pre-flight validation:
- system-context.js: validateTaskPlanFiles() extracts backtick-wrapped
paths from task plans and checks existence before dispatch
- Missing files trigger a warning injected into the execute-task prompt
- Logs warning for observability
This prevents the research→plan→execute pipeline from propagating stale
file paths that cause phantom work, runaway guard intervention, and
flow-audit failures.
Fixes: sf-moqgvdi7-mxc1sr (flow-audit:repeated-milestone-failure)
Related: M008/S03 bug-hunt cluster
Token count now only triggers a warning when accompanied by a primary
signal (high tool calls, long elapsed time, or many changed files).
This prevents false positives on units doing real work with large
context models, where 25+ tool calls can legitimately burn 1M+ tokens.
Also renames 'session tokens' to 'unit tokens' in guard messages to
clarify that the metric is delta-from-unit-start, not cumulative.
Fixes sf-moqewawp-ijwjjt
Pure-function tests for applyRelationBoost (55b14c3f7) cover the
math, but the wired-through path (createMemoryRelation → boost picked
up by getRelevantMemoriesRanked → reordered output) had no
end-to-end test.
New test:
1. Creates memories a, b, c with orthogonal embeddings
2. Mocks gateway to return a query vector aligned only with a
3. Wires a→b with related_to (confidence 1.0)
4. Asserts ranking: a (cosine top) > b (boost from a) > c (unrelated)
Locks the contract that the boost actually fires through the full
pipeline, not just the pure helper. 16 → 17 tests in the file.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The header listed "artifact I/O, detection, flag flips, resolution" but
not the carry-forward injection (claimOverrideForInjection /
formatOverrideBlock) or the memory persistence calls now embedded in
both writeEscalationArtifact (continueWithDefault path, b9bff3762
sibling) and resolveEscalation (00c13bc5a). These are load-bearing
behaviors a contributor should know up front.
Also folded the "SF's local ADR-011 is 'Swarm Chat'" disambiguation
note into the header (matches the convention the rest of the
disambiguation sweep set).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
memory-sleeper.ts had no file header and the "memory" prefix is
misleading — it's a runtime tool-output watchdog (detects repeated
bash failures, too-large tool results) that emits steers, completely
unrelated to memory-store / memory-relations / memory-embeddings.
A contributor reading directory listing top-down would reasonably
assume this file participates in the same pipeline as the other
memory-*.ts modules. Header now states the historical naming and
points readers in the right direction.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous header had two stale references:
- "buildMemoryLLMCall pattern, prefers a dedicated embedding-capable
model" — describes a hook that actually returns null on every call
(the Pi SDK has no provider-neutral embedding API yet).
- "queryMemoriesRanked falls back to keyword-only scoring" —
function doesn't exist; the real consumer is
getRelevantMemoriesRanked, and the fallback is static (confidence
× hit_count), not keyword.
Updated to describe the actual three-stage read pipeline (cosine →
relation-boost → optional rerank) and the soft-degrade fallback to
static ranking when the gateway is offline.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The file header described an aspirational design ("LINK actions
emitted by the memory extractor, or future /sf memory link CLI") that
never matched code reality. As of this session:
Writers shipped:
(a) applyMemoryActions auto-links co-extracted memories with
related_to (b9bff3762)
(b) /sf memory import loads explicit edges from JSON
Read consumers shipped:
(1) getRelevantMemoriesRanked graph-boost (55b14c3f7)
(2) sf_graph MCP tool (pre-existing)
Updated the header so a contributor reading top-down sees the
current data flow, not the original plan.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Updates 23c5de38b (which flagged the table as storage-only) to reflect
that 55b14c3f7 wired the ranker consumer (graph-boost in
getRelevantMemoriesRanked) and b9bff3762 wired the writer
(co-extraction linkage in applyMemoryActions). The graph-aware
pipeline is now end-to-end live, with named relation types,
auto-linking confidence (0.5), intra-pool boost, and damping (0.4).
Honest description for contributors reading top-down.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
