fix(adapters): shared retry helper + run_log failure_class + enable RSS (issues #1 #2 #9)

- adapters/__init__.py: add http_get() unified retry (429/5xx only, max 2
  attempts, capped exp backoff) + AdapterHTTPError carrying failure_class;
  SourceAdapter.last_failure_class set on failure for pipeline capture.
- arxiv/github/huggingface/hackernews/reddit: route HTTP through http_get.
  Preserves GitHub 403 rate-limit retry and Reddit 403/429 fast-bail.
- schema.sql + pipeline.py: add run_log.failure_class column; rollup most-
  severe class across sources (5xx>4xx>429>error>zero_fetch>ok).
- pipeline.py: ENABLE RSS in ENABLED_SOURCES (was registered, disabled).
- RSS smoke test surfaced 3 broken feeds (anthropic 404, googleai 404,
  metaai 301) — left as-is, captured in feed_failures; URL fix is separate
  discovery task, not guessed.

Verified: full dry-run fetches all 6 sources; github live fetch OK;
Reddit 429 fast-bail preserved; no import/syntax errors.

docs/Deployment-Plan.md

@@ -1,42 +0,0 @@
-# Deployment Plan — Athena MVP
-
-## Prerequisites
-- Docker installed on the target host
-- Network access to the 6 source APIs/feeds (arxiv, github, huggingface, hackernews, reddit, rss_feeds)
-- `GITHUB_TOKEN` available as an environment variable (optional, but raises the GitHub rate limit from 60/hr to 5000/hr)
-- `HUGGINGFACE_TOKEN` available as an environment variable
-- A local Ollama instance running `llama3.2:1b`, or an alternate reachable inference backend if swapping — per the model-agnostic `summarize(text) -> (summary, model)` contract
-- Hermes cron infrastructure available and able to invoke `oracle-pipeline.sh`
-
-## Setup
-1. Clone `main` (not a milestone branch) onto the target host
-2. `pip install -r requirements.txt` if present; otherwise confirm stdlib + `requests` are available
-3. Run `schema.sql` against a fresh `oracle.db` — this file is git-ignored and created locally, never committed
-4. Export required environment variables (`GITHUB_TOKEN`, `HUGGINGFACE_TOKEN`) — never hardcode these
-5. Build and run inside Docker with the 150MB memory cap and non-root user enforced, per the PRD platform requirements
-6. Manual smoke test: run `python3 pipeline.py` once and confirm ingest → store → summarize → score completes without errors before handing off to cron
-
-## Cron / Scheduling
-1. Confirm `oracle-pipeline.sh` is the entry point Hermes cron calls
-2. Schedule for 13:00 UTC daily
-3. Add a lock file or PID check so overlapping runs can't happen if a prior run is still in progress
-4. Confirm the cron environment actually carries the exported tokens — cron environments are frequently minimal and won't inherit an interactive shell's exports
-
-## Hermes Integration
-1. Confirm the wrapper script's exit codes are meaningful (0 = success, non-zero = failure) so Hermes can act on them
-2. Define where Hermes should look for pipeline output/logs
-3. Decide on a failure-notification path (Hermes alert, log flag, etc.) — **not yet specified, needs a decision**
-
-## Monitoring
-1. Aggregate logs from each pipeline stage (ingest, store, summarize, score)
-2. Track theme-scan new-arrival counts per cycle per theme — this is the core signal the falsification logic depends on, so it deserves visibility beyond raw logs
-3. Add a heartbeat/dead-man's-switch alert if a scheduled run doesn't fire, rather than relying on someone noticing missing data days later
-4. Watch memory usage against the 150MB cap under real production load, not just dev conditions
-
-## Rollback
-1. Back up `oracle.db` before any schema change — it's git-ignored and not recoverable from the repo itself
-2. If a bad deploy breaks the pipeline, revert to the last known-good commit on `main` and redeploy the Docker image
-3. Check falsification state (new-arrivals counters) after any rollback — rolling back mid-window could distort the 7-day dead-thesis calculation if not handled carefully
-
----
-*Draft prepared by Claude from the README, whitepaper falsification logic, and MVP-PRD platform requirements on `main`. The Hermes failure-notification path is the one open decision blocking this from being final.*

docs/MVP-PRD.md

@@ -1,161 +0,0 @@
-## Chapter 1: Vision and Scope
-
-### Elevator Pitch
-
-Athena is an autonomous research intelligence engine that cuts through high-volume, fragmented signals by ingesting from multiple sources, surfacing cross-source convergence, and using falsification to distinguish real momentum from noise. While the initial focus is on AI signals, the system is designed to work with any class of signals. It delivers actionable insight into emerging trends and capability gaps while remaining model-agnostic and lightweight enough to run autonomously.
-
-### 1.1 Vision
-
-#### Why are we building it?
-
-The AI space produces an overwhelming volume of new research, tools, discussions, and model releases every day. Individual sources only provide partial views, making it difficult to distinguish genuine, sustained trends from one-day spikes. Without a system that can detect convergence across sources and validate momentum over time, real opportunities tied to emerging capability gaps are missed.
-
-#### What happens if we don’t build it?
-
-Without this capability, builders and researchers will continue to operate with fragmented, noisy signals. Early indicators of meaningful trends will remain hidden, decisions will stay reactive, and the ability to spot validated cross-source momentum before it becomes obvious will be lost.
-
-#### When must it be done?
-
-The foundational ability to reliably ingest, score, and validate signals through falsification must be established before meaningful trend detection and opportunity mapping can occur. This forms the core of the MVP and must be in place to enable the system to deliver on its intended value.
-
-### 1.2 Personas and Archetypes
-
-See committed document:  
-**`docs/Personas-and-Archetypes.md`** (on `MVP-milestone` branch)
-
-**Summary of scoped personas and archetypes for MVP:**
-
-**Personas**
-- Pers-1 (Bob) – Sector Trend Tracker (New to AI)
-- Pers-2 (Alice) – Content Creator
-- Pers-3 (Sam) – Hermes Research Agent
-
-**Archetypes**
-- Arch-1 (Small Scrappy VPS)
-- Arch-2 (Research Consumption Layer)
-
-All user stories in this PRD are scoped to combinations of the above.
-
-### 1.3 Use Case Priority Taxonomy
-
-This PRD focuses on defining the core functionality required for MVP. It also catalogs use cases and requirements across V1.0 – V1.5 to maintain context. The primary goal is to deliver a working MVP, with future PRDs derived from the remaining prioritized content.
-
-We will use the following prioritization model:
-
-- **MVP**: The short list of P1 use cases required to prove the concept with a working prototype.
-- **P1**: Use cases that are fundamental to successfully implementing the product vision.
-- **P2**: Use cases that add strength, convenience, and quality to the product vision.
-- **P3**: Use cases that bring additional value but can be cut if time or resource constrained.
-
-## Chapter 2: User Stories (Bob)
-These user stories are based on the personas and archetypes document contained in this repo.  
-
-Chapter 2.1 - Bob's user stories
-
-**As Bob, I want to…**
-
-**Bob-1.** Automatically receive daily updates on new AI innovations without having to manually check multiple sources.
-
-**Bob-5.** See emerging trends and differentiate durable signal from temporary or artificial hype.
-
-**Bob-10.** See when the same idea or pattern is appearing across multiple independent sources (GitHub, arXiv, Reddit, HN, HF).
-
-**Bob-15.** Identify emerging capability gaps or opportunities early, before they become widely obvious.
-
-**Bob-20.** Have research that gives me confidence it is exhaustive and vetted.
-
-**Bob-25.** Adjust or alter the underlying data feeds and weights so I can tune the accuracy and relevance of the output.
-
-**Bob-30.** Understand why a particular signal is considered strong or weak (e.g., cross-source convergence or falsification results).
-
-Chapter 2.2 - Alice's user stories
-As Alice, I want to…
-Alice-1. Integrate deep, vetted research directly into my existing content production pipeline so I can reduce manual research time.
-Alice-5. Query the research system with follow-up questions to explore specific angles or topics on demand.
-Alice-10. Have my tools automatically receive curated, high-signal research so I can focus on content creation instead of information filtering.
-Alice-15. Get research outputs in a structured format that my existing AI tools and workflows can consume without manual reformatting.
-Alice-20. Quickly surface non-obvious insights and patterns from research data to develop more compelling content angles.
-Alice-25. Control which research sources and signals are prioritized so the output stays aligned with my content focus and audience.
-Alice-30. Understand the reasoning and supporting evidence behind key research findings so I can speak to them confidently in my content.
-
-## Chapter 3: Requirements
-Requirements defined as what the product / system must do, differentiated from what the persona can accomplish. Requirements are defined to meet the needs of use cases as well as the architectural system design.
-
-High level design (refer to ***TBD_Design.MD for full design details)
-High-Level Design
-.
-├── Runtime Environment
-│   ├── Linux
-│   └── Docker (containerized)
-│
-├── Core Components
-│   ├── Database: SQLite
-│   ├── Scheduling: Cron
-│   └── Runtime: Python
-│
-├── Connectivity
-│   ├── Outbound (Internet)
-│   │   ├── HTTP client for data feeds (RSS, cURL, optional Playwright)
-│   │   └── OpenAI-compatible inference endpoints
-│   ├── Inbound (Internet)
-│   │   └── HTTP server endpoint (MCP + external consumers)
-│   └── Internal (Intranet)
-│       └── HTTP client for local inference (e.g. Hermes)
-│
-├── Storage
-│   ├── File system (daily digest artifacts stored outside container)
-│   └── Temporary working storage during pipeline execution
-│
-├── Configuration & Secrets
-│   ├── Research topic manifest (feeds, URLs, declarations)
-│   ├── System settings (YAML)
-│   └── Secrets (.env)
-│
-├── Business Logic / Pipeline Flow
-│   ├── Starting trigger
-│   ├── Preflight checks
-│   ├── Query feeds → Temporary result storage
-│   ├── Vet and promote final results to database
-│   ├── Optional daily digest generation
-│   └── Cleanup and sleep
-│
-└── Observability
-├── Structured logging
-├── Diagnostics and instrumentation (inside Docker)
-└── Health/status reporting
-
-3.1 Setup and configuration (REQ-SNC-XX)
-Requirements for initial setup, deployment configs, updating, and uninstall
-    REQ-SNC-05 -, with outbound access to the internet and in/outbound access to the underlying OS network
-    REQ-SNC-10 - The installation process shall be a single command which can be run interactively or silently
-    REQ-SNC-15 - The insallation shall utilize best-practice settings and secrets storage
-    REQ-SNC-20 - 
-
-3.2 Platform requirements (REQ-PLT-XX)
-    REQ-PLT-05 -  All processes will run as standard user (no admin / sudo elevation necessary)
-    REQ-PLT-10 -  ...
-    REQ-PLT-15 -  The system shall be Docker based limited to 150MB of memory
-Requirements addressing what OS and hardware support is in scope
-3.3 Performance and scalability (REQ-PERF-XX)
-3.4 Instrumenation and diagnostics (REQ-DIAG-XX)
-3.5 
-### 3.1 Reliability
-
-REQ-REL-05: Once setup and configured, the system will reliably operate without interaction from the user.
-REQ-REL-10: The system shall automatically retry failed source fetches with exponential backoff.
-REQ-REL-15: The system shall not lose previously stored data on restart or failure.
-REQ-REL-20: The daily pipeline shall complete successfully even if one or more sources are unavailable.
-
-3.3 Observability and Diagnostics
-REQ-DIAG-05: The system shall produce structured logs with timestamps and severity levels.
-REQ-DIAG-10: A health check endpoint or command shall report overall system status and last successful run.
-REQ-DIAG-15: Run logs shall capture per-source success/failure and basic metrics (items fetched, stored, failed).
-
-3.4 Security 
-REQ-SEC-05: All external HTTP calls shall use TLS.
-REQ-SEC-10: No secrets shall be hardcoded or stored in plaintext.
-REQ-SEC-15: The system shall support least-privilege access for outbound API calls.
-
-3.5 Integration and extensibility 
-REQ-INT-05: The system shall expose research output in a structured, machine-readable format (e.g., JSON files or API) consumable by external tools.
-REQ-INT-10: The adapter layer shall support adding new sources without modifying core pipeline logic.

docs/Personas-and-Archetypes.md

@@ -1,59 +0,0 @@
-# Personas and Archetypes (Derived from /main)
-
-**Status**: First Draft – Derived from existing docs on `main`  
-**Source**: README.md + whitepaper.md (branch: main)  
-**Date**: 2026-07-08
-
-## Overview
-
-This document extracts the implied users and operating contexts directly from the current documentation on the `main` branch. It serves as the baseline before we expand or refine.
-
----
-
-## Personas
-
-### Pers-1 (Bob) – Sector Trend Tracker (New to AI)
-- Is relatively new to AI and the broader space.
-- Wants to stay current with trends in AI (and potentially other sectors) without getting overwhelmed.
-- Needs a way to keep up with the high volume of new research, tools, and discussions with minimal ongoing effort.
-- Benefits from a system that filters noise and surfaces what actually matters.
-
-### Pers-2 (Alice) – Content Creator
-- Runs a YouTube channel and an X account with 25k followers.
-- Goal is to grow her audience significantly (targeting 1M followers).
-- Needs help doing research across AI and related topics.
-- Wants to convert research signals into interesting, timely, and compelling content for her audience.
-
-### Pers-3 (Sam) – Hermes Research Agent
-- Is a Hermes agent profile with its own memory and endpoint connection.
-- Acts as the dedicated research team member for an AI-first development team.
-- Needs to stay current on a defined market segment (AI for the MVP; extensible to other segments later).
-- Consumes structured signals from Athena to support ongoing research and decision-making within the team.
-
----
-
-## Archetypes (Operating Environments)
-
-### Arch-1 (Small Scrappy VPS)
-- Small, low-budget, and scrappy VPS environment.
-- Used primarily for learning and early prototyping.
-- Requires a small-footprint workload that can be memory-constrained so it doesn’t destabilize the host system.
-
-### Arch-2 (Research Consumption Layer)
-- Functions as a consumption layer for Athena’s research output.
-- Designed to support downstream AI systems (examples: MCP tools, LoRA adapters, or other agent profiles).
-- Focuses on making Athena’s signals and summaries easily consumable by other systems rather than direct human use.
-
----
-
-## Notes & Limitations (from /main)
-
-- The current documentation does **not** describe team or multi-user usage.
-- Emphasis is on autonomous operation and signal integrity.
-- Polished human-facing interfaces (e.g., daily digest) are not yet built.
-
----
-
-## Next Steps
-
-This version incorporates the updated personas and archetypes.

docs/Prioritized-Task-List.md

@@ -1,42 +0,0 @@
-# Prioritized Task List — Athena MVP
-
-Tied to the personas and requirements in `MVP-PRD.md`. Ordered by phase; within each phase, roughly in the order they should be tackled.
-
-## Phase 1: Get Running Daily
-- [ ] Verify the cron entry (`oracle-pipeline.sh`) fires reliably at 13:00 UTC under Hermes
-- [ ] Confirm `pipeline.py` runs the full ingest → store → summarize → score cycle without manual intervention
-- [ ] Add a lock/guard so a slow run can't overlap with the next day's cron trigger
-- [ ] Validate all 6 adapters (arxiv, github, huggingface, hackernews, reddit, rss_feeds) independently — one adapter failing shouldn't kill the whole run
-- [ ] Confirm environment-only secrets (`GITHUB_TOKEN`, `HUGGINGFACE_TOKEN`) resolve correctly in the cron context (cron environments are often stripped down compared to an interactive shell)
-
-## Phase 2: Core Functionality
-- [ ] Confirm `schema.sql` initializes `oracle.db` cleanly and stays idempotent across repeated runs
-- [ ] Verify `theme_scan.py`'s 4-theme tagging (tool-call, context, compute, trust) against a few real days of data
-- [ ] Confirm the falsification counter (new arrivals per cycle) is genuinely idempotent — re-running against unchanged data must yield 0 new
-- [ ] Wire `summarize.py` to degrade gracefully when the Ollama endpoint (`llama3.2:1b`) isn't reachable — ingestion, scoring, and theme-scan must keep running without it
-- [ ] Confirm `archive.py`'s cold-storage rotation doesn't delete data still needed inside the 7-day falsification window
-
-## Phase 3: Observability & Reliability
-- [ ] Add structured logging per pipeline stage (ingest, store, summarize, score) with pass/fail per adapter
-- [ ] Surface theme-scan counts (new arrivals per theme per cycle) somewhere inspectable, not just buried in log files
-- [ ] Add a daily heartbeat/health check so a silent failure (e.g. cron didn't fire at all) is detectable rather than just showing up as missing data later
-- [ ] Decide and implement retry/backoff behavior for adapters that hit rate limits (especially GitHub without a token: 60/hr)
-
-## Phase 4: Human Consumption Layer
-- [ ] Extend `query.py` to support Bob's cross-source convergence lookups and Alice's curated-research pulls
-- [ ] Define the output format(s) for a "trend confirmed" vs. "trend killed" verdict (per the 7-day dead-thesis rule)
-- [ ] Decide how Alice's content pipeline actually consumes Athena's output — file drop, API, direct DB read — this is currently undefined
-
-## Phase 5: Validation & UAT
-- [ ] Run the pipeline unattended for at least one full 7-day falsification window
-- [ ] Manually verify at least one theme through to a real "confirmed" or "killed" verdict
-- [ ] Walk Bob's and Alice's user stories from `MVP-PRD.md` end-to-end against real output, not synthetic data
-- [ ] Confirm memory stays under the 150MB cap under real daily load, not just in a light dev test
-
-## Phase 6: Hermes Integration
-- [ ] Confirm `oracle-pipeline.sh`'s contract matches what Hermes cron expects (exit codes, output location)
-- [ ] Decide how Hermes is notified on pipeline failure vs. success — not yet specified
-- [ ] Confirm the non-root execution requirement is actually satisfied inside the Hermes-invoked environment, not just in local Docker testing
-
----
-*Draft prepared by Claude from the MVP-PRD, Personas doc, and README/whitepaper on `main`. Open items flagged "not yet specified" need a decision before Phase 4–6 can be considered done.*