feat: exclude_from_graph for graph metrics; record coreness validation finding - #6
Merged
Merged
Conversation
…-cause) Validated k-core coreness against the real ~1000-note work vault: it does NOT track durable knowledge. The top core is dominated by machine-generated hubs (daily digest, ingest log, action/open-actions registers) plus the recurring dated meeting stream, with human maps-of-content stuck mid-core. An exclude_from_graph experiment showed the metrics only clean up with aggressive curation. Conclusion recorded: coreness is a structural-centrality descriptor, not a durability axis; durability stays deferred to the Phase 3 two-strength signal, and Phase 5 must not gate protect/forget on coreness. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… metrics Machine-generated hub notes (a daily digest linking to hundreds of notes, the ingest log, action/open-actions registers) dominate the link graph and distort coreness, components, orphans and islands. The new [health] exclude_from_graph config (glob patterns matched against a note's title, basename, and path) drops matching notes and their edges from the graph BEFORE those metrics are computed, so the dashboard reflects human-authored structure. Exclusion is graph-only: the content detectors (dangling_link, ambiguous_link, para_drift, oversized) still run over excluded notes. A --exclude-from-graph CLI flag overrides the config for ad-hoc runs. Verified end-to-end on the real vault: excluding the automation hubs plus the recurring meeting stream drops max k-core 13 -> 7 and lets the human maps-of-content rise into the top core. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e26e456133
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
| base := strings.TrimSuffix(filepath.Base(path), ".md") | ||
| for _, pat := range patterns { | ||
| if ok, _ := filepath.Match(pat, title); ok { |
There was a problem hiding this comment.
When a user supplies a malformed glob in [health].exclude_from_graph or --exclude-from-graph (for example, an unescaped [ in a note title), this call discards filepath.ErrBadPattern and treats it as a non-match; the health command then reports graph metrics with the intended exclusions silently not applied. Since this feature is meant to support graph-metric experiments, silently computing the wrong graph can invalidate the results; return/report the match error before computing metrics.
Useful? React with 👍 / 👎.
….Match Addresses the PR review on exclude_from_graph: - Reject malformed glob patterns up front. matchesExcludePatterns discarded ErrBadPattern, so a bad pattern (e.g. an unclosed "[") silently excluded nothing and graph metrics were then computed over the unfiltered graph, quietly invalidating the experiment. buildGraphExcluding now validates every pattern via validateExcludePatterns and returns an error naming the offending pattern, failing the health run (CLI and the /api/health dashboard path) instead of producing a wrong result. - Match with the slash-based path package, not OS-dependent path/filepath. Note paths are stored vault-relative and slash-separated, so path.Match / path.Base give the documented "globs do not cross /" semantics on every OS. Docs (CONFIG.md, rendered config.toml comments) updated to path.Match. New test TestExcludeFromGraph_MalformedPatternErrors covers both RunHealthFull and the stats-only GraphHealth path. https://claude.ai/code/session_01QJ1WxqGMfCTuBGgCygW1jU
Bring in the multi-vault web refactor (one global web launchd service) and the health->audit CLI grouping. Clean auto-merge; no conflicts. The stale per-vault web assertion in scripts/acceptance.sh is fixed in the follow-up commit.
…t one The multi-vault refactor made the web launchd service one machine-global job (local.hebb.web), retiring per-vault web plists, but scripts/acceptance.sh still asserted the per-vault glob local.hebb.*.web.plist, which the global plist can never match (install/run.go notes the same). That left the "web launchd plist rendered" check failing on current main and on any branch merge-tested against it. Assert the exact global plist local.hebb.web.plist instead. https://claude.ai/code/session_01QJ1WxqGMfCTuBGgCygW1jU
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the Phase 2 coreness validation gate and ships the option it pointed to.
The validation finding (recorded in METABOLISM.md)
Validated k-core coreness against the real ~1000-note work vault. It does not track durable knowledge and the gate fails as originally framed. The maximum core is dominated by machine-generated hubs (the daily digest at degree 297, the ingest log, the action-review and open-actions registers) plus the recurring dated sync/meeting stream, with person notes mixed in; the human maps-of-content sat mid-core (k=8 of 13), only 1 of ~25 reaching the top two core levels. Coreness tracked raw degree closely (19/30 overlap), so it is essentially "centrality in the operational mesh". Conclusion: coreness is a structural-centrality descriptor, not a durability axis; durability stays deferred to the Phase 3 access/stability signal, and Phase 5 must not gate protect/forget on coreness.
The feature
[health] exclude_from_graph(glob patterns matched against a note's title, basename, and vault-relative path) drops matching notes and their edges from the graph before components, coreness, orphans, leaves, and islands are computed, so the dashboard's graph metrics reflect human-authored structure. Exclusion is graph-only: the content detectors (dangling_link,ambiguous_link,para_drift,oversized) still run over excluded notes. A--exclude-from-graphCLI flag overrides the config for ad-hoc runs. Default is empty (vault-agnostic).Real-vault re-measurement (through the binary)
So the option works but is partial: it cleans the graph metrics, it is not a durability silver bullet. The honest durability signal is Phase 3.
Full suite green; verified end-to-end on the real vault (read-only, temp index).
🤖 Generated with Claude Code