Auto-tracking and attribution
Every time the front window, app or tab changes, andeye scores the candidate tasks and tracks the best one. Sources, strongest first:
- An explicit pin (always 100%).
- An OpenProject task URL in the browser tab (or a work-package id in the window title).
- A just-opened OP task priming the next surface you work on.
- A remembered surface from a past correction.
- Learned associations (what you’ve confirmed before) plus status/recency priors.
A brief flit to another window does not immediately re-file your time: a switch only becomes its own slice once you’ve held it past the Switch Buffer (and never below one displayed minute), so glancing at Slack mid-task does not fragment your timeline.
Turn on Calendar in Settings and a meeting that’s
live right now nudges that slot in the ranking - never enough to beat a pin,
a URL match or a learned rule, just enough to break a tie among your
ordinary tasks. The pick list marks the matching task with a small clock; if
you’re tracking something else during a meeting, the popover offers a
one-line “Calendar:
Context rules: see why, un-learn in one click
Section titled “Context rules: see why, un-learn in one click”In the popover, the certainty line grows a “why?” suffix whenever a signal is tracking (⌘E, or click it) - it expands the Evidence Card in place. In the Time window’s timeline, click a slice then a window in its detail strip to see the same card full-size.
The card shows, top to bottom:
- BECAUSE - the source that fired (pinned, a learned email rule, remembered, learned associations…), with the rule’s provenance when one fired (when it was learned, how many times it’s fired). A remembered window/site shows the exact remembered key it matched on, so an over-broad memory is visible - and forgettable - at a glance. In the timeline, a window’s slice already stands somewhere in your journal, and the journal records what decided it at the moment - so BECAUSE names the original decider outright (“you pinned it”, “a learned rule fired (✉ …)”, “you assigned it”). If the rules as they are NOW would file that window differently, today’s differing read appears beneath, marked “today’s rules would say” - it is never presented as the reason the slice is where it is - with a one-click ↪ refile as… button when today’s answer is confident. The engine also acts on its own: slices IT decided (never ones you assigned or pinned) refile automatically when a later correction or rule confidently contradicts them - batched into the same “recently cleared - undo” receipt as the retro pass, so being right costs you nothing; already-posted entries are flagged in Posting health instead of moved; weaker contradictions appear as one “look mis-filed” row in Review with refile-all and dismiss. If something LEARNED drove the decision, a ✕ forget (or ✕ suppress for a learned association, which can’t be deleted outright, only counter-taught) removes exactly that - undoable (⌘Z) - and shows what would fire instead BEFORE you click.
- sees: - the evidence andeye actually captured: app and site/title always, plus the correspondent, domain and subject when the surface is an open message in Gmail, Outlook Web, Proton Mail, Yahoo Mail or Fastmail. A field it didn’t capture shows as “not captured”, never hidden.
- Wrong? file as - search for the right task, then choose how durably to fix it: Once (today, this thread - today’s soft correction, no lasting rule), Remember (a revisable rule at the grain you pick - correspondent, domain, subject or the whole mail system), or Always 📌 (a pinned rule, 100% and standing law).
Picking a task from the popover’s own list on an email surface or any web page also offers a one-line “remember for…” footer underneath - the same Remember, without opening the card. The Review queue offers the same footer under its assign bar: queued rows keep the correspondents and subject captured while their time accrued, so assigning a batch of low-certainty windows to one task offers the identical Remember - at the correspondent, domain or subject grain when every row in the batch shares one email context, at the mail-system grain when the batch only shares the mail system, or at the whole-site grain when web rows share only their site. Either place, when that context has more than one correspondent, checking the correspondent row expands it into a checkbox per address, so you choose exactly who the rule should cover, not just the first one andeye saw.
The queue only asks about moments worth a decision: a visit appears once its slice is at least a minute long (tunable in Settings, “Review queue floor”). Briefer glances stay tracked and journalled as normal - they just never queue, however often they repeat - because a moment too brief to switch tracking is never worth naming.
Selecting works like the Finder: click a visit to select it, or click a row’s header - or the strip down its left edge while it’s open - to select its whole group. ⌘-click adds or removes a row without disturbing the rest; ⇧-click selects everything between the last row you clicked and this one, whole groups and single visits alike. A selection mixes freely: whole groups here, single visits there, across any number of rows. Clearing a backlog? Sort the queue from the control at the top - newest, oldest, longest or shortest - then click the top row and shift-click at the cutoff to select everything in between. One press of Clear, Unknown or a task then handles everything selected - so does ⌫ for Clear - and one ⌘Z brings it all back. Clear drops the selection from the queue without adding it to timesheets and without teaching andeye anything - the quick way past slices not worth naming; your timeline and journal keep the time untouched.
Every row is dated - Today, Yesterday or the calendar date - and every row expands. A row is one surface (an app, window or tab), stacking every separate visit to it; the chevron lists those visits, and each visit’s own chevron reveals everything held on it - exact start and end, duration, app, window title and address, any email correspondents and subject, how certain andeye currently is about it and where that certainty comes from, and what filled the time immediately before and after it (with the gap named when they weren’t back-to-back; a neighbour that is itself still awaiting review shows in italics as pending review with its surface, since nothing is decided about it yet). Expand all in the header (⌘E) opens every stack and every visit’s detail at once - the certainty and neighbour lines fill in a moment later as they’re worked out - and pressing it again collapses. Because any single visit can be selected on its own, one visit in a stack can go to a different task than its siblings: select just it and assign. It leaves its group immediately, and the buttons re-score over the visits that remain.
Prefer to walk the day instead of selecting? The arrow buttons at the top of the queue (⌘[ / ⌘], or ← / → while the list has focus) step through the visits in time order, in either direction - each visit opens as you land on it and gains an eye mark: viewed. Clicking a visit or opening its detail marks it too; merely scrolling past - or Expand all - never does, so a mark always means you actually looked. Dig in as deep as you like on the way; assigning or clearing something mid-walk simply handles it and the walk carries on. Confirm viewed then takes andeye’s current reading of every marked visit as your decision, in one click and one ⌘Z: those slices become your word - they post like any confirmed time, and no automatic pass will move them again. There is deliberately no confirm-the-whole-day: visits you haven’t viewed stay queued untouched, so reviewing part of the day and coming back later just works (viewed marks last until the app quits). A visit andeye can’t yet place at all stays queued even when viewed - there is nothing on show to confirm.
The assign bar’s task buttons are sorted by how likely each task is for the selected visits - every highlighted visit counts, whether it was picked on its own or as part of a group - most likely first, and a button that has a likelihood shows it as a percentage - hover to see how the number was built. Time tracked to the same task immediately before and after a visit raises that task’s likelihood: strongly when both sides match, less when only one does, fading out as the gap to the neighbour grows. Only decided, tracked time counts here - a pending review neighbour never changes a likelihood.
The same continuity idea runs live: while the clock is running on a task, a window that could plausibly belong to it is read as a continuation - the running task’s likelihood gets the one-sided nudge above, so an ambiguous moment mid-flow queues for review less often than the same window opened cold. Definite evidence (a pin, a task page, a learned rule) always beats the nudge, and a stopped clock carries none.
Can’t place a batch at all? The assign bar’s Unknown button sweeps it to the built-in Unknown task instead of clearing it or guessing - the time stays tracked with full detail, just off your review queue. It shows up hatched grey on the timeline and in the donut so it’s never mistaken for a real task, and you can reassign it from the timeline any time you do work out what it was. If a later rule makes andeye confident about it on its own, it reclaims itself back out of Unknown automatically.
Saving a rule shows a brief “who → task” notice with an Undo, and the first time a learned rule goes on to fire for real, you’re told once more, so a decision it makes on your behalf is never silent. Both notices sit in the popover, auto-dismiss on their own, and are never a system notification.
Every learned + pinned rule lives in Settings ▸ Email → task matching ▸ Context rules… - an Email segment and a Sites segment, each listed with its provenance. Click a row for its full detail; forget it there, or forget a whole task’s rules at once with its group’s Forget all button - either way, one undo (⌘Z) restores everything that click removed. Copy rules puts the current segment’s rules on the clipboard as plain text.
Site rules: whole sites, and the pages inside them
Section titled “Site rules: whole sites, and the pages inside them”On the web beyond email, andeye reads certain sites’ pages into named fields, so one correction can cover exactly the right slice of a site. Built-in recipes understand:
- GitHub - owner, repository, section (issues, pulls, actions…) and the open issue/PR title. “Everything in the acme-web repo → task X” is one Remember at the repository grain.
- Google Docs / Drive - document type, the document itself, and its title. A document rule keys on the document’s stable identity, so it survives a rename.
- Xero - the organisation, the app section (invoicing, bank, contacts…) and the page title. One Remember per organisation maps each set of books to its own task.
Every field is parsed from the page’s address and window title - the same things andeye already watches - so recipes add names and structure, never new collection. A field a page doesn’t show says “not captured” in the Evidence Card, and the card’s grain ladder lets you Remember at any field (Always 📌 pins it), exactly like the email ladder.
On sites without a recipe the ladder still offers the site itself: Remember on the site row teaches “this whole site → task” in one tap, revisable and forgettable like any learned rule; Always on the site row is the classic 100% pin.
The ledger’s Sites segment carries a Recipes strip - one checkbox per recipe. Turning a recipe off stops it reading anything; rules you taught under it stay listed (greyed, dormant) until you turn it back on or forget them. To see exactly what the recipes make of the page you’re on, use Settings ▸ Diagnostics ▸ What recipes see here.