iris-harness 0.1.0__py3-none-any.whl

iris_harness/__init__.py

@@ -0,0 +1,5 @@
+"""IRIS package root."""
+
+__all__ = ["__version__"]
+
+__version__ = "0.1.0"

iris_harness/_data/config/behaviors/reminders.default.md

@@ -0,0 +1,42 @@
+---
+name: reminders
+description: How IRIS handles requests to remember, schedule, or follow up on something later.
+match_intents: [calendar]
+match_keywords: [remind, reminder, reminders, follow up, follow-up, schedule, deadline, by sunday, by monday, by tuesday, by wednesday, by thursday, by friday, by saturday]
+---
+
+# Behavior — Reminders
+
+When the user asks to be reminded of something, scheduled for something, or
+followed up on by a date, treat it as a durable commitment — not a passing
+chat turn. The reminder must survive process restarts and be findable in a
+future session.
+
+## Recipe
+
+1. **Confirm the intent in one short sentence.** No preamble; state what
+   you're capturing and the date/time you parsed. If the time is ambiguous,
+   ask exactly one question, then stop.
+2. **Call `add_reminder`** (or the `create_reminder` tool in the loop). It
+   writes the reminder to the one reminder store: a calendar reminder event
+   plus its delivery row, delivered on the user's channels at that time.
+   Dates and times are the user's local time.
+3. **Use the calendar event tools only for events.** `add_calendar_event`,
+   `edit_calendar_event` and `delete_calendar_event` manage standalone
+   events; a reminder is never written by hand or to a file.
+4. **Tell the user when it will fire.** One line: the reminder text and its
+   local date and time. Do not bury this in a long response.
+5. **Do not invent recurrence.** If the user did not say how often it
+   repeats, create a one-time reminder and state that assumption briefly.
+
+## What to avoid
+
+- Writing a reminder to any file (a markdown table, `~/.iris/reminders/`,
+  `~/.iris/sandbox/<random-hash>/`) — the reminder store is the only place a
+  reminder lives, and only `add_reminder` / `create_reminder` write it.
+- Silently dropping the reminder into chat history with no persistence.
+- Long acknowledgement messages. The user wants the commitment captured,
+  not a recap.
+- Asking more than one clarifying question. If multiple things are unclear,
+  pick the most blocking one and proceed with sensible defaults for the
+  rest, then state the assumptions you made.

iris_harness/_data/config/channels.yaml

@@ -0,0 +1,29 @@
+# Channel Gateway configuration.
+# Each channel maps a logical name to a connector type and parameters.
+# Environment-style placeholders (e.g. ${TELEGRAM_BOT_TOKEN}) are resolved
+# from os.environ at runtime. Channels with unresolved required vars are
+# silently skipped.
+#
+# default: name of the channel used for heartbeats and proactive notifications.
+# Falls back to "console" if the named channel fails to register. The check runs
+# after the channel plugins mount, so naming a plugin-provided surface here works.
+#
+# Which connector serves a row: `console` is core (the guaranteed fallback);
+# `telegram` comes from the telegram_channel plugin and `web` from web_channel, so
+# a profile that does not mount them simply has no such surface (OSS plan M4.5).
+default: telegram
+
+channels:
+  - name: console
+    type: console
+    description: Local development sink that writes to stdout.
+
+  - name: telegram
+    type: telegram
+    description: Personal Telegram bot for proactive notifications.
+    bot_token: ${TELEGRAM_BOT_TOKEN}
+    default_chat_id: ${TELEGRAM_CHAT_ID}
+
+  - name: web
+    type: web
+    description: The web UI's chat — a proactive notice lands in its session history.

iris_harness/_data/config/cron/audit-compact.cron

@@ -0,0 +1,8 @@
+# IRIS audit compaction (Phase 5)
+# Runs every day at 02:30 local time.
+#
+# Install example:
+#   crontab -e
+#   30 2 * * * /path/to/.venv/bin/iris audit compact >> /var/log/iris-audit-compact.log 2>&1
+
+30 2 * * * iris audit compact

iris_harness/_data/config/digest.yaml

@@ -0,0 +1,238 @@
+# The morning digest's defaults (loop-proof plan D3-D5, ADR-0122).
+#
+# This file is the DEFAULT. The owner's changes from Settings -> Digest (or from chat:
+# "add X to my digest") are saved on the data volume (settings.db, section `digest`,
+# ADR-0120) and laid over it by `load_digest_settings`
+# (src/iris_harness/services/digest/settings.py). A deploy that changes this file
+# changes every field the owner has not changed.
+
+# Send the morning digest at all.
+enabled: true
+
+# Local time the digest goes out, HH:MM in IRIS_TZ (UTC when IRIS_TZ is unset).
+time: "07:00"
+
+# Jobs the digest runs, in order, right before it renders (loop-proof PR 5): mail is
+# swept and judged first so the digest never shows a stale or half-judged inbox. Each
+# runs like the Heartbeats screen's "Run now" (a kept run the job checks count), on the
+# scheduled digest and on a manual "run the digest now" alike. `if_setting` names an
+# on/off setting, read with its declared default; the job runs only while it is on. A
+# job that is not registered or is turned off is skipped (logged); one already running
+# is waited for, not started twice. Once `run_first_budget_seconds` is spent no further
+# job starts. A job that fails never stops the digest. Not edited from the app.
+run_first:
+  - heartbeat: email_sweep
+    if_setting: IRIS_EMAIL_JUDGE   # only while the email judge is on
+  - heartbeat: email_judge
+    if_setting: IRIS_EMAIL_JUDGE
+# 240 s keeps the digest on time: it fires 5 minutes early, and by then the 06:15 / 06:30
+# runs have done most of the work; mail not reached waits and the digest says so.
+run_first_budget_seconds: 240
+
+# Where it goes: `all` = every rendering (web stored, Telegram chunked, push
+# headline), or a comma-separated list of channel names.
+channel: all
+
+# The brief's tool-slot names, in the order they appear: the groups' order below, then
+# the sections in no group, `learned_yesterday` last. A slot the brief skill does not
+# have is skipped at render time. A section added here later reaches an owner who
+# reordered their digest too: it slots in after the section it follows here (last if
+# last). Within a group, sections show in this (the owner's) order.
+sections:
+  - todays_plan
+  - todays_events
+  - due_today
+  - overdue
+  - missed_reminders
+  - reminders
+  - open_tasks
+  - bills_due
+  - unusual_spend
+  - portfolio
+  - needs_reply
+  - focus
+  - judged_yesterday
+  - email_summary
+  - open_followups
+  - resolved_followups
+  - indexes
+  - stocks
+  - news_ai
+  - news_global
+  - news_local
+  - active_items
+  - routines
+  - learned_yesterday
+
+# Sections the digest knows but leaves off until the owner turns them on in Settings ->
+# Digest (the brief skill keeps the slot). Trending GitHub repos are opt-in.
+sections_off:
+  - top_repos
+
+# Always shown, always last, whatever the owner's list says: the footer that says what
+# IRIS learned yesterday (D17) is never omitted, and is in no group.
+locked_sections:
+  - learned_yesterday
+
+# The digest's layout (digest v5, prototype signed off 2026-09-25): the sections under
+# a few headed groups, in this order. A section in no group (active_items, routines,
+# top_repos when on) goes in a last group, "More". `push` is the group's line in the
+# phone notification: a format string over the number of items each of its sections
+# has ({bills_due} = how many bills are due); a group with no `push` has no line.
+# Owner-facing wording; change it here, not in code.
+groups:
+  - id: today
+    title: Today
+    icon: "☀️"
+    sections: [todays_plan, todays_events, due_today, overdue, missed_reminders, reminders, open_tasks]
+    push: "Events {todays_events} · Due today {due_today} · Tasks {open_tasks}"
+  - id: money
+    title: Money
+    icon: "💳"
+    sections: [bills_due, unusual_spend, portfolio]
+    push: "Bills {bills_due}"
+  - id: inbox
+    title: Inbox
+    icon: "📬"
+    sections: [needs_reply, focus, judged_yesterday, email_summary, open_followups, resolved_followups]
+    push: "Focus {focus}"
+  - id: markets
+    title: Markets
+    icon: "📈"
+    sections: [indexes, stocks]
+  - id: news
+    title: News
+    icon: "📰"
+    sections: [news_ai, news_global, news_local]
+
+# How each channel renders the groups.
+#   web       every group, a sub-heading per section; empty sections fold into one
+#             "nothing ..." line; links on the source name.
+#   telegram  one message per group, a card (quote block) per section, news in
+#             expandable cards; empty sections and empty groups are not sent; the last
+#             message has buttons to the full digest and Settings. `rule` is an optional
+#             line under each group heading ("" = none, the default: on a phone a
+#             fixed-length rule wraps at larger text sizes — owner 2026-09-25).
+#   web_push  a glance: one line per group from its `push`, at most `lines`, never the
+#             excluded groups; tapping opens the web copy.
+channels:
+  web: {layout: grouped, empty: fold, links: source}
+  telegram:
+    layout: message_per_group
+    section: card
+    news: expandable_card
+    empty: hide
+    links: source
+    buttons: [full_digest, settings]
+    rule: ""
+  web_push: {layout: headline, lines: 3, exclude_groups: [news, markets]}
+
+# When dated items leave the digest (owner rule 2026-09-25): every dated item ends
+# CLOSED (done, paid or dismissed by the owner) or EXPIRED (aged out, below). The
+# digest shows only open, unexpired items; an expired task stays in the store with
+# status `expired` and the reason. Days are the owner's local days (IRIS_TZ): a task
+# due Sep 22 with task_overdue_days 3 shows as Overdue Sep 23-25, expired from Sep 26.
+#   prep_after_event          minutes after its meeting ends, a prep task expires
+#   event_after_end           minutes after it ends, a calendar event leaves the digest
+#   task_overdue_days         days a dated task shows under Overdue, then expires
+#   bill_ask_days             days after its due date an unpaid bill is asked about
+#                             ("Did you pay?"), then
+#   bill_overdue_digest_days  days it stays in the digest before it expires
+#   inbox_notice_days         days a dated inbox notice stays in the digest
+#   reminder_missed_digests   digests a missed reminder is carried into
+# A plugin's own kinds are tuned here too, by the key its manifest declares under
+# `expiry:` (default and range are there): the email plugin's needs_reply_days (3) and
+# unsure_card_days (7), for example. A key no installed plugin declares is refused.
+expiry:
+  prep_after_event: 0
+  event_after_end: 0
+  task_overdue_days: 3
+  bill_ask_days: 3
+  bill_overdue_digest_days: 7
+  inbox_notice_days: 3
+  reminder_missed_digests: 1
+
+# Per-section knobs, e.g. {bills_due: {within_days: 7, line_cap: 5}}. `line_cap` is how
+# many lines a section shows (Settings -> Digest writes it); chat writes the dues
+# window and categories.
+section_config:
+  # Top 3 per news group (9 headlines), top 5 for the other long lists; change any of
+  # them in Settings -> Digest ("lines").
+  news_ai: {line_cap: 3}
+  news_global: {line_cap: 3}
+  news_local: {line_cap: 3}
+  stocks: {line_cap: 5}
+  indexes: {line_cap: 5}
+  top_repos: {line_cap: 5}
+
+# The digest's news, one section per group. Each topic becomes one research query
+# ("<topic> news"); a title or topic may say {news_local_area}. Settings -> Digest edits
+# each group's topics. `news_sources` and `news_language` below apply to all of them.
+news_groups:
+  news_ai:
+    title: AI / Tech
+    topics: [AI, technology]
+  news_global:
+    title: Global
+    topics: [world]
+  news_local:
+    title: "Local — {news_local_area}"
+    topics: ["{news_local_area}"]
+
+# The place the local news is about (Settings -> Digest).
+news_local_area: St. Louis
+
+# Topics for a news fetch that names no group (an ad-hoc `digest-topics` fetch); the
+# digest's own news uses `news_groups` above.
+news_topics:
+  - AI
+  - world
+
+# Preferred source domains, ranked first when they have a story. Never a strict
+# allowlist (D4): a topic with no story from these still shows the best others.
+news_sources: []
+
+# The language the news is in: a two-letter ISO 639-1 code, or `any`. Asked of the
+# search provider where it can (DuckDuckGo region, SearXNG/Brave language) and checked
+# on every headline (its writing script), so a Japanese headline never lands in an
+# English digest. A topic whose every result is in another language counts as failed,
+# so the digest names the section instead of printing it empty.
+news_language: en
+
+# Focus: the newest emails in these triage categories (ADR-0017 topic paths; a path
+# matches itself and everything under it), minus senders marked "not useful". The
+# newest `focus_per_account` from each inbox, then newest first across them, at most
+# `focus_limit` in all (Settings -> Digest edits both).
+focus_categories:
+  - email/personal
+  - email/family
+  - email/finance
+  - email/community
+focus_limit: 10
+focus_per_account: 5
+
+# An old section name -> the section(s) that replaced it. Applies to the owner's saved
+# settings whenever they are read (a saved `news` is the three news groups, on or off
+# together) and to the brief_prefs.json move below. A section split into several
+# leaves its per-section settings (lines) behind: each part takes this file's.
+renamed_sections:
+  news: [news_ai, news_global, news_local]
+  ai_news: news_ai
+  global_news: news_global
+
+# The one-time move of data/brief_prefs.json into the settings store.
+#   new_sections  did not exist when that file was written, so its silence about them
+#                 is not the owner turning them off.
+#   dropped_sections  left off even when that file had them on (the old tool wrote
+#                 every section on); the owner turns them back on in Settings.
+brief_prefs_migration:
+  new_sections:
+    - focus
+    - judged_yesterday
+    - learned_yesterday
+    - missed_reminders
+    - needs_reply
+    - news_local
+    - overdue
+  dropped_sections:
+    - top_repos

iris_harness/_data/config/docs_search.yaml

@@ -0,0 +1,40 @@
+# The corpus the `search_docs` tool may search (services/docs_search/). It is an
+# ALLOW-LIST: the tool reads these directories and nothing else, and every path it
+# opens is resolved and checked to sit inside one of them (symlinks and `..` refused).
+# Nothing here can name the identity files (SOUL/USER/AGENTS), the vault, a .env, the
+# user's data directories or any store: they are not under these roots, and a root that
+# overlaps IRIS_HOME / the data or governance directories is refused at load.
+#
+# This shipped file is the allow-list. A docs_search.yaml under IRIS_CONFIG_DIR can only
+# NARROW it (roots and extensions intersect, limits take the smaller value); a root it adds
+# is ignored. Every root must be a plain relative path under docs/.
+#
+# Roots are relative to the source checkout and are shipped documentation only. The docs
+# are not package data, so on an installed wheel none of them exist and the tool says
+# "docs not present on this install" instead of searching anywhere else. Adding a root is
+# a security decision: it must hold nothing the owner would not publish.
+roots:
+  - docs/architecture   # includes docs/architecture/adrs/ where present
+  - docs/concepts
+  - docs/guides
+  - docs/reference
+  - docs/usage-guides
+
+# Only these file types are read, from inside the roots.
+extensions:
+  - .md
+
+# Bounded work: a runaway tree costs a capped, deterministic amount.
+limits:
+  max_files: 400            # documents indexed; more are ignored (the result says so)
+  max_file_bytes: 400000    # a larger file is skipped, not truncated
+  max_total_bytes: 8000000  # across all documents
+  max_query_chars: 200
+  max_query_terms: 8
+  default_results: 5
+  max_results: 10
+  snippet_chars: 240
+  max_output_chars: 4000
+  scan_chunk_chars: 4000    # the secret scan sees a document in pieces of this size
+  scan_budget_ms: 2000      # a document that uses this up scanning is withheld
+  scan_total_ms: 10000      # per call; documents not yet scanned wait for the next call

iris_harness/_data/config/doctor.yaml

@@ -0,0 +1,45 @@
+# `iris doctor` -- the install preflight (OSS plan R5, milestone L1).
+#
+# Thresholds and the starter model set live here, not in code. The supported Python
+# range is not repeated: doctor reads it from the installed package's metadata
+# (pyproject's `python = ">=3.12,<3.14"`).
+
+# Host memory, total (not free). Below `demo_gb` IRIS cannot run; between the two it
+# runs the synthetic demo on the scripted model but not local models for real use.
+ram:
+  floor_gb: 16
+  demo_gb: 8
+
+# Where IRIS runs (platform.system() / platform.machine(), lowercased). Anything else
+# is a warning; native Windows is refused with a pointer to WSL2.
+platforms:
+  darwin: [arm64]
+  linux: [x86_64, amd64, aarch64, arm64]
+
+# Free space on the volume under IRIS_HOME: the missing starter models' size (below)
+# plus this much for data (mail stores, indexes, the audit ledger). Below that is a
+# failure; below `warn_free_gb` a warning.
+disk:
+  data_headroom_gb: 2
+  warn_free_gb: 20
+
+# The starter model set: what `iris doctor --fix` pulls when it is missing. R5 plans a
+# single-model `starter` set gated on the models-by-capability ADR's proof (draft, not
+# merged); until that lands the fallback starter is `qwen2.5:7b-instruct` alone.
+# `size_gb` is the download size shown before a pull (Ollama's API cannot say it before
+# the pull starts).
+starter_models:
+  - name: qwen2.5:7b-instruct
+    size_gb: 4.7
+
+# Optional extras: reported as information, never a failure. `module` is what is
+# importable when the extra is installed.
+optional_extras:
+  # Without it the Gmail plugin does not load, so an unnamed run stays on the `default`
+  # profile and there is no `iris email` (config/profiles/default.yaml).
+  - name: email
+    module: googleapiclient
+    purpose: the email assistant (`iris email`, Gmail)
+  - name: ml
+    module: sentence_transformers
+    purpose: semantic email discovery and BGE rerank

iris_harness/_data/config/escalation.yaml

@@ -0,0 +1,74 @@
+# Tier-escalation judge (ADR-0068, docs/architecture/escalation-judge.md).
+#
+# A Response Curator head that, after a cheap Tier-1 answer, DIAGNOSES why the
+# answer fell short and decides the next course — escalate to a stronger tier,
+# clarify with the user, or reroute to a tool. YAML-first: thresholds and
+# budgets are policy, not code.
+#
+# Rollout discipline mirrors the governance enforce flips: ship in `shadow`
+# (decide + log + record the counterfactual, never act), validate that the
+# decision tracks real outcomes, only then flip to `enforce`.
+#
+# enforce mode acts on all three diagnoses: escalate (capability_gap -> re-run at
+# a stronger LOCAL tier), reroute (grounding_gap -> re-run same tier with a
+# grounding/tool directive), clarify (ambiguity -> ask the user, gated by
+# clarify_confidence_floor). Bounded by max_escalations + resource-governor veto,
+# egress-safe (local tiers only). Default mode keeps all acting off until an
+# operator flips it after reviewing shadow precision.
+version: 1
+
+# Master opt-in. The env flag IRIS_CURATOR_ESCALATION overrides this (matching
+# the IRIS_CURATOR_* judge family). Default off so normal chat is unaffected.
+enabled: false
+
+# shadow = decide + log + record, never act.
+# enforce = act on escalate, reroute and clarify (live, L3), each confidence-gated.
+mode: shadow
+
+# Hops above the start tier allowed per turn when acting. Bounded retry, never an
+# unbounded "judge says escalate" loop.
+max_escalations: 1
+
+# The judge model tier — must be >= the generator tier (judge a Tier-1 output
+# with a Tier-2 judge); the judge never both generates and promotes its output.
+# The judge is built from this tier; if it is missing from llm_tiers.yaml the
+# judge is off rather than falling back to a weaker model.
+judge_tier: tier2
+
+# Fraction of judged turns the shadow judge evaluates (cost control for the
+# shadow data-collection pass). 1.0 = every judged turn.
+sample_rate: 1.0
+
+# clarify fires only above this confidence; asking too often is worse than a
+# mediocre answer, so prefer escalate/reroute when the answer is knowable.
+clarify_confidence_floor: 0.7
+
+# escalate / reroute act only at or above this confidence. Both re-run the plan and
+# replace the answer, so a verdict the judge itself is unsure of must not act.
+action_confidence_floor: 0.7
+
+# Defer to the governance cost cap + resource-governor veto when acting (L3+).
+cost_aware: true
+
+# L5 predictive start-tier priors. The escalation-priors tick mines
+# escalation_shadow history per intent; an intent that reliably escalates gets
+# its START tier raised so routing is predictive, not reactive. Env override:
+# IRIS_CURATOR_ESCALATION_PRIORS. When disabled the recommendations are computed
+# and logged (shadow) but NOT applied to the router — same shadow -> validate ->
+# enforce discipline.
+priors:
+  enabled: false
+  min_samples: 20          # per-intent turns before a prior is trusted
+  window_hours: 168        # history window mined for the rate (1 week)
+  escalate_rate: 0.4       # bump start tier when escalate-rate clears this
+
+# Cloud escalation (ADR-0068 D4). OFF by default: escalation targets local tiers
+# only, so personal/secret content can never leave the box. When enabled,
+# escalation MAY target a cloud tier — but only when the content being sent
+# classifies into `classifications` (the data classifier runs on the prompt +
+# answer + memory context). `secret` is NEVER eligible, even if listed. The
+# governance kernel's egress gate remains the final backstop. Env override:
+# IRIS_CURATOR_ESCALATION_CLOUD.
+cloud:
+  allow: false
+  classifications: [public]   # widen to [public, internal] only after review; secret never

iris_harness/_data/config/governance/egress.yaml

@@ -0,0 +1,26 @@
+# Where each data class may be sent: the egress gate's policy (EgressGate, PreLLMCall;
+# docs/architecture/unified-governance-layer.md §6.3). Read once, when the kernel is built.
+#
+# The tiers mean where a model runs, never what it is called (llm/locality.py): tier_1 and
+# tier_2 are models on the owner's machines (a provider declared `runs: local` in
+# llm_tiers.yaml), tier_3 leaves them (`runs: cloud`, or undeclared). "Local" includes a
+# host the owner controls reached over the owner's own tailnet -- the cloud VM uses the
+# Mac's Ollama that way -- never a third party's service.
+#
+#   max_tier       the furthest tier a prompt of this class may reach
+#   on_violation   what a call beyond it gets: deny | require_approval (default deny)
+#
+# secret is local only (owner, 2026-09-30): any local model, never tier_3, and a violation
+# is always a hard deny. The loader refuses a table that loosens that, so no edit here can
+# send a secret off the owner's machines.
+classes:
+  secret:
+    max_tier: tier_2
+    on_violation: deny
+  personal:
+    max_tier: tier_2
+    on_violation: require_approval
+  internal:
+    max_tier: tier_3
+  public:
+    max_tier: tier_3

iris_harness/_data/config/governance/identity.yaml

@@ -0,0 +1,49 @@
+# Owner identity policy (ADR-0125; docs/architecture/owner-pii-masking.md).
+#
+# ontology_kinds: which attributes of the owner's CONFIRMED memory facts are the owner's
+# identity, and as which kind (name, email, phone, address, handle, link). Only statements
+# whose subject is the owner count, so a contact's name never becomes owner PII. The keys
+# are attributes of config/memory/ontology.yaml; this mapping lives here, never in the
+# ontology (memris refuses unknown keys and knows no IRIS vocabulary).
+#
+# blog and website are `link`: egress refuses to send a link, so a confirmed blog or
+# website joins what it refuses (ADR-0125 amendment 6).
+ontology_kinds:
+  name: name
+  nickname: name
+  email: email
+  phone: phone
+  github: handle
+  linkedin: handle
+  blog: link
+  website: link
+
+# guards: what each guard does with an occurrence of each kind (owner, 2026-09-30).
+#
+#   egress        network tool arguments          deny | log | pass
+#   answer_owner  an answer to the owner          halt | mask | pass
+#   answer_other  an answer anyone else reads     halt | mask | pass
+#   capability    a capability result             mask | pseudonym | pass
+#   tier3         a prompt to a tier-3 model      placeholder | pass
+#   web_search    web-search arguments            deny | mask | pass
+#
+# pseudonym: the consumer sees [owner:<kind>#<n>] unless its manifest grants the kind
+# (capabilities: uses: - <capability>: {unmask: [<kind>, ...]}). secret is masked and never
+# unmasked. Only the capability column acts in PR 3; PR 4 audits the rest in shadow.
+guards:
+  kinds:
+    secret:  {egress: deny, answer_owner: halt, answer_other: halt, capability: mask,      tier3: placeholder, web_search: deny}
+    link:    {egress: deny, answer_owner: pass, answer_other: pass, capability: pass,      tier3: pass,        web_search: deny}
+    name:    {egress: log,  answer_owner: pass, answer_other: mask, capability: pseudonym, tier3: pass,        web_search: mask}
+    email:   {egress: deny, answer_owner: pass, answer_other: mask, capability: pseudonym, tier3: placeholder, web_search: deny}
+    phone:   {egress: deny, answer_owner: pass, answer_other: mask, capability: pseudonym, tier3: placeholder, web_search: deny}
+    address: {egress: deny, answer_owner: pass, answer_other: mask, capability: pseudonym, tier3: placeholder, web_search: deny}
+    handle:  {egress: log,  answer_owner: pass, answer_other: mask, capability: pseudonym, tier3: pass,        web_search: mask}
+  # A name literal of one word (a first name, a nickname): masked only in web-search
+  # arguments, and it never denies or halts anywhere (ADR-0125 decision 4).
+  first_name_alone: {egress: log, answer_owner: pass, answer_other: pass, capability: pass, tier3: pass, web_search: mask}
+  # Network tools (fnmatch) where an egress deny of these kinds is only logged, until a
+  # per-destination allowlist exists. Never secret or link: egress refuses both today.
+  log_only_destinations:
+    tools: ["github_*", "mcp_*"]
+    kinds: [email, phone, address]

iris_harness/_data/config/governance/mcp-serve.yaml

@@ -0,0 +1,18 @@
+# `iris mcp serve`: the MCP clients the owner serves IRIS's tools to
+# (src/iris_harness/runtime/mcp_serve.py; examples/08-mcp).
+#
+# `iris mcp serve --client NAME` must name a client listed here; every call is governed
+# and audited as `mcp:NAME`. The name is the owner's (it sits in the client's config the
+# owner writes); what a client says about itself decides nothing.
+#
+# local: true  -- the client runs on this machine and the owner accepts that results
+#                 holding their personal data reach it.
+# local: false -- (the default) a result labelled personal is withheld from it.
+# A result labelled secret is withheld from every client, local or not.
+#
+# The owner's own list goes in $IRIS_HOME/mcp-serve.yaml (same shape); its entries win
+# over these.
+clients:
+  # The default when --client is not given: treated as not local.
+  stdio:
+    local: false

iris_harness/_data/config/governance/mcp-signing.yaml

@@ -0,0 +1,11 @@
+# MCP server signing policy (Governance Phase 6 supply-chain workstream).
+# See docs/architecture/mcp-server-signing.md.
+# Sub-phase 6b.1 ships the loader; the bridge gate + enforcement land in 6b.2+.
+version: 1
+enabled: true
+# shadow = verify + audit but never block; flip to enforce once your servers are
+# signed and the audit is clean (see the doc's enforce-flip runbook).
+mode: shadow
+# Action under enforce for an unsigned / untrusted / invalid server.
+unsigned_policy: warn
+trust_store: config/governance/mcp-trust.yaml

iris_harness/_data/config/governance/mcp-trust.yaml

@@ -0,0 +1,12 @@
+# Root of trust for MCP server signatures (operator-managed).
+# The IRIS agent process must NOT have write access to this file.
+# Add public keys with `iris mcp keygen --id <key_id>` (CLI lands in 6b.3),
+# then sign servers with `iris mcp sign <server> --key <key_id>`.
+version: 1
+keys: []
+# Example (do not use this fabricated key):
+#   - key_id: ops-2026
+#     public_key: <base64 ed25519 public key>
+#     comment: "primary signing key"
+revoked_key_ids: []
+revoked_signatures: []

iris_harness/_data/config/governance/sandbox.yaml

@@ -0,0 +1,13 @@
+# Sandbox runtime selection (Governance Phase 6 hardening workstream).
+# See docs/architecture/sandbox-hardening.md.
+# Default runtime: docker → today's behavior unchanged. gVisor lands in 6c.2;
+# Firecracker is evaluated/deferred. gVisor/Firecracker are Linux-only — on
+# macOS the runtime check fails and falls back to docker.
+version: 1
+runtime: docker            # docker | gvisor | firecracker (IRIS_SANDBOX_RUNTIME overrides)
+on_unavailable: fallback   # fallback (→ docker, logged) | disable (no code_exec)
+limits:
+  memory: 1g
+  cpus: "2"
+  pids_limit: 256
+  timeout_seconds: 30

iris_harness/_data/config/governance/taint-policy.yaml

@@ -0,0 +1,18 @@
+# Tools that need the owner's approval for a call made AFTER the run read outside text
+# (issue #149).
+#
+# Outside text is the result of any tool that declares `content: external` (a web page, an
+# email, a document, an MCP server's answer). Redaction of instruction-like phrases is
+# phrase-level, so a model that read such text can still be steered toward a harmful action.
+# A write to memory is the realistic sink: a poisoned fact outlives the turn. So in a run that
+# has an external observation, a call of a tool listed here is held for the owner's
+# approval on the same card the other approved-per-call tools use, and says why. The same
+# call in a run that read nothing from outside is unchanged. The next user message starts a
+# clean run.
+#
+# Names only, no wildcards. A file that is missing, unreadable or malformed falls back to
+# the three tools below; removing a name here is the owner's decision.
+approval_when_tainted:
+  - memory_correct
+  - memory_forget
+  - memory_restore