> ## Documentation Index > Fetch the complete documentation index at: https://yellowhammer.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Statuses and glossary > Look up authoritative Yellowhammer terms and Work Card statuses. Use Yellowhammer's terms to interpret the selected Project's Pulse, Linear records, and Night Summary. Triage decisions belong in Linear; local configuration belongs in Settings. ## Statuses ### Blocked Automatic work on this Card has stopped and needs human action. Read the precise Block Reason and next action at the start of its Managed Block in Linear. Review failures, missing Routes, expired questions, Operator aborts, and authoring defects require different responses. After the stated repair, moving the Card back to **Todo** can make it eligible to retry; follow its own next action. ### Waiting on You A Work Card or Feature needs your answer or decision. Read the question and reply in Linear using the action requested on that record. Only Nights this Project runs count toward the Unanswered Nights Bound; an overdue question can become Blocked. ### Partial Landing A repository lane published eligible completed work while other Work Cards remained incomplete. Read the pull request and Night Summary for missing work and its reason. Partial Landing describes a result, not a promise that the whole Feature is complete. ### Todo, In Progress, and Done **Todo** is eligible pending work; **In Progress** shows work underway; **Done** marks completed work in the board workflow. Read the Check and Verification evidence and pull request links before concluding that a Feature is merged. Moving a Feature to Done on the board can carry its unfinished Cards forward without establishing they passed their Checks. ### Shelved A Card deliberately taken out of active work in Linear. Yellowhammer reads this state but never writes it. Shelved work does not hold landing as unfinished active work. ## Canonical terms ### Project One product scope containing its repositories, Linear project, and specification. Each Project has independent Nights. ### Night One run for one Project, from its first Act firing through the Night Card being completed. A Night can advance through several Features sequentially, with one in flight at a time. Its identity is the date of the configured Night start; a Night that produced no work still has a result. ### Feature One product feature selected for work. The product glossary defines it as the unit of intent; exactly one Feature is in flight per Project at a time. ### Work Card A dispatchable unit of work represented by a Linear issue and local execution record. One Work Card is scoped to one repository. ### Night Summary The account of a Night carried on its Night Card, including completed work and exceptions. ### Night Card A Linear card created for a Night and completed with its Night Summary, including when no work happened. ### Definition of Done The set of clauses describing what must be true for a Feature or Work Card to be finished. Clauses cite locations in the specification. ### Verification A clause-by-clause report against a Definition of Done and its specification citations. It supports an auditable judgment; it does not guarantee correctness. ### Spec Citation A reference from a Definition of Done clause to a specific location in the specification. ### Route The combination of agent CLI, model, and effort used for a Work Card. ### Agent CLI A coding agent command-line interface that Yellowhammer invokes locally to perform code work. ### Repo A repository configured as part of a Project. ### Repo Dependency A declared relationship between repositories that matters when a Feature spans repositories. ### Orca The local development environment that provides isolated worktrees for Night execution. ### Worktree An isolated Git working tree managed by Orca ADE for a repository lane. Sequential Cards in the same lane share its Worktree; a fresh Attempt resets to the recorded known-good state rather than treating failed work as completed. ### Bound A configured limit that stops repeated work, such as attempt or review-round limits. See [Set limits and protected paths](https://yellowhammer.dev/docs/run/set-limits-and-protected-paths.md). ### Protected Paths Repository paths declared as out of scope for a Work Card. Yellowhammer checks for overlap before dispatch; this is not a sandbox or a post-edit fence. ### Rehearsal Night A deliberate rehearsal mode of a Night with its own configured board project and Journal. It uses the same installed app and engine, with rehearsal mode selected at runtime. ### Pulse The main window surface that presents a selected Project's current and recent activity. ### Inspector The main window's detail pane for the current selection. It provides read-only inspection and navigation to Linear for actions that belong there. ### Pull Request A GitHub review request opened for a repository touched by a Feature. A human decides whether and when to merge it. ### Act One short-lived engine invocation: **author** prepares a Feature, **build** coordinates implementation and review, and **land** handles Verification and publication. Each invocation belongs to exactly one Project. ### Attempt One dispatch of a Work Card on a Route. A new Attempt has a fresh Round budget. Hard failures and exhausted Rounds can exclude a Route; an Operator abort or usage-limited ending does not consume the Attempt budget. ### Round A review or Check asks the same Attempt to revise its work. This uses the same worker and Worktree; it is separate from starting another Attempt on another Route. ### Check The command configured for a Repo that the engine runs to check its work. A declared `none` means that Repo has no automated Check; it does not establish correctness. ### Managed Block The section of a Linear Card that Yellowhammer maintains with execution evidence, Attempts, outcomes, and the next action. Read its Block Reason to understand why work stopped. ### Board Connection A named local connection to a Linear workspace, with its authorized app and selected Operator identity. Projects select a Board Connection; multiple Projects can use the same workspace connection. ### Code Hosting Connection A named GitHub credential choice used by Projects for repository access and publication. Changing a Project's connection checks push access before accepting the change. ### Journal The local execution record for one Project. The engine owns its state; the app reads it to show the Pulse and Inspector. A rehearsal has a separate Journal. ## Related pages See [Projects, Features, and Work Cards](https://yellowhammer.dev/docs/concepts/projects-features-and-work-cards.md), [the lifecycle of a Night](https://yellowhammer.dev/docs/concepts/lifecycle-of-a-night.md), and [review the morning](https://yellowhammer.dev/docs/review/overview.md). ## Next steps [Diagnose setup and connections](https://yellowhammer.dev/docs/reference/troubleshoot-setup-and-connections.md) ยท [Review the morning](https://yellowhammer.dev/docs/review/overview.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.