WingedGuardian/GENesis-AGI

Bug src/genesis/knowledge/orchestrator.py skips a source whose content hash is unchanged, but when a source's content has changed, re-ingesting it writes the new version's knowledge units and never retires the previous version's units. Both versions stay recallable side by side, so recall can return outdated statements next to current ones with nothing marking which is current. (The in-batch SUPERSEDED path only handles a unit replaced within one batch; it does not retire a prior source version.) Fix On re-ingest of a changed source, retire (supersede, not hard-delete) every unit belonging to that source's previous version, in the same transaction that commits the new units; drop their vectors on the existing post-commit path. Regression test: ingest v1 of a source, ingest a changed v2, assert recall returns only v2 units and v1 units are marked superseded with a pointer to the re-ingest. Follow-on (separate, larger) The pending four-arm knowledge-base retrieval test (plain / context

Problem web_fetch (src/genesis/mcp/health/web_tools.py) has three gaps for JavaScript-rendered pages (inbox evaluation NGC-69, 2026-10-05): Empty app shells count as success. A JS-only site that returns HTTP 200 with an empty shell is returned as a successful fetch and never retried with a JS-capable backend. urls batches hard-fail without API_KEY_TINYFISH — there is no local JS fallback for multi-URL fetches. The only local JS path is Crawl4AI, which launches a fresh Playwright Chromium per call, is reached by the auto chain only on bot-challenge pages, and is not declared in pyproject.toml (a fresh install does not get it). Proposal (ordered) Fix the chain first (engine-independent): detect an empty/JS-shell response (e.g. tiny extracted text with a script-heavy body, or known SPA root markers) and retry it on the JS-capable rung. Declare Crawl4AI properly or mark it optional with a clear "not installed" reason. Add lexmount/moli (Apache-2.0, local, no Chromium, CDP/WebDriver co

Problem Genesis cannot tell which of its skills are used. Both hooks that record tool activity skip the Skill tool (scripts/hooks/session_observer_hook.py, scripts/hooks/cc_span_hook.py), and loop_closure_status reports most library skills as uninstrumented. A 14-day transcript measurement (inbox evaluation, 2026-09-27) found skill loads concentrated in one skill (~75% genesis-development), and several skills nudged by the skill-injection hook in many sessions and loaded zero times. New skills are added regularly with no way to learn whether they fire. Proposal A read-only skill_usage_status health MCP tool, built as glue over transcripts Claude Code already writes (no new hook on the hot path): Stream transcripts for Skill tool loads and SKILL.md reads; join with the skill catalog (.claude/skills, src/genesis/skills, the install-local skill library), the per-session skill-injection nudges, and dispatch skill_tags. Report per skill: loads, reads, times nudged, nudge-to-load conversion

Problem Genesis has no property-based or mechanically checked tests. Enumerated: no hypothesis dependency in pyproject.toml, zero test modules import it; verification elsewhere is example-based unit tests plus LLM-adversarial review. Example tests check the cases someone thought of; the recurring defect class in this repo is the case nobody thought of (parser edge cases, size-bound overruns, ranking ties). Proposal Add hypothesis as a dev/test dependency and write properties for a small first set of pure, invariant-critical functions. Candidates (each to be confirmed as pure and side-effect free before writing properties): scripts/hooks/shell_parse.py — guards depend on it, and it is known to mis-parse line continuations and quoted heredoc bodies. Properties: tokenizing never raises on arbitrary text; a command built from known-safe segments joined by &&/; is split into exactly those segments; quoted content is never reported as a separate command. scripts/hooks/hook_output.py — t

Problem browser_snapshot (src/genesis/mcp/health/browser.py) returns the page's accessibility tree with no element references, so browser_click / browser_fill and friends must be given a CSS or text= selector that the model writes itself. That is the hallucination surface: the docstrings already carry the symptoms (ambiguity errors on text= matches, guidance to prefer hand-crafted specific selectors). Proposal (adapt, not adopt) Indexed element addressing, the pattern used by browser-use/jev-ultrafast and by Microsoft's Playwright MCP: browser_snapshot assigns a short ref to every interactive element ([e12] button "Submit"), from one atomic snapshot. browser_click, browser_fill, browser_press_key (and other element-targeting tools) accept either a ref or the existing selector. Selectors keep working unchanged. Refs are scoped to the snapshot that issued them; after navigation or a DOM change that removes the element, using a stale ref fails with a clear "stale ref, re-snapshot" error