Cron Job: Brief quotidien éditorial

Brief Publié le 2026-07-05

Cron Job: Brief quotidien éditorial

Job ID: af0fe442cf56

Run Time: 2026-07-05 18:19:56

Schedule: 0 18 *

Prompt

[IMPORTANT: The user has invoked the "editorial-review-cycle" skill, indicating they want you to follow its instructions. The full skill content is loaded below.]

name: editorial-review-cycle

description: "Produce periodic (daily/weekly) editorial reviews from tracked topics in a structured memory system — parallel research, signal synthesis, topic updates, cross-link generation, hypothesis creation, integrity verification, topic ideation, and batch article production via delegate_task."

version: 1.18.0

author: Hermes Agent

license: MIT

platforms: [linux, macos, windows]

metadata:

hermes:

tags: [editorial, review, briefing, memory, veille, research, synthesis, article, ideation]

related_skills: [editorial-agent-system, news-briefings, blogwatcher]

prerequisites:

require_skills: [editorial-agent-system]

Editorial Review Cycle

Produce a complete periodic review (daily or weekly) from a tracked topic set within a constitutional editorial memory system. This covers the full cycle: research → synthesis → memory update → hypothesis generation → cross-linking → integrity verification.

When to Use

The user asks for a "daily review", "weekly brief", "revue quotidienne/hebdomadaire"
You need to update tracked topics with new signals
The editorial memory system has been set up (agents + topics + constitution exist)
After a significant news event that affects multiple tracked topics
New: Module activation — the user says "active le module X" where X has a README, module_config, profile, and kanban in a modular layout

If the user asks to activate a module (e.g. "active le module revue_editoriale"), follow the activation sequence in Prerequisites above before producing any content. This is a distinct task from producing a review — it involves loading context, updating entity tracking, and establishing which subjects are being followed.

Prerequisites

The editorial memory system must exist. It can be in one of two layouts:

Direct layout — all files at /memory/ (canonical):

A 00_index.md listing all tracked topics
Topic files in topics/ with structure (contexte, faits marquants, questions ouvertes, sources)
Optionally: a constitution, agents, and hypotheses directories

Modular layout — module in one of two locations:

Primary vault path — /memory/modules/<module_name>/:

All paths relative to memory/modules/<module_name>/
A README.md describing the module's purpose and perimeter
A module_config.md with rules, naming conventions, and output destinations
A profile.md describing the assistant's role, posture, and method
Local memory in memory/ (index, entities, decisions, hypotheses, glossary)
Topic, brief, hypothesis files in their respective subdirectories

Hermes profile path — ~/.hermes/profiles/<profile_name>/modules_revues/:

Used when the editorial module IS a Hermes profile (e.g. revue_editoriale profile).
Check this path first if ~/.hermes/profiles/<module_name>/ exists and has a modules_revues/ subdirectory.
Structure is the same as the vault path: topics/, briefs/, hypotheses/, analyses/, agents/, sources/.
Session runs under the journal profile (not the editorial profile) — write files with the cross-profile tools (read_file, write_file, patch) using absolute paths. The cross_profile write guard does NOT apply to write_file (it only guards skills/plugins/cron/memories/ directories), so direct file writes through absolute paths work normally.
Some editorial files (like editorial_feedback/) may live under modules_revues/ or in the profile's own memories/ — check both.

Activation sequence for modular layouts: Before starting any work, always load the module's context files in order:

README.md — understand purpose and perimeter
module_config.md — learn rules, naming, output paths
profile.md — adopt the defined posture and method
kanban.md — see what's pending vs done
Local memory (memory/index.md, entities.md, decisions.md, hypotheses.md, glossary.md) — establish the current state

This establishes which paths to write to and what conventions to follow before any research or writing begins.

If neither layout exists, run the editorial-agent-system skill first to create the system.

Convention: /memory is the user-facing Obsidian vault. /opt/data/memory is reserved for the agent's internal technical memory (memory tool). Never write user-facing documents to /opt/data/memory. The module's own memory/ directory contains the local index, entities, decisions, hypotheses, and glossary.

Permission pitfall: /memory is often a separate mount point. If you get "Permission denied" writing to it, the user must chown it from the Docker host: chown -R <uid>:<gid> /memory (the uid/gid of the hermes user, typically 10000:10000).

Workflow

Phase 1: Reconnaissance

Determine the base path — check locations in priority order:
Hermes profile path: if the module name matches a directory under ~/.hermes/profiles/ AND that directory has a modules_revues/ subdirectory, the base path is ~/.hermes/profiles/<name>/modules_revues/.
Vault path: otherwise, if the user referenced a module, the base path is /memory/modules/<name>/.
Root vault: if neither applies, assume /memory/.
Read the module's context files (if modular): README.md, module_config.md, profile.md, kanban.md — these define perimeter, rules, and current state.
Read the index (<base>/00_index.md) to identify active topics, their priorities, and last-update dates.
Read each topic file to understand the current state, existing questions, and knowledge gaps.
Read local memory (<base>/memory/): entities.md (who/what is tracked), decisions.md (past editorial choices), hypotheses.md (active theses).
Identify which topics are stale — those without update in >7 days may need priority rescan.
Detect topic scope-creep that warrants splitting. A topic has grown too broad when:
It covers two distinct ecosystems with different toolchains, communities, and use-cases (e.g. edge_ai = embedded MCU/TinyML vs desktop/GPU local inference — separate hardware tiers, different frameworks, different user profiles).
A single "Faits marquants" section mixes unrelated categories (hardware announcements + software releases + geopolitical implications).
The topic's description in the index no longer captures all its subtopics. If you need a comma-separated list of 4+ subdomains in the one-liner, it is too broad.
The topic has >10 faits marquants and they naturally cluster into 2+ groups.
When in doubt: create the split as a new topic with status: brouillon and link both ways. A split can always be merged back; a bloated topic is harder to prune.

Phase 1.5: Topic & Article Ideation (Proposal Mode)

When the user asks "propose-moi des sujets/topics" or "propose-moi des idées d'articles" — a creative proposal step distinct from researching a named entity or writing a brief. This is a curatorial phase: look at what exists, what's happening, and propose what's worth adding or writing.

Sub-mode A — Proposing new topics from current signals

Trigger: User says "liste des sujets du moment", "idées de topics à ajouter", "quels sujets devrais-je suivre".

Read the current index (00_index.md) — identify existing topics, their priorities, and last-update dates.
Scan recent briefs (last 3-5 from briefs/daily/ and briefs/special/) — look for signals that don't have a natural topic home, or clusters of signals that warrant consolidation.
Propose as a structured list: each proposed topic with:
Slug (lowercase, hyphens)
Description (one-liner)
Priority (🔴/🟡/🟢)
Rationale — why this topic doesn't fit existing ones, why it matters now
Example content — what it would track (signals, actors, open questions)

Cross-reference with existing topics — avoid overlap. If a signal cluster fits an existing topic, say so rather than proposing a duplicate.
Present to user as a numbered list with clear rationale. Let them pick before creating.

Structure for presentation:

| # | Topic | Priorité | Description | Justification |
|---|-------|----------|-------------|---------------|
| 1 | `slug` | 🔴 | One-liner | Why now, what gap it fills |

Sub-mode B — Proposing article ideas with angles

Trigger: User says "propose-moi plusieurs idées d'article avec leur angle", "idées d'articles", "suggestions de contenu long".

This is a creative + editorial step. It combines knowledge of current events with a sense of narrative angle, structure, and tone. Each article idea should include:

Titre — the working title
Angle — what's the unique hook? Why this story, why now, from what perspective?
Structure — chapter/section breakdown (e.g. "chronologie + analyse + 3 scénarios")
Ton — enquête financière, récit d'impact, analyse stratégique, technique immersif, analytique provocateur
Contenu — what each section covers
Contre-épreuve — what the contrarian take would be (optional but encouraged)

Present as a structured list with clear distinction between articles:

### Article N : Titre
**Angle :** ...
**Structure :** ...
**Ton :** ...
**Contenu :** ...

Best practices for article ideation:

Distribute across active topics — don't propose 3 articles on the same subject
Vary the tones — one narrative, one analytical, one technical
Include a "contre-épreuve" or contrarian note within the angle to show balance
Propose 4-6 ideas for the user to choose from
When the user says "oui", proceed to produce them — use batch delegate_task (see "Batch article production" below)

Sub-mode C — Batch article production via delegate_task

Trigger: User says "oui" or "go" after you proposed article ideas, or asks you to write multiple articles at once.

Use delegate_task(tasks=[...]) in batches of up to 3 (per max_concurrent_children=3) to write articles in parallel. Each subagent needs:

goal — "Rédige un article long (~12 000 signes) en français sur [topic]. Sauvegarde dans [output path]"
context — must include:
All factual data the subagent needs (key numbers, dates, names, existing research)
The angle (what makes this article different)
The structure (chapter/section breakdown)
The tone (any style constraints)
Language requirement: "réponds en français" (subagents default to English otherwise)
toolsets — ["terminal", "file", "web"] for articles needing fresh research (web search + file write). The web toolset enables Network access in subagents.

Context structure template:

Contexte : [Key facts, dates, numbers, sources]
Angle : [Unique hook — why this story, from what perspective]
Structure : [Chapter breakdown with section descriptions]
Ton : [Voice, register, style notes]

Goal summary: [One-line reaffirmation]

After all batches complete:

Verify each file was actually created (ls -la on each output path)
Update 00_index.md — add each article to the outputs/ tree listing
Report to user: table with article title, file path, size

Pitfall — max_concurrent_children=3: If you send 4+ tasks in one delegate_task(tasks=[...]), it fails. Split into batches of 3. The second batch runs after the first completes. Total wall-clock time stays roughly the same since parallelism is per-batch.

Pitfall — subagent language: Subagents default to English for summaries. When the article must be in French, explicitly say "en français" in the goal and context fields. Add "Réponds en français — l'article doit être rédigé en français" at the start of the context.

Pitfall — subagent summary reliability: A subagent that says "article written to path X" may be wrong. Always verify file creation yourself in Phase 7 (integrity verification).

Pitfall — subagent file naming convention mismatch: Delegate_task subagents may create files with names that do not match the module's established convention. For example, a subagent told to create briefs/daily/YYYY-MM-DD.md may instead write 2026-06-16-brief-quotidien.md (appending a descriptive suffix because the prompt was more descriptive than the exact filename). After every delegate_task batch, run ls -la on the target directory and rename any files that deviate from the convention with mv via terminal. Then update any file references in the subagent's summary to match the renamed paths.

Phase 2: Research

Research method depends on context: live conversation vs automated cron, number of topics, and available extraction backends.

Mode A — Direct research (live conversations, 1-3 topics)

For simpler requests (1-3 topics) in a live conversation, research directly in the main thread. This avoids delegate_task overhead when the scope is narrow.

Launch parallel web_search calls across topics that need updating — send multiple searches at once, one per topic or signal type. Set limit=10 for broader coverage; default limit=5 may miss signals for fast-moving topics like geopolitics.
Extract detailed content from promising URLs. Two extraction paths:
web_extract(urls=[...]) — preferred for PDFs, API endpoints, plain-text pages. ⚠️ Only works when the configured web.extract_backend supports URL extraction. When the backend is ddgs (DuckDuckGo), web_extract fails with "DuckDuckGo (ddgs) is a search-only backend and cannot extract URL content."
browser_navigate(url) + browser_snapshot(full=True) — fallback when web_extract fails. Handles JS-heavy news sites (Al Jazeera, Guardian, etc.) better than curl. Use browser_get_images() for illustration context when relevant.
Decision tree: PDF/.md/.txt/API endpoint → curl. Everything else → try web_extract → fails? → browser_navigate + browser_snapshot.
Track progress with todo — mark completed topics so you don't miss one in a multi-topic brief.

Pitfall: web_search with DuckDuckGo backend returns results with titles and descriptions but web_extract cannot fetch the underlying page content. This creates a gap: you see that something exists but cannot access the detail. Always plan to browser-navigate to at least the top 1-2 results per topic to fill this gap.

See references/browser-content-extraction.md for a full step-by-step guide to the browser-based extraction workflow, known-working sites, and pitfalls.

Mode B — Parallel delegate_task (3+ topics, automated or deep research)

Use delegate_task to research each topic simultaneously (up to 3 per batch per the default max_concurrent_children=3). Pass toolsets=["terminal","web"] — the web toolset enables curl-based RSS/HTML fetching; browser is not needed for bulk text extraction.

Pitfall — max_concurrent_children limit: If you send 4+ tasks in one delegate_task(tasks=[...]) call, it fails with "Too many tasks: N provided, but max_concurrent_children is 3". Split into batches of 3. The second batch runs after the first completes, keeping total session time roughly the same (parallel is within each batch, not across batches).

Mode C — Catch-up batch (producing multiple missing briefs)

When the user says "lance les revues quotidiennes manquantes" or asks you to fill a gap of 3+ missing days, follow this workflow instead of producing briefs one at a time.

Trigger: User explicitly asks for "missing" or "rattrapage" briefs, or the file listing shows a multi-day gap between existing briefs and today.

Reconnaissance — List actual files on disk in briefs/daily/ and compare against the calendar. Check 00_index.md separately (it may be out of date). Identify each truly missing day and its day-of-week.

Batch research — Delegate research for the missing days via delegate_task(tasks=[...]) in batches of 3 (max_concurrent_children limit). Each subagent researches one day across all tracked topics. The context MUST specify:
The exact date (e.g. "jeudi 11 juin 2026")
All active topics to check (geopolitics Iran, agents AI, open source, etc.)
The format: faits marquants par sujet avec sources

Write in parallel — Once research returns for all days in a batch, create the brief files. Use the same frontmatter and structure as existing briefs (check an existing file for the exact format in use — the template in this skill may differ from what the module actually uses).

Update index — Add every new brief to both the tree listing and the "Suivis Actifs" table in 00_index.md. Update priorité and dernière mise à jour fields for topics that had new signals.

Handle quiet periods correctly -- For weekend days or days with no major news, do NOT fabricate content. Write briefs that explicitly document the silence: "Aucun signal nouveau detecte -- week-end". This is a legitimate editorial output.

Single-day rattrapage (1 missing day)

When only one day is missing and the collection cron failed (no RSS data available), produce a single rattrapage brief using web_search as fallback data source instead of delegate_task:

Diagnose the root cause first -- follow the diagnostic sequence above.
Research via web_search only -- since web_extract typically fails with DuckDuckGo backend, run 3-4 targeted parallel searches covering:
World news for the missing date (English)
French news for the missing date (French)
Topic-specific searches for tracked subjects (AI, geopolitics, tech)
Check the previous and following day's briefs to understand the narrative continuity
Mark the brief as rattrapage in both the frontmatter certification and the header:
Add RATTRAPAGE to the certification: field
Add a > ⚠️ note line explaining why the gap existed (e.g. collection cron crash)
Format follows the standard daily brief template -- same structure, same ALERTE/signal/hypothesis sections.
Update the brief index -- whether index_briefs.md or 00_index.md, add the new file to the chronological listing. The index may be severely stale (weeks out of date); update it fully rather than just appending.
Report the gap and its root cause to the user: what day was missing, why it happened (collection cron failure), and that it's now filled.

Pitfall — table row double-pipe in index: When patching 00_index.md to add new briefs to the tree, the patch tool may introduce || (double pipe) or ||| (triple pipe) prefixes on replaced rows. After every patch on the index file, verify with grep -nP '^\\|\\|' <file>. Fix any stray double-pipes by patching again with single-pipe rows.

Cron pipeline architecture (data collection → editorial production)

When setting up automated daily briefs, prefer a two-cron pipeline rather than a single monolithic cron:

Data collection cron (e.g. 16:00 daily): Runs a script= that curl-fetches RSS feeds with || true isolation. Uses news-briefings skill. Produces raw data in sources/rss/YYYY-MM-DD.md. Delivers a short Telegram summary.
Editorial production cron (e.g. 18:00 daily): Uses context_from=<job_id_of_collection_cron> to receive the collected data. Uses editorial-review-cycle skill. Produces the full editorial brief in briefs/daily/YYYY-MM-DD.md. Updates 00_index.md. Delivers to Telegram + local.

This separation has three advantages:

The collection script is crash-isolated — if a feed TCP-resets, only that feed is lost, not the entire editorial run
Each cron has a focused skill and toolset, reducing context waste
The editorial cron can be re-run independently (with cronjob(action='run')) if it fails, without re-fetching feeds

To create the editorial cron:

cronjob(
    action='create',
    name='Brief quotidien éditorial',
    schedule='0 18 * * *',
    skills=['editorial-review-cycle'],
    context_from=['<collection_job_id>'],   # receives collected data as prompt
    deliver='telegram:CHAT_ID,local',       # Telegram + local archive
    prompt="Produis un brief quotidien complet...",
)

Pitfall — context_from profile mismatch: The cron job that provides context (context_from) may run under a different Hermes profile than the editorial cron. Check the source cron's profile field in cron/jobs.json. If profiles differ, context_from may still work (the runtime fetches output from the shared output store), but test with cronjob(action='run') after creation to confirm data flows correctly.

Pitfall — context_from not persisted by cronjob API: The cronjob(action='update', context_from=[...]) API may save the update to the in-memory job object but NOT write it to ~/.hermes/profiles/<profile>/cron/jobs.json on disk. After updating via the API, always verify with a direct read of the JSON file:

python3 -c "import json; j=json.load(open(expanduser('~/.hermes/profiles/journal/cron/jobs.json'))); [x for x in j['jobs'] if x['id'] == '<job_id>'][0]['context_from']"

If context_from is None or missing, edit the JSON file directly with a terminal one-liner or patch — the cron scheduler reads from the JSON file, not from the API's in-memory state.

Pitfall -- silent duplicate brief from collection cron failure (cascade): When the data-collection cron fails (no output file for that date in cron/output/<job_id>/), the editorial cron that references it via context_from silently receives the previous day's data. It then produces a brief that is a near-duplicate of the previous day -- same alerts, same analysis, different filename. The gap and the duplicate are invisible from cron status alone.

Diagnostic sequence for a missing brief gap: When the user reports a gap in daily briefs:

List actual files on disk -- ls <module_base>/briefs/daily/. Compare against the calendar.
Check both cron output directories:
Collection cron output (cron/output/<collection_job_id>/): is there a file for the missing date? If absent, the collection run failed.
Editorial cron output (cron/output/<editorial_job_id>/): is there a file? If present but its final response reproduces the previous day's summary (same alerts, same date references), context_from fed stale data.
Produce a rattrapage brief (see "Single-day rattrapage (1 missing day)" below).

Pitfall -- recovering data from a failed collection cron: When the data-collection cron (e.g. news-briefings at 16:00) crashes with a Broken pipe (Errno 32) during output delivery, the cron shows last_status: "error" and its context_from payload may be empty. However, the stored output file on disk often survives intact -- the agent's data-collection script ran before the delivery crash. Always check the stored output before declaring data lost:

ls ~/.hermes/profiles/<collection_profile>/cron/output/<job_id>/

The stored output may be under the consuming profile's cron output directory (not the collection profile's) when profiles differ — e.g. collection cron has profile: "brief" but the editorial cron runs under journal. In this case, check both profiles' output directories:

# Check collection profile first
ls ~/.hermes/profiles/<collection_profile>/cron/output/<job_id>/ 2>/dev/null || echo "Not here"
# Also check the consuming (editorial) profile
ls ~/.hermes/profiles/journal/cron/output/<job_id>/ 2>/dev/null || echo "Not here"

The file follows the naming convention YYYY-MM-DD_HH-MM-SS.md. Read the full file — the collected data (RSS feeds, script output) is typically stored in a ## Script Output section or code block. The final error appears at the end of the file, separate from the collected data. If the data survived, extract it and proceed with the editorial production as normal. If the stored output file is absent or empty in both locations, only then fall back to running fresh research (live session) or reporting the failure (cron context).

Pitfall — context_from data truncated by context window limits: Even when the data-collection cron succeeds, the injected context_from data may be truncated when it exceeds the model's context window. The editorial cron receives only the first ~X tokens of the collection output; key signals at the end of the file (e.g. France 24 feed items, Guardian data) may be silently missing. Mitigation:

Always cross-check the stored output file on disk before trusting the injected data for completeness. Read the full stored output and compare against what you received in context.
If the stored output contains more data than the injected context, read the stored output directly as your primary data source for the editorial brief. The stored file is authoritative.
Archive the stored output to the editorial module's sources/rss/YYYY-MM-DD.md as usual — the injected data is a convenience copy, not the canonical source.
In the editorial cron prompt, add an explicit instruction: « Si les données injectées semblent tronquées, lis le fichier de sortie stocké sur disque dans le répertoire cron/output/<job_id>/ — il contient les données complètes. »

Pitfall — RSS archive path mismatch between cron stages: When the editorial module lives at the Hermes profile path (~/.hermes/profiles/<module>/modules_revues/) but the data-collection cron's archive instruction uses the vault path (/home/sebastien/.hermes/memory/modules/.../sources/rss/ or /memory/modules/.../sources/rss/), the RSS archive file may be written to the wrong path. Before relying on the archive file in sources/rss/YYYY-MM-DD.md:

a. Check both the profile path and the vault path: the data-collection cron may write to either location depending on its prompt.

b. If not found at either path, fall back to reading the stored cron output directly (~/.hermes/profiles/<collection_profile>/cron/output/<job_id>/YYYY-MM-DD_HH-MM-SS.md).

c. Write the archive file yourself at the correct path in the editorial module after extracting the data from the stored output.

d. Prevent future mismatches: add an explicit instruction to the data-collection cron’s prompt specifying the exact absolute path for the RSS archive that matches the editorial module’s actual location, not a convention-based path.

Cascading effect — the RSS archive was not saved either: A failed collection cron also crashes before it can write the RSS archive file to sources/rss/YYYY-MM-DD.md. After recovering data from the stored cron output, you MUST also manually write the RSS archive file at the correct module path. This is a separate step from producing the editorial brief — the brief only writes to briefs/daily/, not to sources/rss/. The RSS archive is the canonical data source for future reference and hypothesis cross-checking.

Mitigation: To prevent future losses, configure the data-collection cron with a script= parameter that writes raw data to sources/rss/YYYY-MM-DD.md in the editorial module. This decouples data collection from the agent’s output delivery — even if the agent crashes, the file persists on disk.

See references/catch-up-batch-worked-example.md for a concrete example of this workflow from an actual session (5 missing briefs filled, 13 June 2026).

For existing topics (updating with new signals):

Give the topic's current state and open questions as context
Ask for 4-8 key findings (not 50 — focus on signal)
Target Google News RSS via curl (reliable, no JS dependency)
Prefer getting results back as the subagent's summary (inline text) rather than scattering /tmp/*.md files which must be cleaned up later
If subagents do write temp files, collect and delete them in Phase 7

Quiet period handling: When research returns no signals for a topic (or all topics), do NOT fabricate content or pad with irrelevant news. Instead:

Mark each topic explicitly: "Aucun signal nouveau détecté — week-end/période calme"
Document module-level events as local signals (file updates, topic promotions, entity changes)
Include a "Prochaine vérification" section setting expectations for the next cycle
The brief is still valid — documenting silence is a legitimate editorial output
Avoid "Aucune actualité trouvée" as a blanket — qualify whether the silence is expected (weekend, holiday) or anomalous

For weekly reviews (synthesising from existing daily briefs): research scope is narrower. You already have 3+ daily briefs covering previous days — only research NEW signals since the last daily brief was produced. The bulk of the weekly review comes from synthesising the daily briefs, not from fresh research. Allocate 2-3 parallel subagents to the most active topics (typically geopolitics, agents AI, open source AI) for fresh signals only.

# Example pattern (pseudocode) for updating existing topics:
tasks = [
    {"goal": "Research recent developments in {topic}", "context": current_topic_text, "toolsets": ["browser","terminal"]},
    ...
]
results = delegate_task(tasks=tasks)

For creating a new topic from scratch (no existing signal base): use the 3-angle parallel research pattern. Spawn 3 subagents covering complementary dimensions of the same subject. This produces richer coverage than a single monolithic delegate:

Angle	What it covers	Example for "inférence locale"
Frameworks & tools	Moteurs d'inférence, versions, controverses, tendances logicielles	Ollama v0.30, LM Studio 0.4.0, llama.cpp b9495, vLLM, Jan, LocalAI, GPT4All
Hardware & benchmarks	GPU benchmarks, CPU/NPU comparison, nouvelle génération hardware, recommandations budget	RTX 5090/4090 benchmarks, Apple Silicon vs NVIDIA, NPU laptop limits
Models & applications	Modèles open-weight récents, quantification, cas d'usage concrets	Qwen 3.6-A3B, Gemma 4, Phi-4, Mistral Small 4, RAG local, agents

All three run in parallel via delegate_task(tasks=[...]). Give each the same high-level context (why this topic matters, what questions to answer) but a distinct goal per angle. Collect results, deduplicate, and synthesize into the topic file's structure.

See references/3-angle-research-template.md for a copy-paste template and a worked example from an actual session.

Phase 2.5: New Topic Creation (from scratch, within an existing module)

When the user asks to create a new topic in an existing module (e.g. "ajoute aussi en Topic : Eurailscout/Trealis, Altametris, Rail Open Lab"), this is an intermediate phase between Research and Synthesis. It involves researching multiple entities, writing a structured topic file, and updating the index — distinct from both updating an existing topic and creating a new module.

Trigger: User says "ajoute en topic", "crée un sujet sur", "add a topic about", or asks to document a new subject within an existing tracked set.

Workflow

Research each entity/subject via delegate_task:

Parallel research works well when the user names 2-4 specific entities. Launch one subagent per entity (up to 3 per batch). Each subagent's context must specify:

The full entity name and what it does
The domain context (railway, AI, etc.)
Format expected: activité, produits/services, pays, liens SNCF, actualités récentes

   tasks = [
       {"goal": "Research Entity A in detail", "context": "...", "toolsets": ["web"]},
       {"goal": "Research Entity B in detail", "context": "...", "toolsets": ["web"]},
       {"goal": "Research Entity C in detail", "context": "...", "toolsets": ["web"]},
   ]
   delegate_task(tasks=tasks)

Define the topic structure before writing. Two format variants:

Variant A — Signal-tracked topic (default): For topics that follow ongoing developments (regulations, markets, tech trends, geopolitics). This is the format used by most topics in the revue_editoriale module.

---
title: "Topic Title — description courte"
date: YYYY-MM-DD
updated: YYYY-MM-DD
status: actif
priority: 🟡
tags: [tag1, tag2]
sources: [Source1, Source2]
---

# Topic Title

> Suivi du sujet — one-line description.
> Dernière mise à jour : YYYY-MM-DD.

---

## Contexte

1-3 paragraphs explaining why this topic exists, what it covers, its significance.

## Signaux récents

| Date | Signal | Source | Priorité |
|------|--------|--------|----------|
| YYYY-MM-DD | Latest signal | Source | 🔴 |

Each row = one signal. Sort by date descending.

## Acteurs clés (optional)

Bullet list of key actors with brief description and status.

## Questions ouvertes

- Question 1?
- Question 2?

Variant B — Entity-focused topic (multi-actor domain): For topics where multiple organisations/products need structured profiles (e.g. railway inspection companies, drone manufacturers, space programs). Use type: topic, cycle: permanent, module: frontmatter fields.

---
title: "Topic Title"
date: YYYY-MM-DD
type: topic
cycle: permanent
priority: 🟡
module: revue_editoriale
---

# Topic Title

> One-line description.
> Créé le : YYYY-MM-DD
> Dernière mise à jour : YYYY-MM-DD

---

## 1. Contexte

## 2. Acteurs / Entités

### Entity A
| Champ | Valeur |
|---|---|
| **Statut** | Description |

### Entity B
...

## 3. Relations entre les entités

## 4. Actualités récentes

| Date | Fait | Acteur | Source |
|---|---|---|---|

## 5. Tendances clés

Variant C — Company/Product profile (single entity): For topics about a specific company, product, or technology where the primary value is its product catalog, competitive landscape, and use cases (e.g. LUNAAR smart glasses, Vectron X locomotive). Use type: topic, cycle: permanent, module: frontmatter fields.

---
title: "Company/Product Name — description"
date: YYYY-MM-DD
type: topic
cycle: permanent
priority: 🟡
module: revue_editoriale
tags: [tag1, tag2]
sources: [Source1, Source2]
---

# Company/Product Name

> One-line description.
> Créé le : YYYY-MM-DD
> Dernière mise à jour : YYYY-MM-DD

---

## 1. Contexte

1-3 paragraphs: what the company/product does, why it matters, market position.

## 2. Produits et solutions (if product-based)

| Produit | Usage | Certification | Description |
|---------|-------|---------------|-------------|

## 3. Acteurs / Entités

Table of key actors: company, role, details.

## 4. Concurrence et alternatives

| Produit | Concurrent | Forces | Faiblesses |

## 5. Actualités récentes

| Date | Fait | Source | Priorité |

## 6. Tendances clés

Bullet list of market/tech trends affecting this entity.

## 7. Liens

Cross-references to related topics (Variant A or B) that share domain or use cases.

## 8. Sources

Decision rule: Use Variant A for topics tracking ongoing signals and developments (most editorial topics). Use Variant B when the primary value is entity profiles and their inter-relationships, especially when the user named specific organisations as the reason for creating the topic. Use Variant C for single-entity company/product deep-dives where the focus is the product catalog, competitive landscape, and use cases rather than ongoing signal tracking or multi-actor dynamics.

Determine the right structure variant based on content type:
Multi-entity domain (e.g. Eurailscout+Trealis+Altametris): use Acteurs/Entités as the core section with entity sub-sections, plus a Relations diagram
Single-entity or product (e.g. Vectron X, TGV M): use sections like Technologie, Déploiement, Impact
Tracked trend (e.g. EU AI Act): use Signaux récents timeline + Questions ouvertes

Write the topic file in topics/:
For revue_editoriale under /memory/: topics/<slug>.md
For revue_editoriale as a Hermes profile: ~/.hermes/profiles/revue_editoriale/modules_revues/topics/<slug>.md
Same convention applies for analyses, hypotheses, and briefs — prepend the profile's modules_revues/ path when the module is a profile.
Only actions that target skills/plugins/cron/memories/ under another profile trigger the cross-profile write guard. Writing topics/, briefs/, hypotheses/, analyses/, or sources/ under modules_revues/ in another profile does NOT trigger the guard — use plain write_file.
Frontmatter with date:, type: topic, cycle: permanent, priority:, module:

Update the index (00_index.md) with:
Add the topic to the tree listing (under topics/ or at module root, matching the layout of existing topics)
Tree indentation pitfall: The tree listing in 00_index.md uses specific prefix characters (│ ├──, │ └──, ├──, └──). When patching, match the EXACT indentation of the line above your insertion point. Adding a topic with the wrong indentation prefix (e.g. │ ├── when it should be ├──) will break the visual tree structure. After patching, verify by reading the affected lines.
Add a row to the Suivis Actifs table with priority, date, and status
Update the Suivis Actifs pitfall: some table rows have a || or ||| prefix (double/triple pipe) instead of |. Match the EXACT prefix of the rows you're replacing. When adding a new row, use the same prefix as the row above it. After patching, run grep -rn '^||' <file> to catch stray double-pipe prefixes.

Update linked topics — If the new topic overlaps with existing topics, update those topics too:
Add a "Liens" section or new entries to their existing "Liens" section linking to the new topic
Bump their Dernière mise à jour date and add a note about the cross-reference

Update the hermes_agent.md module topic when the user asks specifically about Hermes Agent evolutions — see references/github-releases-changelog-scraping.md for the technique

Phase 2.6: External Source Ingestion from User-Shared Links

When the user shares a URL to an external tech blog, article, or source site (e.g. Korben, Hacker News, a GitHub repo), the agent should systematically evaluate and integrate it — this is a distinct pattern from web_search which discovers sources proactively. The user is handing you a source they already trust.

Trigger: User shares a URL with no explicit instruction, says "ajoute cette source", "regarde ça", "tu connais ?", or drops a link mid-conversation.

Workflow:

Extract the source — determine what the link points to:
Single article → extract content (try web_extract first, fall back to browser_navigate)
Blog homepage → identify key topics covered
GitHub repo → read README for purpose, features, stars

Assess relevance to tracked topics — read the full content (not just the title/description). Ask: does this contain a signal for an existing topic? A new source worth tracking? Both?

Three-path decision tree:
Path A — Signal only (single article with a news signal, source well-known): add the signal to the relevant topic file's Faits marquants / Signaux récents table. No source file needed.
Path B — New source worth documenting (blog regularly covers topics in scope, or unique domain expertise): create a source file in sources/source_<name>.md with description, tags, RSS feed (see step 5), and notable articles.
Path C — Both (article contains signals AND the source is new to the module): do both. Add signals to topics AND create a source file.

Add signals to topics — for Path A or C:
Identify which topic(s) the signal belongs to
Add a row to the Signaux récents table or append to Faits marquants with the date, signal description, source name, and priorité
Bump the topic's updated: date and subtitle
Add a brief link reference if the article was mentioned in a recent brief

Discover and document RSS feed — for Path B:
Try common WordPress feed paths: /feed/, /feed/atom/, /rss, /feed.xml
Use curl -sI <url> and check the Content-Type header — is it XML? If yes, it's a living RSS feed.
If the site is behind Cloudflare (403 + cf-mitigated: challenge), note it in the source file: "Bloqué par Cloudflare — pas intégrable dans collecte automatisée. Consultation manuelle nécessaire."
If the feed is accessible, add the URL to the source file and consider adding it to the collecte-veille.sh script or news-briefings skill's feed list.

Document the source — for Path B, create sources/source_<name>.md with:

# Source Name — Description

## Description
One paragraph: what the site covers, language, frequency, trust level.

## Flux RSS
- `<url>` — status (accessible / Cloudflare / dead)

## Tags
`tag1`, `tag2`

Update the index tree — add the new source file reference in the sources/ section of 00_index.md if the module tracks source files (check the tree structure first — some modules don't list individual source files in the index).

Report to user — tell them what you added and where. If Cloudflare blocks the RSS feed, mention it so they know automated collection won't work.

Pitfall — Cloudflare challenge blocks both curl and browser_navigate: Many tech blogs (Korben, Hacker News) use Cloudflare JS challenge. Neither direct curl nor browser_navigate can bypass it. In this case:

Search results (web_search) for site:domain.com can still surface article content
Manual consultation by the user is the only reliable access path
Document this limitation in the source file
Do NOT attempt to circumvent Cloudflare — it's a terms-of-service violation

Pitfall — RSS feed behind Cloudflare: Even the /feed/ URL may be challenged. Standard WordPress feeds at /feed/ are blocked by the same Cloudflare rules as the main site. Test the feed with curl -sI before declaring it accessible.

Pitfall — Korben-specific note: Korben.info is a French tech blog covering AI, Linux, open-source, robots, cybersecurity, and domotica. Its RSS (https://korben.info/feed/) is blocked by Cloudflare. It remains a useful manual-consultation source — see sources/source_korben_info.md for a complete profile.

Alternative: Activate an editorial agent (e.g. Contrarian) on a specific brief

When the user says "active l'agent contra/contrarian/contre-épreuve sur ce brief", they want the Contrarian agent's contre-épreuve workflow applied to a specific document. This is a distinct editorial action — not producing a new brief, but validating and challenging an existing one.

Trigger: "active l'agent [name] sur [document]", "lance le contra", "applique le controleur", "contre-épreuve sur".

Workflow:

Read the agent's profile — load agents/contrarian.md to understand its mission, workflow, format de sortie, and biais detection grid.

Read the target document — the brief or article the agent will review.

Apply the Contrarian format per the agent's template:
## Thèse originale (principe de charité) — reformulate the thesis fairly
## Antithèse — the opposing argument
## Scénarios alternatifs — minimum 2 (most likely if wrong, most disruptive if right but poorly framed)
## Biais identifiés — table with confirmation, disponibilité, autorité, groupe, ancrage, survie
## Verdict — ACCEPTÉ | ACCEPTÉ AVEC RÉSERVES | REJETÉ
Include a score de robustesse (1-10)

Save the contre-épreuve in analyses/contre-epreuve-<slug>-<date>.md

Update the index — add the contre-épreuve to the tree listing under analyses/

Present a summary to the user with:
Score de robustesse
Biais détectés (with impact level)
Scénarios alternatifs
Correctifs recommandés

Mode B — Multi-brief Contrarian (synthetic journal):

When the user says "passe au contra sur les N derniers jours" or asks you to apply Contrarian at the semantic level across a set of daily briefs, the goal is to challenge the dominant narratives of a period, not validate a single document.

Trigger: "passe au contra", "contre-épreuve sur les briefs de la semaine", "analyse les 5 derniers jours avec le contrarien".

Workflow:

Read all target briefs — read each daily brief from briefs/daily/ for the requested period.
Extract the N dominant theses — typically 3 (geopolitics, tech, markets). List each with its supporting evidence from the briefs.
Apply the Contrarian format to EACH thesis (not to each brief): ## Thèse originale → ## Antithèse → ## Biais identifiés → ## Scénarios alternatifs. Use the same biais grid as Mode A.
Save the contre-épreuve in analyses/contre-epreuve-<slug>-<date>.md
Integrate into a journal — the Contrarian output becomes Chapter 2-style rebuttals in a synthetic journal article (see "Synthetic journal from N days of briefs" below).
Update index — add to analyses/ tree in 00_index.md

Key difference from Mode A: Mode A validates a single document. Mode B synthesizes N documents into a meta-analysis. The Contrarian's output is not the final product — it feeds into a broader journal article that presents both the thesis and the counter-thesis.

Pitfalls:

Do not run Contrarian on each brief independently — that produces N shallow analyses. Apply it across the full period to get cross-cutting insights.
The biais grid applies to the corpus, not to individual claims. Bias de confirmation may manifest as the same story being covered from the same angle for 5 consecutive days.
Score de robustesse should reflect the full period, not the last day.

Alternative: Synthetic journal from N days of briefs

When the user asks you to "édite un journal" from a set of existing daily briefs, the deliverable is a comprehensive analytical article that synthesizes the period — NOT a fresh weekly review with new research. This is a retrospective synthesis from already-written material.

Trigger: "édite un journal", "fais un journal des X derniers jours", "résumé synthétique de la semaine".

Workflow:

Confirm scope — which days? Use the calendar files on disk, not the index (index may be stale).
Read all target briefs — read_file on each daily brief. Also read any relevant special briefs.
Run Contrarian — apply Mode B (multi-brief) first, before writing. The Contrarian output shapes the journal's critical perspective.
Structure the journal — 5 chapters:
Ch. 1-3: One chapter per dominant narrative (typically geopolitics, tech, markets). Each chapter = thesis + supporting evidence + [CONTRARIEN] counter-analysis.
Ch. 4: Signals less visibles — roundup of secondary stories (regulations, supply-chain attacks, product launches).
Ch. 5: Scénarios for the next 30 days — table with probabilité, impact, déclencheur.
Add Statistiques du module — briefs produced, hypotheses updated, topics touched.
Conclusion — what the week means, what the Contrarian assessment says about the durability of the narratives.
Save to outputs/journal-<descriptor>-<date>.md
Deliver — send a short Telegram summary (5-8 bullets) with MEDIA:/path/to/journal.md for the full file.
Update index — add to outputs/ tree in 00_index.md

Structure template:

# Journal Hermes — {Date range}

## La semaine qui a tout changé : {Narrative 1}, {Narrative 2} et {Narrative 3}

> One-paragraph hook summarizing the period.

---

## Chapitre 1 — {Narrative 1}

### Le récit dominant

{3-5 paragraphs of synthesis from the daily briefs}

### [CONTRARIEN] — {Counter-thesis}

**Thèse** : {fair statement}
**Antithèse** : {opposing argument}
**Scénario alternatif** : {what changes if wrong}
**Fait historique** : {reference older than 2 years}

## Chapitre 2 — {Narrative 2}
...

## Chapitre 3 — {Narrative 3}
...

## Chapitre 4 — Les signaux moins visibles

| Signal | Importance | Pourquoi |
|--------|-----------|---------|

## Chapitre 5 — Scénarios pour les 30 prochains jours

| Scénario | Probabilité | Impact | Déclencheur |
|----------|-------------|--------|-------------|

---

## Statistiques du module

| Métrique | Valeur |
|----------|--------|

Decision rule: Use this pattern when the user already has daily briefs and wants a synthetic product. Do NOT use it when the user asks for fresh research (use the weekly review workflow instead). The journal is a recombinant product — it remixes existing content, it does not gather new signals.

Difference from weekly review: A weekly review (Phase 3) does fresh research and updates topics. A synthetic journal reads existing briefs and applies Contrarian at the corpus level. The two can be combined: produce a weekly review with fresh research, then a synthetic journal with Contrarian overlay.

Alternative: Special brief (one-off event)

When a major event requires a dedicated brief beyond the daily/weekly cycle, create a special brief as a standalone document. Use this when the event is significant enough to deserve its own synthesis (peace treaty, regulatory bombshell, natural disaster, IPO, etc.).

Trigger: User says "brief spécial", "fais un point sur [event]", the user asks for a comprehensive overview of a specific event that isn't a daily or weekly cycle.

Workflow:

Research the event — gather all key facts: timeline, terms, stakeholders, impacts, reactions
Structure as a standalone document in briefs/special/<date>-special-<slug>.md

Structure:

---
title: "Brief Spécial — Title"
date: YYYY-MM-DD
type: brief
cycle: special
canal: telegram
---

# 📜 BRIEF SPÉCIAL — Title

> Date — Signature prévue/événement
> Synthèse complète

---

## 🚨 Les faits

One-paragraph summary of what happened.

---

## 📋 Terms / Dispositions (if agreement)

| Disposition | Détail |
|---|---|
| Clause 1 | Detail |
| Clause 2 | Detail |

---

## 📆 Chronologie

| Date | Événement |
|---|---|
| DD/MM | Event |

---

## 🌍 Impacts

### Geopolitique
### Économie
### Humanitaire

---

## 🔮 Prochaines étapes

| Date | Événement |
|---|---|

## Questions ouvertes

Bullet list of key unknowns.

Update index — add to briefs/special/ tree in 00_index.md
Optionally — run the Contrarian agent on the special brief for validation

The special brief lives in briefs/special/ alongside daily and weekly subfolders. It is NOT an outputs/ article — articles are for long-form analysis, special briefs are for event-focused synthesis.

Alternative: Full analytical article

When the user asks for a comprehensive article ("génère moi un article complet", "analyse complète de X", "écris un article sur Y"), produce a standalone document in outputs/. This is distinct from a brief — articles are long-form, narrative, with chapters and analysis depth.

Trigger: "article complet", "analyse détaillée", "écris un truc complet sur", user asks for more depth than a brief allows.

Workflow:

Research — gather timeline, background, multiple perspectives, statistical data
Define chapter structure before writing (typically 4-6 chapters + intro + conclusion)
Include multiple perspectives — not just the mainstream narrative. Reference counter-arguments (Contrarian perspective)
Write chapters — each chapter covers a phase or dimension of the subject
Add scénarios — 3-4 plausible future scenarios with estimated probabilities
Save to outputs/<slug>-<date>.md (NOT in briefs/)
Update index — add to outputs/ tree in 00_index.md

Delivery format (user preference): When delivering an article to Telegram, do NOT post the full text in the chat. Instead:

Send a concise summary (3-5 bullet points or 1-2 paragraph résumé)
Append MEDIA:/absolute/path/to/article.md at the end — the platform delivers it as a native file attachment
The user explicitly corrected this: « Quand tu édites un article comme ça, je préfère que tu me postes un résumé et le fichier de l'article en pièce jointe »
This applies to ALL articles (special, analytical, scenario) — not just daily briefs
This also applies to daily briefs when they exceed Telegram's character limit: short summary + MEDIA: file attachment

Chapter structure pattern for geopolitical/regulatory articles:

Ch. 1: Background / Roots
Ch. 2: Timeline / Chronology
Ch. 3: Key negotiations/decisions
Ch. 4: The agreement/outcome in detail
Ch. 5: Impacts and consequences (geopolitical, economic, humanitarian)
Ch. 6: Scenarios for the future (3-4 with probability estimates)
Conclusion

Architecture/technical articles — including ASCII diagrams: When the article describes a technical architecture, infrastructure stack, or multi-component system (e.g. how Hermes Agent orchestrates Home Assistant via MCP, or the RTX Spark + OpenShell stack for personal agents), include an ASCII architecture diagram. Use simple box+arrow diagrams:

┌─────────────────┐     ┌──────────────────┐
│  Component 1    │────▶│  Component 2     │
│  (detail)       │     │  (detail)        │
└─────────────────┘     └──────────────────┘
         │                       │
         ▼                       ▼
┌─────────────────┐     ┌──────────────────┐
│  Component 3    │     │  Component 4     │
└─────────────────┘     └──────────────────┘

Rules for ASCII diagrams:

Keep them simple: max 4-6 boxes, 2-3 layers deep
Use ┌, ┐, └, ┘, ─, │, ▶ characters only (these render reliably in all terminals and markdown)
Always add a short prose explanation below the diagram — the diagram is a visual aid, not a replacement
Include only in outputs/ articles, not in daily briefs (briefs are consumed on Telegram where ASCII may break)
The diagram must add information not already in the text — never repeat the same information in diagram and prose form

Scenario-analysis variant (geopolitical/regulatory forecasting):

When the core value of the article is exploring multiple futures (not just narrating the past), use this enriched variant. It replaces the standard chapter structure with a scenario-centric architecture:

# Title — Subtitle

## Prologue — The hook

One-paragraph framing that establishes the tension. What's at stake, why now, what's the time window.

## Ch. 1 — Les acteurs et leurs contraintes

Cartography of every key stakeholder: their position, constraints, levers. For each: what they want, what they can't do, what they could do if pushed.

## Ch. 2-N — One chapter per scenario

Each scenario chapter includes ALL of:

**Probability estimate** (e.g. 35%) | **Impact level**

### Le récit
3-5 paragraphs of detailed chronology: what happens, when, who does what, what breaks.

### Conséquences
Bullet list: geopolitical, economic, humanitarian impacts.

### Signaux de détection précoce
5 numbered signs to watch — concrete, observable events (not general trends).

### Analyse Contrarian (embedded)
**Thèse** : what this scenario assumes — state it fairly.
**Antithèse** : the counter-argument within this specific scenario. Why it might not unfold this way.
**Parallèle historique** : a reference older than 2 years (e.g. Suez 1956, Oslo 1993, Doha 2020). What makes this scenario similar and different.
**Évaluation** : is the probability under- or over-estimated? What blind spots does this scenario have?

## Ch. N+1 — Le dénominateur commun

The cross-cutting constraint that ALL scenarios share (e.g. "the nuclear question was pushed to 60 days in every scenario"). This chapter identifies what doesn't change regardless of which future unfolds — the structural bottleneck.

## Épilogue

Summary table: scenario name | probability | impact | "signal clé à J+7" (one concrete thing to watch right now).
Then two sections:
- **Ce que l'accord/événement a changé** — the irreversible shifts
- **Ce qu'il n'a pas changé** — the open questions
- Final Contrarian assessment: score de robustesse global (1-10).

## Références

List of source briefs, analyses, and topics referenced.

See references/scenario-article-format.md for a complete worked example from the Iran accord analysis.

Decision rule: Use the standard chapter structure for historical/narrative articles (telling a story from past to present). Use the scenario-analysis variant when the user asks for "scénarios", "trajectoires", "que va-t-il se passer", or when the event is ongoing and the future is genuinely open. The scenario variant is NOT for articles about completed events (use the standard structure instead).

For scenario-focused articles on the other hand, use the scenario-analysis format instead of the general structure above: one chapter per scenario, each with its own Contrarian analysis, detection signals, and historical parallel. See references/scenario-analysis-article-format.md for the full template and a worked example.

Difference from special brief: A special brief is factual and event-focused (what happened, when, who). An article is analytical and narrative (why it happened, what it means, what comes next). Article = brief + analysis + scenarios + depth.

Alternative: Deep-dive response on a specific site/location

When the user follows up on a topic by asking for details on a specific physical site (e.g. "détaillé moi le triangle de Connerré"), this is distinct from both new-topic creation and existing-topic enrichment. The user wants deep context on one sub-element already referenced in the topic. The full workflow is in references/site-deep-dive-worked-example.md — including geography research, technical deployment details, historical context, and cross-referencing back to the parent topic.

Alternative: Regulatory/policy deep-dive explainer

When the user asks "détaillé moi [regulation/subject] et en quoi ça m'impacte" (e.g. "what does the EU AI Act mean for me?"), this is a specific pattern: the user wants a comprehensive explanation TAILORED to their personal and professional context, not a generic summary.

Trigger: User asks for an explanation of a regulation, law, or policy with explicit framing like "en quoi ça m'impacte", "what does this mean for me", "suis-je concerné".

Workflow:

Research the regulation via delegate_task or web_search — gather key facts (scope, timeline, penalties, specific articles relevant to the user's industry).

Split into professional + personal — the user explicitly wants both angles. Structure the answer in three parts:
The regulation in brief — what it is, key dates, risk levels (if applicable)
Professional impact — how it affects their specific job/industry (e.g. SNCF Réseau: critical infrastructure under Annex III, 8 obligations for high-risk AI, concrete tools they use)
Personal impact — does it apply to them as an individual using AI tools at home? (Generally exempt for personal use, but with caveats around publishing/sharing AI-generated content)

Include concrete action checklist — end with "ce que tu dois faire" sections for both professional and personal contexts.

Prioritize the user's actual toolset — reference THEIR tools (Altametris, KIZEO, Hermes, drones) when discussing impact. Generic regulation summaries are useless; the value is in the contextualization.

Source attribution — cite the specific articles (e.g. "Article 50 (transparence)", "Annexe III, point 2 (infrastructures critiques)"). This builds trust and allows the user to verify.

Tone: Factual, structured, direct. No speculation. If a deadline is "J-48" say it. If an amende is "35M€" say it. The user asked for concrete impact, not editorial commentary.

See references/eu-ai-act-impact.md for a worked example of a regulatory deep-dive covering professional + personal impact (EU AI Act × SNCF Réseau, updated June 2026).

Alternative: Enriching an existing topic (not creating a new one)

If the user mentions entities that fit within an existing topic (e.g. adding "Hermes Agent v0.16.0" info to the existing hermes_agent.md topic), expand the existing file instead of creating a new one. Add new sections or subsections as needed. The existing topic's Signaux récents table is the first place to add new entries.

Decision rule: Create a new topic when the entity/subject has no natural home in any existing topic. Enrich an existing topic when it clearly belongs there.

Cross-linking between related topics: When two topics share one or more entities (e.g. Altametris appears in both inspection and drones topics), add explicit cross-references in both directions. In each topic's Liens section, add - Voir aussi : topic — [reason]. Bump both topics' Dernière mise à jour date. This avoids duplicating entity descriptions across related topics.

For enriching an existing topic (adding a deep-dive on one of its sub-elements): When the user says "ajoute ceci au topics" after a verbal deep-dive, the info goes into the EXISTING topic file that already covers that domain — not a new file. Identify the section to expand, then patch to replace the brief bullet-point placeholder with the full structured deep-dive (geography, chronology, technology, partners, outcomes). Update the 00_index.md entry's description line if the topic's scope broadened.

Write the daily brief to briefs/daily/YYYY-MM-DD.md with this structure:

---
title: "Revue Quotidienne Hermes"
date: YYYY-MM-DD
type: brief
cycle: daily
canal: cli
certification: "Constitution Fondatrice Hermes — Agent: Analyst & Contrarian"
---

# Revue Quotidienne — {Date}

> Synthèse des signaux détectés sur les N territoires suivis.
> Agent Sentinel — revue par Analyst + contre-épreuve Contrarian.

---

## 🔴 ALERTE — {Titre de l'alerte majeure}

**Source** : ...
**Certitude** : {CERTAIN | PROBABLE | SPÉCULATIF}
**Implication** : ...

{Analyse 3-6 lignes}

**Contre-épreuve** : [CONTRARIEN] {Contre-argument / scénario alternatif}

---

## 1. {Topic 1 — Titre}

**Signaux** : tableau des signaux avec priorité + source
**Analyse** : 3-5 lignes
**Contre-épreuve** : [CONTRARIEN] ...

## 2. {Topic 2 — Titre}
...etc...

---

## 🔗 Liens entre sujets détectés

{Liste de 3-8 connexions inter-topics avec explication d'1-2 lignes}

---

## 💡 Hypothèses émergentes

{Liste de 3-6 hypothèses avec une ligne d'explication}

---

## 📋 Recommandations mémoire

1. Mettre à jour les topics avec les signaux du jour
2. Créer `hypotheses/` avec les hypothèses
3. Proposer nouveaux dossiers si nécessaire
4. Archiver les synthèses brutes dans `sources/`

---

*Signaux intégrés : N (X 🔴, Y 🟡, Z 🟢)*
*Contre-épreuve : ✓ (...)*

For weekly reviews — write to briefs/weekly/YYYY-MM-DD.md. Two format variants are acceptable; pick based on how much happened during the week.

Variant A — Topic-by-topic (calm week, 1-2 major stories):

--- (same frontmatter) ---
...

Variant B — Alertes-driven (intense week, 3+ major stories):

This variant is preferred when the week had 3+ major stories that span across topics. It opens with individual ALERTE sections for each major story, followed by a compact per-subject summary table and forward-looking sections. This avoids the problem of the same story needing to be mentioned in every topic section.

---
title: "Revue Hebdomadaire Hermes"
date: YYYY-MM-DD
type: brief
cycle: weekly
week: "DD-MM à DD-MM-AAAA"
canal: cli
certification: "Constitution Fondatrice Hermes — Agent: Analyst & Contrarian"
---

# Revue Hebdomadaire — Semaine du {start} au {end}

> Synthese hebdomadaire des signaux detectes sur N sujets suivis.
> N briefs quotidiens (dates).
> Agent Sentinel — revue par Analyst + contre-epreuve Contrarian.

---

## 🔴 ALERTE S1 — {Titre alerte majeure #1}

**Chronologie :**
| Date | Evenement |
|---|---|
| JJ | Detail |

**Implication :** 4-8 lignes.

**Contre-epreuve :** [CONTRARIEN] ...

---

## 🔴 ALERTE S2 — {Titre alerte majeure #2}

... (repeat S3, S4 if needed)

---

## 📋 Synthese par sujet

| Priorite | Sujet | Fait marquant |
|---|---|---|
| 🔴 | Topic A | Detail cles |
| 🟡 | Topic B | Detail cles |
| 🟢 | Topic C | Detail cles |

(Compact table with 1-2 lines per subject, no separate sections for quiet topics)

---

## 📊 Tendances lourdes de la semaine

| Tendance | Detail |
|---|---|
| Tendance 1 | 2-3 lignes |

---

## 💡 Hypotheses — mise a jour hebdo

| Hypothese | Statut |
|---|---|
| Hypotheses A | VALIDEE / CONFIRMEE / Stable |

---

## 📅 Agenda semaine a venir (dates)

| Date | Evenement |
|---|---|

---

## 📈 Statistiques du module

| Metrique | Valeur |
|---|---|
| Briefs quotidiens produits | N (dates range) [+X cette semaine] |
| Briefs hebdomadaires | N [+X] |
| Topics actifs | N [+X cette semaine] |
| Hypotheses suivies | N |
| Analyses | N |

Decision rule: Use Variant A (topic-by-topic) when in doubt — it's the default. Use Variant B (Alertes-driven) when the week had 3+ genuinely major stories that cut across multiple topics and would need to be repeated in each section. The Alertes-driven variant is NOT for weeks with 1-2 normal stories — Variant A works better for those.

Always include a "Statistiques du module" section in the weekly brief. It tracks the module's growth across briefs produced, topics active, hypotheses, and analyses. This gives the user a quick sense of the module's health and trajectory.

Phase 4: Update Topic Files

For each topic, rewrite the topic file with:

Updated date: and updated: in frontmatter
New signals added to "Faits marquants" / "Signaux récents" (table format)
Updated "Questions ouvertes" based on new information
New "Liens" section pointing to related topics + hypotheses + brief

Format for signal table:

| Date | Signal | Source | Priorité |
|------|--------|--------|----------|

Phase 5: Generate Cross-Topic Links

In each topic file, add a "Liens" section with:

Lien fort — direct relationship to another topic (e.g., Edge AI + HA/ESPHome)
Hypothèse — link to hypothesis that connects this topic to others
Brief — link to the daily/weekly brief

Format consistency: Use - Lien fort :, - Hypothèse :, - Brief : (dash prefix). Do NOT use | (pipe) prefix — pipes are for table rows, not list items. Verify after each patch that the list markers are consistent.

Apply the principle of charité — don't force links that don't exist. Quality over quantity.

Phase 6: Create Emerging Hypotheses

For each pattern you notice across topics, create a hypothesis file in hypotheses/:

---
title: "Hypothesis title"
date: YYYY-MM-DD
status: active
tags: []
sources: []
---

# Hypothèse : Title

**Postulat** : {One-paragraph thesis}

**Arguments pour** : {Evidence from the research}

**Arguments contre** : {What would weaken this}

**Ce qui infirmerait** : {Specific condition that would falsify this}

**À réévaluer dans** : {N} jours.

Hypotheses MUST include:

A falsification condition (what would disprove it)
A re-evaluation deadline
Both for and against arguments

Phase 7: Integrity Verification + Permissions

After all files are written:

Check all relative links are valid — grep -rn '\\\\.\\\\.\\\\/' on all modified files. Also verify each referenced file actually exists on disk.
Verify list format consistency — after patching topic "Liens" sections, check that all markers use - (dash), not | (pipe). A grep '^| ' on modified topic files can catch stray pipes in link sections.
Verify no orphan files — every new file in topics/, hypotheses/, briefs/ must be referenced in 00_index.md
Frontmatter completeness — every file needs date:, status:, tags:
Link count — each topic should link to 2-3 other topics + hypotheses + brief
Fix any dead links found (common: wrong hypothesis name, wrong relative path)
Set Unix permissions for Obsidian/SSHFS — after every file or directory write in /memory/:
chmod 664 <fichier.md> on every new or updated .md file (target: rw-rw-r--)
chmod 775 <dossier> on every new directory created (target: rwxrwxr-x)
Verify with ls -la <fichier.md> and fix immediately if wrong
Scan the hierarchy for pre-existing files with restrictive permissions (-rw-------) and fix them too — these break Obsidian via SSHFS on the host Mac
Check group ownership — if ls -la shows group hermes (or 10000) instead of users, the SSHFS client user gets read-only access. Inform the user they must run chown -R 10000:users /path from the Docker host to fix group ownership. This cannot be done from inside the container (no sudo, hermes not in users group).
Clean up temp files — remove any /tmp/.md or /opt/data/.md research artifacts left by subagents. Also remove any files the subagents wrote to /opt/data/ during research phase.
Log the session — after any major restructuring, index update, or module cleanup, save a session log in archive/sessions/YYYY-MM-DD-<slug>.md. The log should briefly describe what was done (not a transcript) and list the next steps. This prevents the "what happened last time" question and gives Archivist a reference point. Format:

# Session — {Title}

**Date** : YYYY-MM-DD
**Contexte** : {1-2 line context}

## Actions
1. {bullet list of actions taken}

## Résultat
{what changed, key numbers}

## Prochaines étapes
- {from kanban or roadmap}

Phase 8: Deliver to Messaging Platform (optional)

After writing the brief and before updating topics, deliver the finished brief to the user's preferred platform if applicable. This bridges the editorial review cycle with the messaging delivery layer.

When to deliver: If the user explicitly asked for a platform delivery (e.g. "envoie sur Telegram"), or if the brief was produced via cron with a deliver target, do this between writing the brief and starting topic updates.

Delivery option: SSH/VPS

When the user asks to send articles to a remote VPS (e.g. 185.229.202.36), use this workflow:

Check if SSH key exists — ls ~/.ssh/. If no key directory exists, generate one:

   mkdir -p ~/.ssh && ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa_vps -N ""

Install the key on the remote server — Since sshpass is often unavailable and apt may be locked, use a Python script with pexpect (available on most Hermes hosts) to enter the password:

   import pexpect, os
   password = os.environ["VPS_PASSWORD"]
   host = "root@HOST"
   with open(os.path.expanduser("~/.ssh/id_rsa_vps.pub")) as f:
       pubkey = f.read().strip()
   child = pexpect.spawn(f"ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null {host}", timeout=30)
   child.expect('assword:')
   child.sendline(password)
   child.expect(['#', '$'])
   child.sendline(f"mkdir -p ~/.ssh && echo '{pubkey}' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys && chmod 700 ~/.ssh")
   child.expect(['#', '$'])
   child.sendline("mkdir -p /root/articles")
   child.expect(['#', '$'])
   child.sendline("exit")

Write this to a file with write_file, then run via terminal(VPS_PASSWORD='*' python3 /path/to/script.py).

Copy files — Once the key is installed, use scp with the identity key:

   scp -i ~/.ssh/id_rsa_vps /path/to/article.md root@HOST:/root/articles/

Bulk copy — For multiple articles, loop:

   for f in article-*.md; do scp -i ~/.ssh/id_rsa_vps "$f" root@HOST:/root/articles/; done

Verify — SSH in and run ls -lh /root/articles/ to confirm all files arrived.

Pitfall — execute_code sandbox lacks pexpect: The delegated Python sandbox (execute_code) does not have pexpect. Write the SSH key script to a file first, then run via terminal(). pexpect IS available in the terminal environment.

Pitfall — password in script file: Use environment variables (VPS_PASSWORD='*' python3 script.py) instead of hardcoding the password. The script persists on disk.

Pitfall — sshpass unavailable: On many Hermes hosts, sshpass is not installed and apt-get may be locked (non-root user). pexpect is the reliable alternative — do not attempt to install sshpass.

The MEDIA: pattern for long-form content: Briefs routinely exceed Telegram's 4096-char limit (the briefs we produce are 8-12 KB). Do NOT truncate or split into multiple messages. Instead:

Send a short summary (5-8 bullet points with the key alerts) as the message text
Append MEDIA:/absolute/path/to/brief.md at the end — the platform delivers it as a native file attachment

📰 *Revue Quotidienne — JJ mois AAAA*

🔴 *ALERTE principale* : résumé en 1-2 lignes.

🔴 *Alerte secondaire* : résumé en 1-2 lignes.

🟡 Topic 1, 🟡 Topic 2, ...

N signaux intégrés.

MEDIA:/home/sebastien/.hermes/memory/modules/revue_editoriale/briefs/daily/YYYY-MM-DD.md

The MEDIA: path must be absolute. The attachment appears as a downloadable .md file on Telegram (and other platforms that support file attachments). This avoids character limits entirely while keeping the full content accessible.

Pitfall: Do NOT use MEDIA:/path on CLI — the marker renders as literal text. Only use it when delivering via send_message(target='telegram:...') or similar platform channels.

Phase 9: Update Index

Update 00_index.md:

Add new topics, hypotheses, briefs to the tree structure — verify parent placement: special briefs go under briefs/special/, not under briefs/weekly/ or briefs/daily/. Check the existing tree structure for sibling examples before inserting new lines.
Update the "Suivis Actifs" table with new priorities and dates — every topic listed in the tree under topics/ should also have a row in the Suivis Actifs table, even new ones (🆕 status)
Bump the "Dernière mise à jour" line at the top

Phase 10: Editorial Feedback (post-production)

After all memory files are updated, run the editorial feedback procedure documented in memory/style/writing_preferences.md (section: Apprentissage continu):

Analyze the produced brief for linguistic patterns — check against rejected_patterns.md
Classify notable passages — add to quality_examples.md if they're reference-worthy
Detect new patterns — add to rejected_patterns.md if a banned expression was used
Update writing_preferences.md if user provided explicit feedback
Increment revision_count in the frontmatter of modified feedback files

This creates a virtuous cycle: each review improves the next. Skipping this phase means rejected patterns repeat in the next review, quality stagnates, and the user eventually corrects the same issues again. This phase is mandatory, not optional — if under time constraint, spend 2 minutes minimum: scan rejected_patterns.md for any new violations and check one quality example.

The 6 feedback files and their purposes:

File	Purpose
`writing_preferences.md`	Profil intellectuel, ton, check-list pré-production. Updated when user corrects style/format.
`quality_examples.md`	Corpus de référence : exemples classés (à imiter / à améliorer) avec raisons. Updated after each notable review.
`rejected_patterns.md`	Patterns bannis : formulations, angles morts, mots interdits. Updated when a pattern repeats.
`stylistic_rules.md`	Règles de style : voix, structure, ton, vocabulaire, lisibilité, marquage. Stable — only updated when constitution changes.
`analytical_depth.md`	4 niveaux de profondeur L1-L4 + grille d'approfondissement. Audited during verification.
`historical_connections.md`	Grille temporelle + chronologies TODO. Each review should advance at least one chronology.

Phase 11: Module Maintenance — Backlog/Kanban Processing

When the user asks to "scan the kanban" and "process pending tasks", run this workflow to clean up the module's task board. This is distinct from the review cycle — it's a maintenance pass that can happen between reviews.

Trigger: User says "scan le kanban", "traite les taches en attente", "fais le point sur le backlog", or any variant asking to process the module's task list.

Workflow

Read kanban.md — understand the current columns (Backlog, À faire, En cours, En attente, Terminé)

Audit each backlog item against what actually exists on disk:
Does a file already exist for this task? (e.g. "Identifier les revues quotidiennes" → 4 briefs exist in briefs/daily/)
Was the task implicitly completed by other work? (e.g. "Identifier les sujets suivis" → 00_index.md already lists them all)
Is the task still genuinely pending?

Classify each item:
Implicitly done — move to Terminé with note explaining when/how it was completed
Partially done — complete the missing piece (create the index, template, file) then move to Terminé
Still pending — keep in backlog or promote to À faire
Obsolete — remove if the task no longer makes sense

Create missing artifacts for partially-done items:
briefs/index_briefs.md — chronological index of all reviews produced
briefs/index_topics.md — subject index with status, priority, last signal date
briefs/template_daily.md — reusable daily brief template (copy from an existing brief structure)
Activation prompt in README if missing (short one-liner + long version + skill-load variant)

Update all references after creating artifacts:
memory/index.md — add entries for new files
00_index.md — update the tree and status table
kanban.md — reflect the new state

Kanban state output: After processing, summarize to the user:
Which items were moved to Terminé (with reasons)
Which new files were created
What remains in Backlog / À faire (if anything)
Any action needed from them (e.g. chown from Docker host for group ownership)

Example

Backlog item: "Créer un index des briefs"
→ Audit: 4 daily + 1 weekly brief exist, listed in 00_index.md but no dedicated index
→ Action: Create briefs/index_briefs.md with chronological table, stats
→ Reference: Update memory/index.md, kanban.md
→ Classification: Terminé — index_briefs.md created

Common pitfalls

Marking items as done without creating the artifact. If an index doesn't exist but ought to, you must create it — don't just say "already covered by 00_index.md" if the backlog specifically asked for a dedicated file.
Overwriting the kanban.md header. When rewriting kanban.md, preserve the column definitions and table at the top. Only modify the task lists below.
Not updating memory/index.md. New artifacts must be listed in the module's local memory index, not just 00_index.md. Both indexes need updating.
Forgetting permissions on new files. Every new .md file needs chmod 664, every new directory chmod 775. See Phase 7 for full permissions handling.

Anti-Patterns

Skipping the counter-evidence step. Every 🔴 signal must have a [CONTRARIEN] counter-analysis. This is a constitutional requirement (anti-hype permanent). Without it, the review is just aggregation.

Creating hypotheses without falsification conditions. A hypothesis that can't be disproven is not a hypothesis — it's a belief. Every hypothesis file must include "Ce qui infirmerait".

Forcing cross-topic links. If two topics genuinely don't connect, don't invent a link. Quality of insight over quantity of connections.

Overwriting the user's topic format. If topics already have custom structure, adapt to it rather than rewriting in a rigid template.

Not cleaning up temporary research files. The delegate_task subagents may scatter /tmp/.md and /opt/data/.md files — either integrate them into sources/ or clean them up. Prefer returning results via subagent summary (inline text) to avoid scattered files entirely.

Pipe vs dash in link sections. When patching topics to add Liens entries, the patch tool may introduce pipe (|) characters instead of dashes (-). This creates broken list formatting. Always verify list markers after patching: grep '^[|-] Brief' <topic_file>.

Not verifying cross-profile /memory write access. If /memory is a separate mount, it may have different ownership. If writes fail, tell the user to run chown -R <hermes_uid>:<hermes_gid> /memory from the Docker host. Do not attempt sudo/root inside the container.

Table row double-pipe when patching any Markdown table. When patching a table row in any file (topics/, 00_index.md, briefs/), the patch tool may introduce additional pipe characters on replaced rows — e.g. | row | becomes || row ||, or ||| row | becomes |||| row |||| on subsequent edits. Each patch compounds the extras by one pipe. This breaks table rendering. Two sub-cases:

Original format uses | (single pipe): patches produce || (double). Fix: patch back to single |.
Original format uses ||| (triple pipe) — the Suivis Actifs table in 00_index.md uses this format. Patches produce |||| (quadruple). Fix: match the original prefix count, not single-pipe.

Always verify table rows after every patch batch: grep -nP '^\|{4,}' <file> to catch prefixes that are longer than the original format (this catches ||| → |||| escalation). Fix by patching all affected rows at once with the correct prefix count. Do not patch rows one at a time — each individual patch re-escalates the pipe count. Batch all corrections into a single new_string spanning the full table section.

Escalation escape hatch — use sed when patch keeps compounding: Even with batching, the patch tool may continue adding one pipe per edit (triple → quadruple → quintuple). Once the count is 3+ beyond the original, stop patching the table and use sed from terminal instead:

   sed -i '/^|\{4,\}/s/^|\{4,\}/|||/' 00_index.md

This matches any row with 4+ leading pipes and collapses them to exactly 3 (|||). Adjust the target count to match the module's original format. After running sed, verify with grep -nP '^\|{3,}' that all rows are uniform. This avoids the compounding problem entirely because sed does a simple regex substitution, not the patch tool's fuzzy-matching algorithm.

Special characters (emoji, arrows) make matching harder — when a table-row patch fails, include the surrounding header row and separator row in old_string for a broader match.

Literal \n in patched files. When the patch tool's new_string contains a literal \n sequence (rather than an actual newline), it writes the literal characters \n into the file instead of a line break. This produces a single line like || row1 🆕\\n|| row2 🆕| instead of two lines. To fix: patch again replacing the literal \\n with an actual line break. To prevent: always use genuine newlines in new_string, never the escape sequence \n.

Index staleness trap. The 00_index.md may not list all files that actually exist on disk. When catching up on missing briefs, always trust the filesystem listing (ls briefs/daily/) over the index. Files may have been created without updating the index. After writing new briefs, the index must be patched to reflect the actual file set.

Patch fuzzy-match collateral deletion. When the patch tool's fuzzy matcher detects content near the match boundary as "related" to the old_string, it may silently delete lines that were NOT included in your old_string. In this session, - NVIDIA/skills ajouté aux taps Skills Hub de confiance — a line preceding the matched block by one line — was dropped. The fuzzy matcher absorbed it into the replacement. This is distinct from anti-pattern 6 (pipe vs dash) — here the content is lost entirely, not just reformatted. Mitigation: after every patch, verify the 5 lines above and 5 lines below the edit site with a targeted grep or read_file. If content went missing, restore it with a second patch. When the match boundary is ambiguous (e.g. a bullet list or a table in the middle of other content), include MORE surrounding context in old_string to pin the match precisely.

Offset/limit stale-state warning on patch. When you patch a file that was last read_file'd with offset and limit (partial read), the patch tool warns: "was last read with offset/limit pagination (partial view). Re-read the whole file before overwriting it." More importantly, patches may behave unpredictably on file views that don't reflect the full current state — especially if the file was modified between the partial read and the patch. Mitigation: after any write/update to a file, do a full read_file (no offset/limit) before the next patch on that same file.

Renumbering collision when patching numbered lists. When adding items to a numbered list (e.g. "Faits marquants" with 1., 2., ...), the patch tool matches on content, not number. If your old_string includes numbered items that exist in the file, those items are replaced — not spliced. This silently drops items you didn't intend to touch if they happen to fall within the matched span. Two failure modes:
Missing renumbering: writing new_string with new numbers like 12., 13., 14. but omitting an existing item whose number range overlapped the match — that item vanishes.
Duplicate numbering: re-adding a dropped item in a later patch creates two items with the same number (e.g. two 9. entries).
Safe approach: always include the complete sequence of items in new_string, carrying forward any existing items you want to keep. After patching, verify the list has no duplicate numbers: grep -nP '^\d+\.' <file> | sort | uniq -d (catches duplicates) and grep -nP '^\d+\.' <file> | wc -l vs expected count (catches missing items). If numbers are cosmetic (markdown renders them in order regardless), this is a formatting issue — fix the numbers for human readability.

Forgetting to account for web_extract backend limitations. When DuckDuckGo (ddgs) is the configured web search backend, web_extract silently fails — it cannot fetch page content. This manifests mid-research as a blocker: you have promising search result titles but zero detail. Mitigate by either (a) using browser_navigate + browser_snapshot(full=True) as a fallback for the top 1-2 results per topic, or (b) configuring a URL-extraction-capable backend (Firecrawl, Tavily, Exa) in config.yaml under web.extract_backend. See references/browser-content-extraction.md for the full browser workflow.

Sibling agent concurrent access collision. When a live session patches 00_index.md (or any topic file) after a cron agent has already written to it (e.g. daily brief cron at 18:00), the patch tool warns "was modified by sibling subagent <id> at <time> — after this agent's last read". The patch may still apply, but the stale-state can cause:

Double entries in the tree listing: the cron agent added 2026-06-26.md with its description, your patch adds a second 2026-06-26.md with a different description. You end up with two identical-looking tree lines.
Index description inconsistency: the "Dernière mise à jour" line in the header was already bumped by the cron to a newer date than what your patch targets.
Table row triple-pipe escalation: the cron agent's patches may use a different pipe prefix count than yours, creating mixed || / ||| rows.

Mitigation sequence when you get a "modified by sibling subagent" warning:

Re-read the file fresh (full read, no offset/limit) before making any more patches to it.
Compare disk state with your intended edits: what lines does the cron have that you don't? What lines do you have that the cron doesn't? Merge, don't overwrite.
Batch ALL your remaining patches into ONE patch on the full section — patch the entire table or tree listing at once, with all rows both yours and the cron's. This avoids the compounding-pipe problem.
Verify no duplicate lines after the patch: grep -c '2026-06-26' 00_index.md should return exactly 1 for each unique day.
Check the "Dernière mise à jour" header — if the cron already bumped it past your intended edit, leave it. Don't overwrite a newer date with an older one.

Prevention: before making any live-session edits to 00_index.md, check whether the daily cron may have already run today by checking the file's modification time (stat -c '%Y' 00_index.md) against the cron schedule (typically 18:00). If the cron ran after your session started, ignore stale read-cache and re-read the file before every patch.

4. Processing the "Recommandations mémoire" Backlog

After the daily cron produces a brief, the ## 📋 Recommandations mémoire section lists specific topic updates that should be applied. This section accumulates — briefs from multiple days may each have 3-5 items. When the user says "applique les recommandations", run this workflow:

Phase 12: Process Recommendation Backlog

Read the last N briefs (N=3-5) from briefs/daily/ in reverse chronological order. Extract every ## 📋 Recommandations mémoire section. Tip: an exact marker search (grep -A 10 '## 📋 Recommandations mémoire' briefs/daily/*.md) collects all recommendations at once.

Cross-check each recommendation against the actual disk state of the target file:
Already applied? Check the file's updated: frontmatter field; if it's >= the brief's date, the signal may already be in the file. Read the end of the Faits marquants section to confirm.
Partially applied? The cron agent may have added some signals but missed others. Look for gaps between what the recommendation lists and what the file actually contains.
Not applied? Add the signal.

Deduplicate across briefs — the same recommendation (e.g. "Mettre à jour geopolitique_iran.md") may appear in consecutive briefs with different signals. Merge all pending signals into one batch update per topic.

Apply remaining items only — skip items whose signal was already added by the cron, apply items that are genuinely missing. Report which were already done and which you added.

Track persistent gaps — if the gap 24 juin note appears in multiple briefs without action, flag it: "Le gap du N date est toujours présent dans M briefs consécutifs — décision attendue."

Stylistic Requirements

These rules are enforced by the style/stylistic_rules.md system and MUST be followed in every review:

Banned expressions (zero tolerance)

"révolution silencieuse", "point d'inflexion", "game changer", "nouveau paradigme", "l'avenir est déjà là", "dans un monde en constante évolution", "il est temps de"
If the same metaphor ("tectonique", "inflexion", "seuil") appears in 2+ consecutive reviews, it's automatically banned for the next 3 reviews

Analytical depth requirement

Briefs: minimum L3 (facts + context + causality + implications)
Topic updates: minimum L2 (facts + context)
Check the 4 levels in style/analytical_depth.md

Historical depth requirement

Every topic update must include at least one reference to an event older than 2 years
If no such reference exists, add a ## Chronologie section with 3+ dates
Check style/historical_connections.md for guidance

CERTAINTY markers

[CERTAIN] — verified by 3+ independent sources
[PROBABLE] — strong evidence, not definitive
[SPÉCULATIF] — limited evidence, reasonable hypothesis
[NON VÉRIFIÉ] — single source, unconfirmed
Every main claim in the ALERTE section MUST have a marker

Tone constraints

Max 1 metaphor per document
No LinkedIn-style formulations (calls to action, pseudo-provocations)
No rhetorical questions without implied answer condition
Sentences max 35 words
Active voice preferred

Verification Checklist

[ ] Brief written to briefs/daily/YYYY-MM-DD.md (daily) or briefs/weekly/YYYY-MM-DD.md (weekly) with complete structure
[ ] Weekly brief: references daily briefs in footer (Briefs quotidiens: N (dates))
[ ] Weekly brief: week: field in frontmatter is populated with the date range
[ ] All active topics updated with new signals and links
[ ] Each 🔴 signal has a Contrarian counter-analysis
[ ] Cross-topic links documented in the brief and in each topic's "Liens" section
[ ] Hypotheses created with falsification conditions and re-evaluation deadlines
[ ] New topics/dossiers proposed (as status: brouillon) if a topic has grown too large or covers distinct ecosystems
[ ] Topic splitting detected during Phase 1: no single topic blends unrelated hardware tiers or communities
[ ] All relative links verified (no dead links)
[ ] 00_index.md table rows verified: grep -rn '^||' memory/ returns nothing across the whole vault (no double-pipe prefixes)
[ ] Permissions verified: find /memory/ -name '*.md' -not -perm 644 -a -not -perm 664 -a -not -perm 775 -a -not -perm 755 | head -5 returns nothing (no files with owner-only permissions)
[ ] 00_index.md updated with new files, priorities, and dates — verify parent placement in tree (special briefs under briefs/special/, analyses under analyses/)
[ ] File naming conventions verified: all new files match the module's pattern (YYYY-MM-DD.md for daily briefs, YYYY-MM-DD-special-<slug>.md for specials, contre-epreuve-<slug>-YYYY-MM-DD.md for analyses) — rename any files that deviate
[ ] Temporary research files either archived to sources/ or deleted
[ ] Banned expressions checked: none present (verify against rejected_patterns.md §3)
[ ] CERTAINTY markers present on all 🔴 claims
[ ] Max 1 metaphor across the entire document (re-read to check)
[ ] Editorial feedback: quality_examples.md and rejected_patterns.md updated if applicable
[ ] Historical depth: at least one reference older than 2 years in each updated topic

The user has provided the following instruction alongside the skill invocation: [IMPORTANT: You are running as a scheduled cron job. DELIVERY: Your final response will be automatically delivered to the user — do NOT use send_message or try to deliver the output yourself. Just produce your report/output as your final response and the system handles the rest. SILENT: If there is genuinely nothing new to report, respond with exactly "[SILENT]" (nothing else) to suppress delivery. Never combine [SILENT] with content — either report your findings normally, or say [SILENT] and nothing more.]

Output from job '76ce033272c7'

The following is the most recent output from a preceding cron job. Use it as context for your analysis.

# Cron Job: Veille quotidienne d'actualités (FAILED)

**Job ID:** 76ce033272c7
**Run Time:** 2026-07-05 16:10:01
**Schedule:** 0 16 * * *

## Prompt

[IMPORTANT: The user has invoked the "news-briefings" skill, indicating they want you to follow its instructions. The full skill content is loaded below.]

---
name: news-briefings
description: "Research current events and deliver formatted news briefings to the user's messaging platform (Telegram/WhatsApp). Covers one-shot news queries and recurring cron-based news briefings — aggregating from RSS feeds via curl, structuring summaries by region/topic, and delivering to the user's preferred channel."
version: 1.3.0
metadata:
  hermes:
    tags: [news, current-events, rss, briefing, delivery, telegram, whatsapp, cron]
prerequisites: {}
---

# News Briefings

Research and deliver current-events briefings to the user's messaging platform. Supports two modes:
- **One-shot** — user asks "what's happening?" in a live conversation
- **Recurring cron** — automated daily/weekly briefings via the cronjob tool

## Mode 1: One-shot queries (live conversation)

### 1. Gather news data

When the user asks for news/current events, gather from multiple RSS feeds using `curl` (browser dependency may be unavailable). Good free RSS sources:

BBC World: https://feeds.bbci.co.uk/news/world/rss.xml

NYT World: https://rss.nytimes.com/services/xml/rss/nyt/World.xml

Le Monde: https://www.lemonde.fr/international/rss_full.xml

France Info: https://www.francetvinfo.fr/monde.rss (⚠️ /monde/rss → 404, utiliser .rss)

France 24: https://www.france24.com/fr/rss

Hacker News: https://news.ycombinator.com/

Apple Newsroom: https://www.apple.com/newsroom/

The Guardian: https://www.theguardian.com/tone/news


⚠️ **Avoid sources with aggressive anti-bot protection** — Some sites (Reuters/DataDome, Google News, DuckDuckGo, Bing, Searx) are systematically blocked from certain server IPs. When `curl` hits these, the connection may get a TCP reset that propagates as a "Broken pipe" (Errno 32) crash, killing the whole agent run — far worse than a simple HTTP error. For **one-shot queries**, if these fail, just skip them. For **cron jobs**, remove them from the prompt entirely — a runtime error crashes the agent, and "skip and continue" won't help if curl itself segfaults on a blocked domain.

Use `delegate_task` for heavier research (multiple feeds → extraction → structured summary) so the main thread stays responsive. Pass `toolsets=["terminal"]` for simple RSS parsing.

For parallel research on multiple topics, use the tasks= array form:

delegate_task(tasks=[

{"goal": "Research {topic A}", "toolsets": ["terminal"]},

{"goal": "Research {topic B}", "toolsets": ["terminal"]},

])

This runs up to 3 subagents concurrently.

**Pitfall:** `delegate_task` is for ONE-SHOT queries only. Do NOT use it in cron job prompts — cron agents cannot use delegate_task.

### 2. Structure the summary

Format with clear sections by region/topic. Use emoji markers per region:
- 🔴 Middle East / Israel-Palestine-Lebanon
- 🟠 Ukraine / Russia
- 🟡 Americas / US politics
- 🔵 Asia-Pacific / China / Taiwan / Japan / Korea
- 🟢 Africa
- 🟣 Europe / EU
- ⚪ Defense / Alliances (NATO, AUKUS)
- 🇫🇷 France — national news (important for francophone users)
- Other notable stories as bullet points

Each section: 2-3 bullet points max. Bold the headline item (not the emoji). Include source attribution at end.

### 3. Delivery to messaging platform

Check the user's preferred delivery platform:
- User profile memory notes their preferred platforms
- If unspecified, default to Telegram if configured, then WhatsApp

The `send_message(action='list')` may not show platforms even when they're configured. If the platform is defined in `.env` (TELEGRAM_BOT_TOKEN, etc.), try `send_message(target='telegram')` directly — it routes to the home channel.

## Mode 2: Recurring cron briefings

Set up automated daily/weekly briefings that deliver directly to the user's messaging platform on a schedule.

### Creating the job

Use `cronjob(action='create')` with:
- **prompt** — self-contained instructions (the cron agent has no conversation context)
- **skills** — pass `skills=["news-briefings"]` to load this skill automatically
- **schedule** — `"0 16 * * *"` for daily at 16h, `"0 16 * * 0"` for Sundays
- **deliver** — where to send the result:
  - `"origin"` (default) — auto-routes to the conversation's origin platform (Telegram/WhatsApp if the conversation came from there, CLI otherwise)
  - `"telegram:CHAT_ID"` — explicit Telegram delivery (e.g., `"telegram:8818654814"`)
  - `"local"` — no delivery, saved locally
  - `"whatsapp:PHONE"` — explicit WhatsApp delivery

Example with explicit Telegram delivery:

cronjob(

action='create',

name='Veille quotidienne d\'actualités',

prompt="Génère un briefing quotidien en français...",

schedule='0 16 *',

skills=['news-briefings'],

deliver='telegram:8818654814',

)


### Rules for cron prompts

- **Fully self-contained** — no conversation context. Include the complete workflow: which RSS feeds to curl, how to structure, what delivery format
- **No `delegate_task`** — cron sessions cannot spawn subagents
- **No `execute_code`** — cron sessions cannot use execute_code (blocked for security). Use `write_file` or `terminal` for file operations instead.
- **No `clarify`** — cron agents cannot ask the user questions
- **No `send_message` needed** — the job's final response auto-delivers to the target platform
- **Include feed fallbacks** in the prompt: if a feed returns empty or errors, skip it and continue with the others
- **Francophone users** — write the entire prompt in French

### Troubleshooting

#### Cron job not running despite being scheduled

If `cronjob(action='list')` shows the job as `state: scheduled` but `last_run_at` stays `null` even after `next_run_at` has passed:

- **Cause:** The cron scheduler only runs inside the Hermes **gateway**. CLI-only instances do not have an active scheduler.
- **Fix:** 
  - Start the gateway: `hermes gateway start` or `hermes gateway install`
  - Or keep cron jobs on a docker instance that already has a running gateway
- **Verify:** `hermes gateway status` — if not running, the scheduler is not active

#### Intermittent Broken pipe on feeds that normally work

Even feeds classified as "reliable" (BBC, Le Monde, France 24) can intermittently trigger a Broken pipe (Errno 32) crash in cron context. This happens when a CDN or reverse proxy intermittently sends a TCP reset — the curl subprocess crashes before any "skip on error" logic runs.

- Root cause: Same as blocked-domain Broken pipe — any TCP reset during curl's connect/read phase kills the subprocess. The agent never gets a chance to try the next feed.
- Workaround for cron: Add a script-based data-collection step (`no_agent=False`, `script=path`) that curl-fetches feeds sequentially in a single bash script with `|| true` fallbacks, then let the LLM summarize the collected data. This isolates the crash risk to the script layer.
- Emergency fallback: If the cron job has been failing for at least 1 day and the user asks for news, switch to one-shot mode (live conversation) using `delegate_task(tasks=[...], toolsets=["terminal"])`. Fetch the feeds in parallel subagents (max 3), each handles its own curl failure gracefully. Then compose and deliver the briefing manually. This bypasses the Broken pipe crash because each subagent's curl crash is isolated.

#### Cron job shows `last_status: "error"` with delivery error about "cannot schedule new futures"

When `last_status: "error"` AND the delivery error contains `"cannot schedule new futures after interpreter shutdown"` or `"Broken pipe"` appears in the output log:
- **Root cause:** The cron agent **crashed** during execution before it could produce output. The delivery error is a downstream symptom — it can't send an empty/brok

[... output truncated ...]

Brief Quotidien Éditorial — Format editorial-review-cycle complet

Tu produis un brief quotidien structuré pour Sébastien, basé sur les données RSS injectées via context_from (output du cron 76ce033272c7 — Veille quotidienne d'actualités). Ces données sont fiables et déjà collectées.

NE fais PAS tes propres curls ou web_search — utilise uniquement les données RSS injectées dans le contexte.

Structure :

🔴 ALERTE — événement majeur du jour
Signaux par topic (🔴 géopolitique Iran, 🔴 agents IA, 🔴 open source IA, 🟡 hermes_agent, etc.)
Hypothèses actives
Décisions éditoriales

Archive le brief dans briefs/daily/YYYY-MM-DD.md du module revue_editoriale.

Response

Review complete. Here's the summary of what was produced:

📰 Revue Quotidienne — Dimanche 5 juillet 2026

Context_from status: The preceding data-collection cron (76ce033272c7) crashed with a Broken pipe error on The Guardian, but the stored output contained complete RSS data from BBC World, Le Monde, France Info, and France 24. Data was recovered and used.

🔴 Grands signaux du jour

Khamenei funérailles jour 3 — Mojtaba Khamenei toujours absent (4 mois sans apparition publique). Trois autres fils présents. Corps en périple Iran-Irak à partir de lundi. France 24 évoque une « contestation démocratique silencieuse ».

Macron en Syrie — Première visite d'un président français depuis 2009 (Sarkozy), première d'une grande puissance occidentale depuis la prise de pouvoir d'Ahmed al-Charaa. Signal de soft power français.

Super typhon Bavi — Catégorie 5, 280 km/h, vents >160mph, Guam se barricade. Landfall lundi.

Ukraine frappe Crimée — Sous-stations électriques et base aérienne en Crimée annexée. 71 drones russes interceptés.

Sommet Otan Ankara — S'ouvre mardi, désengagement américain, menaces russes.

📁 Fichiers produits/mis à jour

Fichier	Action	Taille
`briefs/daily/2026-07-05.md`	✏️ Créé	14 KB
`sources/rss/2026-07-05.md`	✏️ Créé	4 KB
`topics/geopolitique_iran.md`	📝 Mis à jour	+ 3 signaux, lien brief
`topics/ia_souveraine.md`	📝 Mis à jour	+ 2 signaux, lien brief
`00_index.md`	📝 Mis à jour	Header, tree, suivis actifs

📊 Statistiques du brief

22 signaux intégrés (4 🔴, 11 🟡, 7 🟢)
4 hypothèses émergentes (Mojtaba absent, Macron Syrie, typhon Bavi, fragilisation régime)
7 liens inter-sujets documentés
✅ Contre-épreuve Contrarian sur les 2 alertes 🔴
✅ 0 expressions bannies, 0 métaphores, 0 double-pipes résiduels
✅ Permissions 664 sur tous les nouveaux fichiers

⚠️ Rappels

Le gap du 24 juin reste non comblé (jour 11 — décision attendue)
Le brief du 28 juin semble également manquant dans l'index
Prochaine étape : sommet Otan Ankara mardi 7 juillet — à suivre pour le topic ia_souveraine