@aitne-sh/aitne 0.1.11 → 0.1.13

package/agent-assets/docs/features/lifestyle/git.md

@@ -28,7 +28,6 @@ tags:
   - github
   - autonomous
   - observations
-  - core
 status: stable
 ask_examples:
   - What is the My Life › Git page for?
@@ -46,7 +45,7 @@ ask_examples:
   - How much does one Architecture refresh cost?
 locale: en-US
 created: 2026-05-05
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - my life
   - git
@@ -102,18 +101,18 @@ The page lists every repository registered on
 **Connections → Repositories** and exposes three collapsible sections
 per repo (all open by default so the controls are visible at a glance):
 
-1. **Polling** — overrides the global `gitPollIntervalSeconds` for
-   this repository alone. Useful when one repo is high-traffic and
-   you want it scanned more aggressively (or vice-versa). Also shows
-   the most recent observations gathered from that repo's polling
-   sources.
+1. **Polling** — how often the agent checks this repo for new
+   activity. It overrides the global `gitPollIntervalSeconds` for
+   this repository alone, which is handy when one repo is busy and you
+   want it scanned more often (or the reverse). It also shows the most
+   recent observations gathered from that repo's polling sources.
 2. **Triggers** — fire when matching Git or GitHub events arrive on
    this repository. Triggers run **alongside** the project-wide
    task-flow defaults, not in place of them. Each trigger has a
    workdir mode (`local-clone` or `temp`); local-clone triggers
    require the repository to have a `localPath`.
 3. **Daily git management** — opt-in per repo. Enabling it does three
-   distinct kinds of work, on different cadences:
+   distinct kinds of work, each on its own schedule:
    - On the first **Generate overview** click, writes the curated
      `knowledge/repos/<slug>/overview.md` skeleton, mirrors the source
      `README.*` to `knowledge/repos/<slug>/README.md`, and

package/agent-assets/docs/features/lifestyle/reading.md

@@ -26,7 +26,7 @@ ask_examples:
   - Where do reading-list items get stored?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - reading
   - books
@@ -37,6 +37,7 @@ related:
   - features/memory-files/user-profile
   - features/lifestyle/receipts
   - features/lifestyle/travel-bookings
+  - pages/reading
 api_endpoints:
   - GET /api/books
   - PATCH /api/books/:id
@@ -52,7 +53,7 @@ ui_anchors:
 
 A reading list backed by the `books` and `reading_highlights` SQLite
 tables: imports your Kindle highlights, tracks each book's status
-(`reading`, `completed`, or `abandoned`), and surfaces the working set
+(`reading`, `completed`, or `abandoned`), and shows your current list
 at `/reading`.
 
 ## What It Does
@@ -65,14 +66,15 @@ at `/reading`.
     "Export Notebook" email.
 - **List** the library on `/reading` or via `GET /api/books`
   (filterable by `status` and `source`, paginated to 200 rows per call).
-- **Mark complete or abandoned** — an existing row is updated via
-  `PATCH /api/books/:id`. This is an **Approve-tier** write that requires
-  an operator `Authorization: Bearer` token, so it is driven from the
-  dashboard, not autonomously by the agent (an unauthenticated agent curl
-  is rejected with **401** before the handler runs). Setting `status` to
+- **Mark complete or abandoned** — `PATCH /api/books/:id` updates a book
+  that already exists. This is an **Approve-tier** write (a change that
+  needs your explicit sign-off), so it requires an operator
+  `Authorization: Bearer` token and runs from the dashboard rather than
+  on the agent's own initiative (an unauthenticated agent curl is
+  rejected with **401** before the handler runs). Setting `status` to
   `completed` stamps `completed_at` automatically; you can also set a 1–5
   `rating` or `notes`.
-- **Recommend** from the list during reactive turns, and refresh the
+- **Recommend** from the list when you ask in a chat, and refresh the
   reading-taste profile during the weekly review.
 
 There is **no bare "add a book" endpoint** — new books arrive through the
@@ -126,5 +128,6 @@ drives the list shape. The reading skill loads in two situations:
 
 ## Related
 
+- [Reading Page](../../pages/reading.md)
 - [Receipts](receipts.md)
 - [Travel Bookings](travel-bookings.md)

package/agent-assets/docs/features/lifestyle/receipts.md

@@ -16,7 +16,6 @@ summary: |
 section: lifestyle
 tags:
   - lifestyle
-  - receipts
   - mail
   - integrations
 status: stable
@@ -27,7 +26,7 @@ ask_examples:
   - What receipts haven't I saved yet?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - receipt
   - invoice
@@ -58,10 +57,10 @@ your external Obsidian vault on request.
 ## How Detection Works
 
 The mail observer scans travel-booking emails across every connected
-mail account and records each attachment it finds. Each detected
-attachment inserts a row into the `receipts` table, keyed uniquely on
-`(account_id, provider_msg_id, attachment_id)` so re-scans are
-idempotent. Columns:
+mail account and records each attachment it finds. Every detected
+attachment becomes one row in the `receipts` table. Each row is keyed
+uniquely on `(account_id, provider_msg_id, attachment_id)`, so
+re-scanning the same mail never creates a duplicate. Columns:
 
 - `category` — `travel` at detection time; reclassify to `document`
   via PATCH (nullable on legacy rows)
@@ -72,22 +71,22 @@ idempotent. Columns:
   vault (see below)
 - `id`, `created_at` — row identity and detection time
 
-There is no Markdown context file for receipts; the durable record is
-the SQLite row plus the optional Obsidian copy.
+There is no Markdown context file for receipts. The lasting record is
+the SQLite row, plus the optional Obsidian copy you save yourself.
 
 ## Saving a Receipt to Your Vault
 
-Saving is a two-step flow — the download endpoint never writes to the
-vault by itself:
+Saving takes two steps. The download endpoint never writes to the vault
+on its own:
 
-1. The agent downloads the original bytes via
+1. The agent downloads the original bytes with
    `POST /api/receipts/:id/download`, which streams the raw attachment
-   (resolved through the mail registry by `account_id`; oversized files
-   over 100 MB and orphaned rows with a null `account_id` are rejected).
-2. The agent writes the file into your **external** Obsidian vault — not
-   the primary management vault — under the convention
-   `receipts/YYYY/MM/<merchant>-<date>.<ext>` (e.g.
-   `receipts/2026/04/amazon-2026-04-12.pdf`), then records that path
+   (found in the mail registry by `account_id`). Files larger than
+   100 MB, and orphaned rows with a null `account_id`, are rejected.
+2. The agent writes the file into your **external** Obsidian vault —
+   not the primary management vault — using the naming convention
+   `receipts/YYYY/MM/<merchant>-<date>.<ext>` (for example,
+   `receipts/2026/04/amazon-2026-04-12.pdf`). It then records that path
    with `PATCH /api/receipts/:id` (body `{"obsidianPath": "..."}`),
    which also stamps `saved_at`.
 
@@ -96,11 +95,11 @@ To reclassify a receipt, the agent PATCHes `{"category": "travel"}`
 
 ## Where in the Dashboard
 
-There is no dedicated tab today. Receipts surface inline when you ask
-for them in chat (e.g. "what receipts haven't I saved yet?"). List and
-filter them with `GET /api/receipts` (`category`, `saved`, `limit`
-params) and pull totals from `GET /api/receipts/summary`. The full API
-is documented in
+There is no dedicated tab yet. Receipts show up inline when you ask for
+them in chat (for example, "what receipts haven't I saved yet?"). List
+and filter them with `GET /api/receipts` (the `category`, `saved`, and
+`limit` params) and pull totals from `GET /api/receipts/summary`. The
+full API is documented in
 `agent-assets/skills/gmail-lifestyle/references/receipts-api.md`
 (loaded by the `gmail-lifestyle` skill).
 

package/agent-assets/docs/features/lifestyle/travel-bookings.md

@@ -17,7 +17,6 @@ summary: |
 section: lifestyle
 tags:
   - lifestyle
-  - travel
   - mail
   - integrations
 status: stable
@@ -27,7 +26,7 @@ ask_examples:
   - Where are my travel bookings stored?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - flight
   - hotel
@@ -76,10 +75,10 @@ confirmation email never creates a duplicate row.
 
 ## How Bookings Get Created
 
-Bookings are extracted from email only — there is no manual "log a
-flight" command or DM shortcut. To start capturing travel, connect a
-mail account (see [Mail](features/integrations/mail)) and let the
-classifier do the rest. The flow is:
+Bookings come from email only — there is no manual "log a flight"
+command or DM shortcut. To start capturing travel, connect a mail
+account (see [Mail](../integrations/mail.md)) and let the classifier
+do the rest. The flow is:
 
 1. The mail poller fetches new messages.
 2. The classifier (`gmail_classify`, lite tier) tags travel
@@ -99,9 +98,10 @@ classifier do the rest. The flow is:
 
 ## API
 
-Read-only and status-update access (read endpoints are read-sensitive —
-they expose personal travel data; the PATCH endpoint follows the standard
-write-safety tier and requires approval):
+These endpoints give read and status-update access. The two read
+endpoints are read-sensitive, because they expose personal travel data.
+The `PATCH` endpoint follows the standard write-safety tier, so it
+requires approval before it runs.
 
 ```bash
 # All bookings (optionally filter by type/status/date range)

package/agent-assets/docs/features/memory-files/agent-journal.md

@@ -17,7 +17,6 @@ section: memory-files
 tags:
   - memory
   - journal
-  - reflection
   - routines
 status: stable
 ask_examples:
@@ -27,7 +26,7 @@ ask_examples:
   - Why did journal/agent.md stop growing?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - journal
   - retros
@@ -77,20 +76,22 @@ Each entry carries:
 - The reflection itself.
 
 The file lives at `~/.personal-agent/context/journal/agent.md`. The
-day-to-day morning and ad-hoc entries accumulate indefinitely; the
-daily retention rollup keeps only a rolling window of the structured
-retros (the most recent 12 `## Weekly` and 24 `## Monthly` sections),
-pruning older ones. Later routines read it back to look for patterns.
+day-to-day morning and ad-hoc entries accumulate indefinitely. A daily
+retention rollup then keeps only a rolling window of the structured
+retros — the most recent 12 `## Weekly` and 24 `## Monthly` sections —
+and prunes older ones. Later routines read the file back to look for
+patterns.
 
 ## Who writes it, and when
 
 Three routines append to the journal — none ever rewrites it:
 
 - **Morning routine** is the recurring daily writer — and here the
-  daemon itself does the writing, not an LLM stage. After the day's
+  daemon (the always-on local background service) does the writing
+  itself, rather than an AI-model (LLM) stage. Once the day's
   stages (Stage A `routine.morning_routine_today`, Stage B
-  `routine.morning_routine_journal`) settle, the daemon appends a
-  one-paragraph audit-trail entry assembled from the run's
+  `routine.morning_routine_journal`) finish, the daemon appends a
+  one-paragraph audit-trail entry built from the run's
   `agent_actions` rows — stage results, inbox stats, anomalies — plus
   a one-line footprint of the prior day's actions. This is the entry
   you'll see most often.
@@ -104,7 +105,8 @@ Three routines append to the journal — none ever rewrites it:
   rejected. It does not write the bulk of the diary.
 
 In-the-moment notes can also land here when the agent flags something
-worth recording during reactive work.
+worth recording during reactive work — its live back-and-forth with
+you, outside the scheduled routines.
 
 ### Example entry
 

package/agent-assets/docs/features/memory-files/agent-lessons.md

@@ -18,8 +18,6 @@ summary: |
 section: memory-files
 tags:
   - memory
-  - feedback
-  - learning
   - routines
 status: beta
 ask_examples:
@@ -30,7 +28,7 @@ ask_examples:
   - How do I tune the lesson caps?
 locale: en-US
 created: 2026-06-08
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - lessons
   - feedback
@@ -61,20 +59,21 @@ ui_anchors:
 
 The lesson stores are where the agent remembers how you want it to
 behave: a short, dated list of learned directives that grows from your
-corrections and the agent's own retros, and is fed back into the agent's
-work so it stops repeating the same mistakes.
+corrections and from the agent's own reviews of its work, and is fed back
+into the agent's work so it stops repeating the same mistakes.
 
 ## What they are
 
 There are two kinds of store:
 
 - **Global agent behavior** — `policies/agent-lessons.md`. Lessons that
-  apply to the agent as a whole. These are injected into your DM
-  conversations and into the routines that decide whether to notify you.
+  apply to the agent as a whole. They are fed into your DM (direct
+  message) chats with the agent and into the routines that decide whether
+  to notify you.
 - **Per-agent** — `policies/agents/<slug>/lessons.md`, one per Agent
-  Definition. These are injected **only** into that agent's own
-  executions, so a lesson learned for your "weekly-report" agent never
-  leaks into an unrelated one.
+  Definition. These are fed in **only** when that agent itself runs, so a
+  lesson learned for your "weekly-report" agent never leaks into an
+  unrelated one.
 
 Both live under `~/.personal-agent/context/policies/`, alongside your
 other rule files, and are plain Markdown you can read or hand-edit.
@@ -111,7 +110,7 @@ it for you. There are three ways signals enter:
 Those raw signals don't become lessons immediately. Each night the
 [evening review](../routines/evening-review.md) folds the day's
 unconsumed signals into the right store as dated lessons, then marks them
-consumed (it skips the step entirely when nothing pends). Once a month
+consumed (it skips the step entirely when nothing is waiting). Once a month
 the monthly review — off by default; opt in by enabling the
 monthly-review agent at `/agents/monthly-review` — runs a re-generalize
 pass that collapses several same-theme lessons into one higher-level
@@ -122,8 +121,8 @@ principle, keeping each store small.
 A new lesson is stored but is not necessarily *injected* right away. A
 lesson carries a `<!-- provisional -->` marker until it has enough
 corroborating evidence; provisional lessons sit in the file but are not
-fed into the agent's prompts. This avoids over-fitting to a single
-offhand comment.
+fed into the agent's prompts. This keeps the agent from over-reacting to a
+single offhand comment.
 
 How a lesson crosses from provisional to active:
 
@@ -135,6 +134,26 @@ How a lesson crosses from provisional to active:
   promotes on the first occurrence — it is taken at your word.
 - An **ignore on its own never promotes** a lesson, and is never read as
   disapproval.
+- A candidate that **contradicts an established lesson** (one whose
+  confidence is at or above `feedbackContradictionGuardCf`, default 0.6)
+  is held provisional until it accumulates 1.5x the usual evidence — a
+  single stray signal can't flip a well-supported lesson. Your explicit
+  corrections bypass this guard entirely.
+
+## Confidence (`cf`)
+
+Every lesson carries a numeric confidence `cf` between 0 and 1, stamped
+deterministically by the daemon (never trusted from the model's rewrite).
+It rises with corroboration and decays with time since the lesson was
+last reinforced. Inferred lessons whose decayed confidence falls below
+`feedbackLessonConfidenceFloor` (default 0.25) quietly stop being
+injected — but the two highest-authority classes are protected: a
+durable `constraint` is never filtered, and an explicit owner correction
+is tested on its undecayed confidence (obeying a directive produces no
+new signals, so decay alone can't silently un-bind it). A daily
+mechanical pass (the **Lesson Maintenance** agent at
+`/agents/lesson-maintenance`, 17:40) keeps the stamps fresh even on days
+with no new feedback.
 
 ## Bounded by design
 
@@ -142,19 +161,25 @@ The stores can't grow without limit. Each is capped in bytes and entry
 count — the global store at `feedbackLessonMaxBytesGlobal` bytes
 (default 8192) / 40 entries, the per-agent stores at
 `feedbackLessonMaxBytesPerAgent` (default 4096) / 20 entries. When a
-store is full, the lowest-signal lessons are dropped first. Lessons that
-go untouched for `feedbackLessonStaleDays` (default 60) are pruned — with
-one exception: a `kind=constraint` lesson is durable and is never
-stale-pruned or collapsed away. The underlying feedback signals
-themselves are retained for `feedbackSignalRetentionDays` (default 180).
+store is full, the lowest-signal lessons are dropped first. Expiration is
+graduated and reversible: a lesson untouched past
+`feedbackLessonStaleDays` (default 60) whose decayed confidence is below
+the floor **demotes** back to provisional; a provisional lesson that goes
+uncorroborated for twice that horizon is **archived** (removed from the
+file — its raw signals remain in the database); fresh corroboration
+**re-promotes** a demoted lesson. One exception: a `kind=constraint`
+lesson is durable and never expires or collapses away. The underlying
+feedback signals themselves are retained for
+`feedbackSignalRetentionDays` (default 180).
 
 ## Where in the dashboard
 
 **Settings → Lessons** (`/settings/lessons`, labelled "Lessons" with a
-**Preview** badge) is the read/tune surface. From there you can view and
-edit the lessons themselves and adjust every knob above:
+**Preview** badge) is where you read and tune all of this. From there you
+can view and edit the lessons themselves and adjust every knob above:
 `feedbackLearningEnabled` (the master kill-switch, on by default),
-`feedbackPromotionThreshold`, the byte caps, the stale-days horizon, and
+`feedbackPromotionThreshold`, the byte caps, the stale-days horizon, the
+confidence floor, the contradiction guard, the outcome-rollup toggle, and
 the signal retention window. Turning `feedbackLearningEnabled` off stops
 both capture and consolidation.
 

package/agent-assets/docs/features/memory-files/projects.md

@@ -16,8 +16,6 @@ summary: |
 section: memory-files
 tags:
   - memory
-  - projects
-  - core
 status: stable
 ask_examples:
   - Where do I find the per-project files?
@@ -25,7 +23,7 @@ ask_examples:
   - How does the agent write to a project file?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - projects
   - project file
@@ -67,11 +65,11 @@ only the minimum — `type: project`, `owner: shared`, an `updated`
 date, and an H1 title. By convention the agent also writes `slug`,
 `state`, `start`, `due`, `stakeholders`, `next_milestone`, and `tags`.
 
-`state` is what marks a project **active**: the Obsidian `_active.base`
-Bases view filters on it (`state != "archived"`), and the morning
-routine surfaces every project whose `state` is not `archived` — a
-file with no `state` (or any state other than `archived`) is treated
-as active and surfaced.
+The `state` field is what marks a project **active**. The Obsidian
+`_active.base` view filters on it (keeping rows where
+`state != "archived"`), and the morning routine surfaces every project
+whose `state` is not `archived`. A file with no `state` at all — or any
+state other than `archived` — counts as active and shows up.
 
 ```markdown
 ---
@@ -95,13 +93,14 @@ Ship the public beta before the conference.
 
 ## When It Runs / How It Is Triggered
 
-Read on demand. Written when the operator asks the agent to remember
-something project-specific, or when a DM expresses project intent
-(create, update status, mark done).
+Read on demand. Written when you ask the agent to remember something
+project-specific, or when a direct message (DM) signals project intent
+— create, update status, or mark done.
 
-The agent cannot edit context files on disk — a pre-write hook blocks
-`Edit`/`Write` anywhere inside the context vault. All project writes go
-through the context API:
+The agent cannot edit context files directly on disk: a pre-write hook
+blocks the `Edit` and `Write` tools anywhere inside the context vault
+(the folder that holds these Markdown memory files). Instead, every
+project write goes through the context API:
 
 - `GET /api/context/list/projects` — discover existing project files.
 - `PUT /api/context/plans/projects/<slug>` — create or fully replace.

package/agent-assets/docs/features/memory-files/roadmap.md

@@ -9,13 +9,13 @@ aliases:
   - preparation timeline
 category: features
 summary: |
-  roadmap.md captures long-running goals plus Preparation Timeline
-  rows that fire on specific days. The morning routine walks the
-  roadmap each day to surface items whose offsets fire.
+  roadmap.md holds long-running goals plus Preparation Timeline
+  rows dated for specific days. Each day the morning routine reads the
+  roadmap and surfaces any row whose date has arrived.
 section: memory-files
 tags:
   - memory
-  - core
+  - scheduler
 status: stable
 ask_examples:
   - What is the roadmap file?
@@ -24,7 +24,7 @@ ask_examples:
   - How do I add a roadmap entry?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - roadmap.md
   - roadmap
@@ -49,7 +49,7 @@ context_files:
 ## In One Sentence
 
 A multi-week plan: each goal carries dates and Preparation Timeline
-rows that the morning routine fires on the day they come due.
+rows, and the morning routine surfaces each row on the day it comes due.
 
 ## What It Does
 
@@ -87,16 +87,17 @@ hotel", and so on.
 
 ## When It Runs / How It Is Triggered
 
-Read by the morning routine each day, which walks the roadmap and
-surfaces any Preparation Timeline rows dated for that day (or overdue).
-The file is updated by the operator, or by the agent on request (for
-example via the roadmap skill or `aitne run-now roadmap_maintenance`).
+The morning routine reads the roadmap each day and surfaces any
+Preparation Timeline rows dated for that day — plus any earlier row it
+has not handled yet (overdue). You can update the file yourself, or ask
+the agent to (for example via the roadmap skill or
+`aitne run-now roadmap_maintenance`).
 
-The agent never edits the file directly. All writes go through the
+The agent never edits the file directly. Every write goes through the
 daemon's context endpoint — `PUT /api/context/plans/roadmap` (full
-replace) or `PATCH /api/context/plans/roadmap` (section op) — which is
-guarded by an exclusive roadmap write lock so two flows can't clobber
-each other.
+replace) or `PATCH /api/context/plans/roadmap` (section op). A write
+lock holds the roadmap exclusively during each write, so two flows can
+never overwrite each other.
 
 ## Where in the Dashboard
 
@@ -104,6 +105,6 @@ each other.
 
 ## Related
 
-- [Morning Routine](../../routines/morning-routine.md) — reads the roadmap each day.
+- [Morning Routine](../routines/morning-routine.md) — reads the roadmap each day.
 - [Projects](projects.md) — deeper, per-project context the roadmap links to.
 - [today.md](today.md) — the single-day plan the roadmap feeds into.

package/agent-assets/docs/features/memory-files/schedule.md

@@ -21,7 +21,6 @@ tags:
   - memory
   - journal
   - routines
-  - core
 status: stable
 ask_examples:
   - Where does the agent store the day's diary?
@@ -29,7 +28,7 @@ ask_examples:
   - How do I change which sections the daily journal includes?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-10
+updated: 2026-07-01
 keywords:
   - daily journal
   - diary
@@ -42,7 +41,7 @@ related:
   - features/memory-files/agent-journal
   - concepts/agent-day
 ui_anchors:
-  - /schedule
+  - /tasks
   - /agents/morning-routine?tab=rulebook
 process_keys:
   - routine.morning_routine_journal
@@ -55,8 +54,9 @@ context_files:
 ## In One Sentence
 
 `journal/daily/YYYY-MM-DD.md` is the morning routine's first-person
-diary of the **previous** agent-day — what the user did, who they met,
-what they talked about — composed by the daemon and kept as a
+diary of the **previous** agent-day (the agent's version of a day,
+which rolls over at 04:00 by default) — what the user did, who they
+met, what they talked about — composed by the daemon and kept as a
 read-only archive that the weekly and monthly reviews read back.
 
 > **Renamed from `schedule/`.** The old mechanical `schedule/YYYY-MM-DD.md`
@@ -93,11 +93,11 @@ typically includes:
 - `## Tasks` — what the user worked on.
 - `## Conversations` — who they talked to and about what.
 
-When the `browser_history` integration is active, a reading/research
-surface is woven in from the day's browser digest. Daemon-owned
-frontmatter (`date`, `weekday`, `calendar_events`, `messages_handled`,
-`projects`, `people`, `tags`, `content_hash`, `updated`) is filled in
-automatically. The exact sections and tone are governed by the
+When the `browser_history` integration is turned on, a reading and
+research section is added from the day's browser digest. The daemon
+fills in the frontmatter fields automatically (`date`, `weekday`,
+`calendar_events`, `messages_handled`, `projects`, `people`, `tags`,
+`content_hash`, `updated`). The exact sections and tone are set by the
 journal-format and journal-export policy files (see
 [Configuration](#configuration)).