Planning a day and a week

Planning in Lithic is one field on a row: the period it is planned for. No separate task object, and a deadline is a second field rather than the same one — the row you wrote is the row you schedule, and there is only ever one of it.

Periods, not dates

A row is planned into a period, and the shape of what you write decides how precise you were being:

That is the whole scheduling model. "Sometime in August" is a real answer, not a missing date — and it is the answer most things deserve when you first write them down.

There is no quarter any more. Four horizons proved to be the ones people use, and every extra one is another order that has to agree with the others. A row planned for 2026-Q3 in an older document is not lost: it is read, drawn, ordered and counted as 2026, and the next change to it stores the year.

Only a day carries a clock. A start time and a duration are meaningful under a day and nowhere else; planning a row for a week strips them, because "Tuesday 09:30" and "some time next week" cannot both be true of one row.

Timeboxes and untimed rows

Under a day, a row can be one of two things:

• A timebox — it has a start time and a duration, and it sits in the hour grid. The grid snaps to 15 minutes, the shortest box is 15 minutes, and a row dropped onto the grid starts out 30 minutes long.
• Untimed — planned for the day, with no time. These sit in their own lane above the grid, in an order you can drag.

The untimed lane is the point of the day view, not a leftover. Most of a day is things that have to happen today and do not have to happen at 11:00.

The visible hours run 06:00 to 22:00 by default and are a setting.

The grid grows past them when something falls outside. A row at 05:00, or a mirrored meeting at 23:15, opens the grid down to 05:00 or up to 24:00 rather than being drawn at the edge at the wrong time. It grows for the whole view, not for one column, so the hour lines stay at one height across a week — one late meeting on Friday makes the whole week taller, which is the price of being able to compare Tuesday with Thursday by eye.

Things at the same time sit side by side. A meeting and a row you planned over it split the width between them, as does one row over another; nothing is hidden behind anything. In a week column that width is small, so a busy hour becomes a set of narrow blocks — the day view is where four overlapping things are actually readable, and every block keeps its full title in its tooltip.

Priorities are separate

A priority (Ctrl/Cmd + 1 / 2 / 3) says how much a row matters. A period says when you intend to do it. They do not imply each other, and the planner never reorders by priority on its own — a plan you did not make is not a plan.

Panes

A Lithic window is a row of panes, and every pane is a view of the same document, never a copy. Change a row in one, and the others already agree.

Three kinds:

• A document pane, which can be ordered five ways: the tree — the outline as you wrote it — periods (below), unplanned (that grouping with only its first group), projects (below) and tags (see Documents).
• A planner pane, showing a day, a week or a month.
• An agenda pane, showing the same day, week or month as a LIST (below).

Each pane has its own header, and everything about that pane is in it: its name, its views as a row of buttons, and a ⋯ holding "move left", "move right" and "close". The only thing left in the window's top bar is the + that adds one — adding a pane is the one act that belongs to the window rather than to any pane.

A lone pane keeps its header only while it has something to offer: a document pane does (it can switch to the periods view), and it shows no grip, because one pane is not something to reorder.

Panes can be reordered and resized, and the layout is remembered per document — for you, on every device. Open the same document in a second window and it shows the arrangement you left, picked up whenever a window is looked at again. A colleague reading the same document keeps their own: a pane closing under somebody's cursor because you closed yours would not be synchronisation.

Ctrl/Cmd + P shows or hides the planner.

The day view

Top to bottom: a stack of the periods this day sits inside — year, then month, then week — then the day itself, and under it the hour grid.

The day is drawn exactly as the agenda draws it: the same heading (the date, "Today" beside it, a count of what is on it, a caret that folds it) and, under the heading, the rows that have no time — all-day meetings and the tasks that are simply "some time today" — as plain rows, the way they look in the agenda. The grid below holds only what has a clock. The all-day block never scrolls away with the hours; it sits above them.

The stack is the useful part. Dragging a row down the stack makes it more specific: from "this year" to "August" to "next week" to "Tuesday" to "Tuesday at 09:30". Dragging it up makes it vaguer again. The planner reads downwards, so the gesture matches the sentence.

The week view

The same period lanes, then one column per day: each column has its day heading and its all-day rows above the shared hour grid. Five or seven columns, starting Monday or Sunday — both are settings. The carets fold every day's all-day rows together — a week's all-day list is one thing to fold. In a narrow column the heading keeps the date and lets the rest go.

The month view

A grid of whole weeks. Every cell is a drop target, so a month is where you place things you know the week of but not the day.

The agenda view

The document itself, grouped by time. The agenda draws the same rows the tree draws — you type straight into them, ~ and ! work, the row menu is the row menu, and a row brings whatever is indented under it. It is the periods view with two things a horizon list has no use for: the appointments, in their place in the day, and the context bands.

The same day, week or month as the planner, without the clock: a stack of sections you read downwards. First the periods the view sits inside — year, month, week — then one section per day.

A day has two halves. At the top what has no time: all-day meetings and the tasks that are simply "some time today". Below it the chronology — meetings with a time, your timeboxes, and the tasks hanging between those meetings.

A task without a time is not late in the day, it is outside the clock — which is why it sits at the top rather than under the last meeting.

An empty day is one line, so a month is a list you can scan.

Opening a document folds the days that are over. Only days, and only days that hold something: the overdue area stays open — it is what did not get done — and so does a week or a month that has ended, because rows planned for "this week" live there and no day section draws them. Unfolding a past day sticks while the document is open; the next time you open it, it is folded again.

A week's heading names the days it covers — Week 34 · 17–23 Aug — because an ISO week number alone is a label almost nobody can date by eye.

Every entry shows its own properties beside the title: the priority mark, the duration and the tags, drawn the way the document draws them. Everything except the scheduling, which the entry's position already says — a chip reading "Tue 14:00" inside Tuesday's 14:00 slot would be the same fact twice.

Every heading carries two numbers: appointments still ahead, and open tasks. They are counted differently on purpose, because they are different obligations:

• An appointment is a mirrored meeting with a time on it. All-day entries — a public holiday, somebody's leave — are not counted; they are a fact about the day rather than an item on it, and the strip above the clock already names them. A day that is over counts none at all, and neither does a meeting you have ticked off.
• A task is a row of yours that is not ticked, whether or not it has a time. Past days keep theirs: unfinished work stays unfinished.

Overdue work sits at the top. Above the ladder, whenever there is any: one section holding every unfinished row whose plan has passed — oldest first, no horizon, so a task planned for last month is as visible as one from yesterday. It is not a period, so nothing can be planned into it: no +, no drop target, and Alt + ↑/↓ walks out of it rather than into it. Give a row a new date, tick it off or archive it and it leaves. Empty, the section is not drawn at all.

A horizontal rule never appears there. It keeps the day it was put in — that is what places it between the blocks it separates — but it is a structure and not a task: it is never overdue, it is not part of a day's "3 tasks", and "tick everything off" does not reach it. A rule cannot be ticked, so a list of unfinished work would be one it could never leave.

A whole day at once. Two more controls appear in a day's heading beside the +, each only when it has something to do:

• the tick — after confirming, every open task of that day is done and every meeting on it is ticked. The confirmation names both numbers ("7 tasks and 3 meetings"). Ctrl/Cmd + Z takes the tasks back in one press; the meeting ticks belong to your account and stay. A task with a rhythm among them does what a single tick does — it moves on and leaves its record (see Repeating tasks).
• the archive symbol — archives everything already finished on that day, subtrees included. See the archive.

Three things it does that the planner cannot:

• It is the document. Rows, subtrees, typing — see above.
• Order inside any period. Drop a row between two others and it stays there — in a week and a month as much as in a day. The planner's period lanes now honour that order too, since both panes read the same plan.
• Contexts (below), as bands inside a section.

Drop a row on a section's heading to plan it for that period, uncategorised; drop it into a band to file it. This is the view for "what am I doing today", where the planner answers "when".

The keyboard is the document's. Everything you know from the tree works here, because these are the tree's rows: the arrows move the caret, Enter starts a new line, Tab indents, Alt + ↑/↓ moves a row among its siblings, and the row chords do what they always do.

A line you start inside a day belongs to that day. Press Enter at the end of a row planned for Wednesday and the new line is planned for Wednesday too — it stays where you are typing instead of jumping to the unplanned pile. Only the period is inherited, never a start time: a line under a 14:00 timebox is a line on that day, not a second thing at 14:00.

Alt + ↓ at the end of a section moves the row to the next one. That is the one thing the tree cannot express, so it is the one thing the agenda adds: inside a section Alt + ↑/↓ reorders as it does anywhere, and at the edge it replans. A row that is indented under another stays put — carrying it to the next day would tear it out of the row it belongs to.

Every entry carries the document's own row menu, with the same entries: the planning horizons, Terminieren … and Dauer …, priority, heading, done, archive, copy, duplicate and delete. Only zooming and "move to another document" are missing, because both are gestures of the tree rather than of the row. While editing an entry, ~, ! and # open the duration, date and tag pickers exactly as they do in the document.

The period view

A document pane can drop the tree and group the same document by planning horizon instead: everything planned for this year, this month, this week, this day — and a group called Unplanned that is always shown.

Each row appears exactly once, under the finest horizon anybody gave it. Drop a row on a group heading to replan it; drop it on Unplanned to take it out of the plan.

This is the view for the question "what have I actually committed to", which the tree cannot answer because the tree is sorted by subject.

Contexts

A day can be divided into named bands — Work and Private, Weekend and Weekdays, whatever you plan by. Open them from ⋯ → Contexts … — the one beside the document's title, or the one on its row in the sidebar, which are the same menu. They belong to that document and appear in every pane of it.

A context is not a time. A row filed under Work still has whatever period you gave it, or none — the point is that the tasks of a day stop lying in one heap. Drag a row into a band to file it, onto the section's heading to take it out.

Bands appear in the agenda's sections and in the planner's untimed lane. In a narrow week column the names are hidden and the grouping remains. A row with a TIME is never in a band: a time is the stronger claim, and a day's clock reads in one order.

With no contexts defined, nothing changes anywhere.

Tasks inside a meeting

Drop a row onto a meeting in the agenda and it becomes a task inside that meeting: indented under it, and it moves with it. If the meeting is moved to another day at the provider, the task follows on the next sync.

What is stored on your row is only which event it is — never the meeting's title, place or link. That matters if you share the document: a calendar belongs to the person who connected it, and somebody else opening the document sees a task pinned to a meeting they cannot see, with nothing about it revealed.

In the document that row shows a pin beside its schedule chip. Hover it for the meeting's name; press it for the same details the calendar shows, including the way back to it at the provider. With no calendar connected — or for a colleague who cannot see that one — the pin stays a plain mark, because there is nothing it could honestly say.

It takes the meeting's time, start and length both, and keeps them when the meeting moves — so the chip in your document reads Tue 14:00 · 60m and not just Tue. It is still drawn once, inside the meeting, and never as a second block over it. An all-day meeting has no time to give, so a task inside one is an untimed task of that day.

Drag it out — onto the day, into a band, onto another day — and it is an ordinary row again, on the day you dropped it. Anything you say about its time by hand takes it out too: choosing a period from its menu, setting a date with !, or the × that removes it from the plan. That is not the gesture doing two things — a pinned row's day belongs to its meeting, so a date you typed would be quietly overwritten on the next sync, which is what used to happen.

Tasks inside one meeting can be reordered among themselves: drop one above or below another, as anywhere else in the agenda.

The planner shows a count on the meeting rather than the list, because a 15-minute block has no room for one.

One limit worth knowing: a task inside a meeting never becomes an entry of its own on a calendar. It borrows the meeting's hour instead of claiming one, and only a task carrying a day and a start time of its own is ever published — see Calendars from elsewhere.

A deadline: when it has to be finished

When you mean to do something and when it has to be done are two different statements, so Lithic keeps them apart: the plan says which day you take the time, the deadline says by when it has to be finished at the latest.

Set it from the row menu — the Deadline column of its planning table, with the same answers the plan has (today, tomorrow, this or next week, this or next month, or pick … for a day of your own) — or from the chip once there is one, or by typing !! in the row. The row shows both beside each other — "Mon 17 Aug" for the plan, "by Fri 21 Aug" for the deadline. Once the deadline has passed and the row is not ticked, the chip takes on colour.

The two move independently: push a task to another day and the deadline stays where it was. (A rhythm is the one exception — when a repeating task moves to its next occurrence, the deadline moves with it by the same number of days. See below.) That is the whole point of keeping them apart — otherwise every reschedule would quietly move the delivery date with it.

A deadline enforces nothing. Nothing is blocked, nothing is replanned for you, nothing nags. It is visible on the row, early enough to do something about it; the rest is your decision.

The order inside a collection

A day's untimed list, a week, a month, a year, and every group in the periods view are collections: lists with no clock to put them in order. Lithic sorts them for you, and the pane's header says so — the ↓↑ button beside the fold and the archive switch.

The default is: what is done, then what is urgent, then what is short.

1. Done at the top, so the section reads as a log of the day: finished above, left to do below.
2. Priority, high before low, and a row with none after all three.
3. Length, short before long. Among equally urgent work the short thing is what fits the gap you are looking at. A row that says nothing about its length comes after the ones that do — an unknown length is not a short one.

Press the button and you get your own order back. Manual draws the rows the way you arranged them, which is what dragging has always written.

Sorting changes nothing in the document. It is a property of the view, like folding and like the archive switch: your arrangement stays underneath untouched, a colleague looking at the same document sees their own choice, and two panes side by side may differ. Nothing is re-written and nothing is lost.

Dragging a row into a sorted list switches that pane to manual, and then moves the row. It has to: while a sort draws the order, a drag would write an arrangement the list does not read, and the row would spring back. The same goes for Alt + ↑/↓.

Two places are never sorted: the clock half of a day, where the time is the order, and the rows under a row, which keep the document's own order — a checklist that re-arranges itself under its heading is one nobody can read twice.

Repeating tasks

A task that comes back every week does not need writing down every week. Give the row a rhythm and Lithic brings it back for you.

Type it. !every monday at 8:00 in the row says the whole thing at once — the rhythm, the day it starts on, and the hour. The same ! that plans a row plans a repeating one; every day, every 3 days, every 2 weeks, every month and every weekday work the same way, in German too (jeden Montag um 8:00, alle 3 tage).

Or set it in the row menu, in the Repeat row: D, W, M, Y for daily, weekly, monthly and yearly, and – to stop. The row then shows a quiet chip beside its plan — ↻ Weekly — so that a task which reappears is one you can see will reappear. Pressing the chip opens the menu again.

A rhythm needs a day to count from, so setting one plans the row for today if it is not already on a day. A rule on a row planned for a whole week has nothing to count with, and would do nothing at all.

What ticking one does

Four things, in one step — one press of ⌘Z takes all of it back:

1. the row moves on to its next occurrence;
2. an already-ticked copy goes into the archive, as the record that it was done, on the day it was done;
3. the ticks underneath it are reset, so a "weekly clean-up" with three items under it starts empty again;
4. a deadline moves with it, by the same number of days — due two days after the plan stays due two days after the plan. A timebox keeps its time and its length on the new day.

The row keeps its identity: notes, files and links to it stay on it. What lands in the archive is the record, not the task.

Late is not four times late

The rhythm counts from the plan, so a weekly task keeps its weekday however late it is ticked. And it comes back once: a task planned for 24 August and ticked on 21 September lands on the 21st — not four times over, once for every Monday nobody ticked. That is what keeps the overdue section usable.

Where the plan is not the anchor — "every three days after I actually do it" — write [repeatFrom:: done] on the row's Markdown line and the rhythm counts from the tick instead.

Rhythms the menu does not offer

The menu has four; the document's Markdown line has the rest. [repeat:: 3d], [repeat:: weekly:mo,th], [repeat:: 2w:mo], [repeat:: monthly:3], [repeat:: monthly:last], [repeat:: monthly:2fr] (the second Friday), [repeat:: yearly:12-24]. Such a rule shows itself on the chip exactly as it is written, and leaves the menu's four unselected — none of them is it, and checking the nearest one would overwrite it on the next press.

Tasks between two meetings

Not everything that sits between two meetings has a time. "After lunch, before the 19:00 meeting" is a statement about order, not about a minute — and that is exactly how it is stored.

Push a task between two meetings and it hangs in the free block behind the upper one: visible in its place, but with no start time and no duration. A day has a block behind every meeting, including the last one, where the evening is. Several tasks in one block are ordered freely with Alt + ↑/↓; a new one joins at the end.

The gap before the first appointment is a block as well. It is the only one that names nothing — it ends at whatever the day fixes first, a meeting or one of your timeboxes — and it is drawn at the top of the day's chronology, right under the hairline. So "before the first appointment" is a place you can drop into, walk into and type into, and it stays what it is when that first appointment is moved, re-timed or cancelled. On a day with nothing fixed left, it is simply the bottom of the day's own list.

A block is a place inside a day, not a statement about which day the work is on. So when the provider moves the meeting to another day, the task stays on its day and falls back into its list — unlike a task inside a meeting, which travels with it.

Through the day with the keyboard

Alt + ↑/↓ moves a row through its day — along the meetings, block by block. No step computes a time, and every one is undone by the same key in the other direction. Downwards out of the day's list the first stop is the block before the first appointment, and only the next press crosses it; upwards the same places come back in the same order.

Three things hold for a row that HAS a time. Crossing an appointment moves it into that appointment's free block and gives its time up — a block is a window, not a minute. Overtaking one of your own timeboxes trades the two times instead. And passing a row with NO time exchanges the two places: the other row moves into the block on the far side and yours keeps its minute. It could not work otherwise — a row with a time is drawn where its minute puts it, and what waits under a timebox waits there because that is where the timebox is. On screen it is exactly what it looks like: one press, the two lines change places, and the press back puts them as they were. At the edge of the day it goes on to the neighbouring day, then to the week, the month and the year — and at the top it stops. Nothing about the document changes: this is only about scheduling.

Planning without dragging

Every row's menu opens with a small table: a row per grain — Day (today, tomorrow), Week (this, next), Month (this, next) — and Pick … for any other day; – takes the row off the plan once it has one. The Deadline sits beside it as a second column with the same answers, so "when I mean to do it" and "when it has to be done" are set from the same place. Under the table: Duration, as the lengths ~ offers (minutes in one row, hours in the next), and Repeat. That covers most of what dragging is for, and it works when the planner pane is closed.

The menu is the same in every pane — the document, the agenda, the planner — down to the deadline column. What it does not offer in one pane it does not offer because the pane cannot do it (zooming into a subtree from a calendar column, say), never because it is a different menu.

A planned row shows a small chip in the document — Tue 11:30 · 45m. Pressing the date opens the date list, pressing the duration opens the duration list, and the date list's last entry, Remove the date, takes the row out of the plan again. A chip with a pin beside it belongs to a meeting (above): its time is the meeting's, not one you chose.

On a phone

The planner offers Day and Month. It does not offer Week: seven columns in a 390 px screen measure 49 px each, which holds a truncated weekday and nothing else — and a week on a phone is a list, which is exactly what the agenda's own week view is.

The all-day block above the clock draws its rows the way the agenda does, and the way the period lanes above it do: nothing boxed, the ⋯ at the right end of the line. With a mouse, hovering a row also brings out a tick and an unschedule beside it. On a touch screen it does not — there is no hover, so those two would be permanently drawn and an all-day entry would be the one row in the product with three controls on it. Both are entries of the ⋯ menu, which is where a finger reaches everything else about a row.

In the week and month grids, where a column is about 90 px, the controls move into the corner of the entry instead — measured, beside the title they left it no readable width at all.

Everything else about a day works the way it does on a laptop, with the gestures a finger has instead of the ones a keyboard has: swipe a planned row right to archive it and left to delete it, and the ⋯ opens the entry's menu as a sheet from the bottom. Moving a row onto a day by dragging it is a mouse gesture; on a phone the row's own menu plans it, which is what the planning table is for.

Settings

The gear sits at the foot of the sidebar, and it is there whether the sidebar is open or collapsed — it used to be in the planner pane's header, where closing that pane took the settings with it.

What is in there:

• Calendar — the visible hours of the grid, five or seven day columns, whether a week starts on Monday or Sunday, how a date is written, and whether declined meetings are drawn.
• Connected accounts — see below — and your personal access tokens and the workspace id, which is what you need if you came here for the API.
• Appearance, symbols and account, including the version this instance is running.

Calendars from elsewhere

Connect an account under Settings → Connected accounts and its calendars appear in the planner beside your own rows, drawn in the colour the provider gives them.

Four kinds of account can be connected: Google and Microsoft 365 by being sent to the provider to approve it, and an ICS/webcal subscription or a CalDAV server (iCloud among them) by supplying the address yourself. Google and Microsoft have to be configured by whoever runs this instance; a subscription URL needs nothing.

What arrives is a mirror, and each calendar is read-only until you allow writing for it — then changes you make here are sent to that calendar. The box is beside the calendar's name under Settings → Connected accounts; nothing is allowed until you tick it, and while it is unticked nothing you do here changes anything on that calendar.

• What you see is still a mirror. It is rebuilt from what the provider says and from nothing else — so a change you make from here reaches the calendar, and comes back into the mirror at the next sync like anybody else's change.
• Mirrored events are never dragged, and you cannot type into one: a meeting is not a row of yours and never becomes one. Your own rows can be dragged, and the two are drawn differently so the difference is visible before you try.
• A meeting can be ticked off — Ctrl/Cmd + Enter on it, or its tick in the row — and that tick is yours: it says "I have dealt with this", it is never sent to the provider, and a colleague looking at the same calendar does not see it. It also leaves the day's appointment count, exactly as a done task leaves the task count.
• Disconnecting an account deletes the mirror with it.

Allowing writing is a decision per calendar, not per account, and a calendar has to be mirrored before it can be allowed — Lithic only writes to calendars it mirrors. What the box buys depends on the kind of account:

An account can also be connected without the permission to change events — Google's consent screen lets you untick that box and finish anyway. The switch says so when that has happened, and only disconnecting the account and connecting it again fixes it.

Changing a meeting is one control on the meeting itself: the corner of its box in the planner, the clock on its line in the agenda, or Shift + Enter. It opens a small form — the title, and a day and a time at each end, because a meeting is allowed to end on another day — and the same form takes the meeting off the calendar, which removes it for everybody invited to it and cannot be undone from here. Two entries have no such form: an all-day entry, which has no hour to move, and one occurrence of a repeating series, because "this one or the series?" is a question this app does not answer. Where there is no form there is no control either, so you see it before you try.

Publishing your own timeboxes is the other direction, and it is set per document: ⋯ → Publish to calendar … picks one calendar and one time zone for this document, and for you alone — a colleague with the same document publishes to their own calendar, or to none. Only a task with a day and a start time becomes an event; a task planned for a day, a deadline, an estimate and a task inside a meeting all stay in Lithic. What is sent is the title and the span and nothing else — no notes, no location, no guests, no link back. A published row wears a chip saying where it has got to, and Stop publishing takes those events back off the calendar and counts how many. Move one of them at the provider and the timebox moves with it in the document, unless the document has something newer to say; delete one there and the task keeps its day and loses its clock.

Clicking a mirrored meeting shows what is known about it — title, time, place — and offers to open it at the provider as a second step. It used to be the link itself, so a stray click left the app. From the keyboard the same details are Alt + Enter.

Alt + ↑/↓ on a meeting moves the meeting past the untimed rows around it. Nothing about the meeting changes — it is a mirror, and its place in the day is its time; what moves is the boundary between "before this meeting" and "after" it, so the row it passes changes sides. It stops at the first thing with a clock, a timed task or another meeting, because there the two times would collide.

Enter on a meeting opens a line under it. The row lands in the gap that follows the meeting and stays with it — move the meeting and the line goes along (see Tasks between two meetings). That is what Enter means everywhere else in Lithic, and a meeting is the one line you cannot write in; preparing something for the appointment you are looking at is what people do there instead.

Not every entry is a meeting. A calendar carries things that are not appointments, and they are drawn as what they are:

Only Google says which of these an entry is. Microsoft 365 and a subscription do not, so from those every entry is an ordinary meeting — nothing disappears because a provider is quiet.

What is mirrored: the title, the time, the location and a link back — and nothing else. No attendees, no descriptions, no meeting links. That is a deliberate limit rather than an unfinished one; see ADR-0032.

The window is fixed: from 30 days back to 180 days ahead. Anything outside it is not mirrored, and the planner will not show it.

How current it is: a calendar is re-read at most every 15 minutes, so a change made at the provider takes up to that long to appear. Newly added calendars are noticed within 6 hours. If you cannot wait, press the refresh button in the document's header (the circling arrows beside the people who are here — it is only there once a calendar is connected): every connected calendar is read again at once, and the panes redraw as the answers arrive. Pressing it twice within a minute is refused with the time to wait, because two looks in a minute ask the provider twice for the same thing. The same thing per account is Sync now in the connected-accounts list, which also says when each calendar was last read.

The calendar list under each account is folded to start with, and its heading says how many of them are mirrored — an account with thirty subscribed feeds would otherwise push the account list off the screen.

Which calendars: when an account is first connected, only its primary calendar is mirrored — the rest are listed unticked, so thirty subscribed holiday feeds do not arrive uninvited. Tick the ones you want. Unticking one removes its mirrored events.

A connected account belongs to you, not to the workspace: colleagues in the same workspace cannot see it or its events.

Projects

A project is a row like any other, and it says so about itself: the row menu offers "Make this a project" (under More …), and from then on the Projects view of the document pane draws it as a card. Its tasks are its children — there is no project object, in the same way there is no task object.

That is the whole model, and it is what makes the rest work without any new rules:

• A project's heading shows how far along it is — 3/7, counting every line under it, rules excepted, nested ones and sub-projects included.
• Its tasks are ordinary rows. Plan one into next week and it appears in the agenda beside the block; tick it off and the count moves. Which project a task is part of and when it is being done are two independent answers, which is why the task can be in both places at once.
• A project inside a project is a block inside a block, one indent in, with its own tasks in it — the same stack the agenda builds out of year, month, week and day. Every row appears in exactly one block: the one for the nearest project above it.
• The heading is the project's own line, so everything you do to a row you do to it here: type in it to rename it, its ⋯ is the row's menu, drop a task on it to file it in, and the arrow keys walk through it. The indents are the document's — a project's tasks sit one step in from its heading.
• Adding a task: press Enter on the heading, or use the + on it. Either way the task goes INSIDE the project — on the heading, Enter never makes a neighbour. The + adds at the bottom of the list; Enter puts the line directly under the heading.
• A new project: the + under the list, at any time.
• Renaming is in the heading's ⋯ menu. A click on the title folds the block, as it does in the agenda — a project is not something to rename by accident. From the keyboard, Enter or Space on the heading opens it.
• Zooming in and out is the same control on the heading: ⤢ opens the project, and on the project you are zoomed to it becomes ⤡ and takes you back. ⌘⌥. and ⌘⌥, do the same from the keyboard.
• Ticking a project ticks everything under it, and archiving it archives the whole block — a project is a row, so both are the gestures every row has.

The inbox

The last block is No project: everything the document holds that is in no project. It is where a task written anywhere else lands until it belongs somewhere, and because it sits in the same pane as the projects, filing one is a drag of a few centimetres. Its own + writes a task with no project.

Under a zoom into a project there is no such block — everything there is already part of that project.

• Folding a block folds the row. It is the same fold as in the document tree, because it is the same row — so it puts away the tasks and the sub-projects together.
• Zooming shows one project. The ⤢ on a heading (or "Zoom in" from any row's menu) leaves just that project on screen — its heading and what is in it — and the breadcrumb at the top takes you back out. Otherwise this view works like Tree.

Filing a task into a project

Three ways in, and they all do the same thing — the row MOVES into the project, because a project is where a task lives:

• type + in a row and pick the project (start typing to narrow, or make a new one on the spot);
• press ⌘⇧P / Ctrl+Shift+P, which opens the same picker without typing — and files the whole selection when a run of rows is selected;
• drag a row onto a project's heading.

The picker's last entry is No project, which takes the row back out to the top level. And a filing says so in a short message naming the project, because the row leaves the list you were looking at.

Seeing a project from somewhere else

A project's row carries its glyph — or a mark, if you have given it none — in every view, so a project looks like one in the document tree and not only in the Projects view.

A task inside a project carries a small +Name beside its other facts, in the views that show it away from its tree: the agenda, Periods and Unplanned. It is on the row that was planned; rows nested under that one ride it, and their project is the heading above them. In the document tree and in the Projects view there is no such label, because there the project is already the row above.

A project can name work kept elsewhere

A project can be linked to cards kept in another product: the card appears beside the project's name on its heading, and the link opens it.

What travels is only the link. The name you see is fetched when it is drawn, so a card you have no access to — or whose product is not active on this workspace — shows a link without words. Nothing is broken about that; a colleague may well see the name.

Writing such a link is not a button yet. Each side writes the reference into its own document, and the one this side writes is the [cards:: …] attribute of the Markdown surface — so it arrives by import, by paste, or through the API. A project made from the other product's side names itself over there straight away; naming it back from here is the half that still has to be typed.

What planning cannot do yet

• No answering an invitation. On a calendar you allowed writing to, a meeting can be moved, renamed or deleted, and a timebox of yours can be published to it — but accepting or declining is not among the things Lithic sends.
• Nothing repeating can be changed from here. An occurrence of a series is refused whether you move it or delete it: "this one or the series?" is a question with consequences at twenty events, and Lithic does not answer it. Change it in the calendar itself.
• An all-day entry cannot be moved either. It has no hour to move, and giving one an hour is a different act from moving it.
• A subscription and a CalDAV server keep limits of their own. An ICS/webcal feed can never be written to at all. iCloud and other CalDAV servers take what you publish, but a meeting made elsewhere cannot be changed there.
• No Google Tasks, and no plan to add it.
• A row planned for a WEEK is invisible in a month view, in the agenda and in the planner alike: a month holds four or five weeks and "the week containing this month" is not one of them. The week view is one step in.
• Selection follows the tree, not the group. In the period view a Shift-click can span two groups, because selection is defined on the document's order rather than the view's.
• A context is per document. Two documents that want the same Work and Private need them defined twice — and the same is true of tags.
• The appointment count follows what is drawn. Switch declined meetings on and the number in the day's heading goes up: it counts what is on the screen, not what you owe.