Your console opens to the workspace home, /, and the first thing you see is status. If there's a banner at the top—a quiet notification that a connected repository is behind the current Ship bundle—pause there. This is Ship telling you that a new template, new routine, or new knowledge structure has been published and your repository hasn't pulled it in yet. Open the wizard, review what's changed, and merge the PR into the repo. This is setup work, not operational work, and it's gentle enough to handle in the first few minutes. If you've already done this in a previous morning, there's nothing here. Either way, move on.
Below the banner sits the workspace status card and three small panels: work in progress, recently shipped, and process and testing signals. You are not reading numbers. You are confirming that nothing is reporting a state you need to know about right now — a degraded integration, a routine that has been failing on repeat, a repo whose template has fallen far enough behind that something important is broken. This takes three seconds and gives you permission to trust what comes next.
Now drain the Inbox. This is the work that matters most in a morning, and it's not what you might expect. The Inbox is not a notification feed. It's not a log stream of events. It's a collection of decisions that belong to you—items that the system, or a human, or a routine, has flagged as needing your judgment. There are exactly five types of things in there: clarifications, improvements, approvals, failures, and exceptions.
Read the failures first. A failure is something that tried to happen and stopped. It's a workflow that ran but couldn't proceed, a validation that didn't pass, an integration that returned an error. Failures block other work. Read the approvals next—these are decisions you're already expecting, probably because someone asked you explicitly or because a work item is waiting for a gate that only you can open. Failures and approvals together form the blocking queue. Clear them, or mark them as deferred with a reason that the person who flagged them will understand.
Now read the clarifications. A clarification is a question baked into a work item. Someone built something, and it works, but they need to know: does this meet the spec? Should we ship this? Is this the behavior you meant? Answering one clarification often cascades—you clear the blocker for that work, and it surfaces the next item waiting behind it. Spend time here.
Improvements are the gentlest category. An improvement is a suggestion, a refinement, a "we could be better at this." You can defer improvements. You can push them to a later sprint, or to a backlog without a date. If you defer one, write a sentence about why: "This is good, but we're focusing on knowledge ingest this month." That sentence is not for Ship. It's for the next person who looks at that item and wonders if it was forgotten.
Exceptions are the strangest Inbox items. An exception is an edge case that the system couldn't categorize—something that doesn't quite fit in the normal flow. Read these carefully. An exception usually means that something unexpected happened, and someone has decided it's important enough to bring to your attention. Give it an owner. If the owner is not you, it becomes their Inbox item. If the owner is you, decide what to do right now: address it, schedule it, or defer it with your reason.
Once the Inbox is empty—or as empty as it's going to get this morning—glance at shipped work. The workspace home shows recently shipped items. Did anything merge in the last 24 hours? If yes, spot-check one or two of them. Does each one have a tracker link? Can you trace from the merged PR back to the work item it closed? Is the metadata clean, or is there a stray note that should have been cleared? You're not reading every commit message. You're checking that the trail is solid—that someone could pick up this feature in three months and understand why it exists.
Now look at what's in progress. Every active work item should have three pieces of context: a connection to the tracker that explains what it is, a connection to the repository and branch that shows where the code lives, and a named owner who is moving it forward. Scan the list. If something has been "in progress" for longer than it should—longer than the work item itself predicts, longer than you'd be comfortable with if someone asked you about it—that's a flag. That item is probably waiting for a decision, or stuck on something that needs help. Bring it forward to your own mental queue. Depending on the situation, it might become an Inbox item for the owner, or it might be something you handle now.
Take a minute to consider whether the knowledge in Ship has drifted. Did you answer the same question twice this week? Did someone ask about something that should have been documented but wasn't? If you answered a clarification from a work item and that answer is general enough that it will help someone else, it belongs in the knowledge section. Navigate there, find the bucket where it fits, and write a paragraph. The fix for a recurring question is not training people to answer it again. It's an article in the right place, written in plain language, that lets the next person find it.
Finally, if something felt off this morning—if you sensed a gap, or a piece of work that seemed to disappear, or a routine that should have run but didn't—open the audit log. The log records privileged actions: who changed what, when, on whose behalf. It's not exciting reading. You probably don't open it every morning. But knowing it exists, and that you can open it when your instinct tells you something is worth investigating, is the architecture working as intended.
Close on this: an Inbox with no critical decisions today, routines that ran and reported nothing eligible—which is valid; the work wasn't there—and knowledge that didn't drift. That is a healthy morning. That is the quiet workspace that tells you the system is thinking straight. A system that quietly does nothing is sometimes lying, as the prologue reminds us. Cultivate the habit of checking absence, not just failure. No news, when you've looked carefully, is the best news.
If you haven't set Ship up yet, Part II walks the wizard end to end.