@shivaedev/work-board 0.11.0 → 0.13.0

package/docs/delivery/wave1.md

@@ -0,0 +1,66 @@
+# Wave 1 delivery — stay informed
+
+The [delivery plan](./README.md) explains gates and verification. These steps define the reading outcomes tracked in the [roadmap](../roadmap.md). This wave concerns reading and personal view state. Agents keep writing files through their existing tools. Follow numeric order unless the prerequisites below permit a useful independent change.
+
+## 01 A real workspace shell
+
+**Outcome:** opening the existing folder feels like a navigable workspace. Replace the wrapping top bar with a collapsible sidebar and breadcrumbs; use a readable document measure and a wider board canvas. Introduce shared color, spacing, typography, density, and light/dark/system theme tokens. Keep existing routes and `--home` behavior. Add the representative workspace and browser acceptance path alongside this visible change, not as a standalone framework. [Browser acceptance](./browser-acceptance.md) uses the shared large-workspace fixture. **Depends on:** the vision. **Accept:** 50 documents do not push the content out of reach; keyboard focus, narrow screens, diagrams, and live updates still work.
+
+## 02 Document locations and reading state
+
+**Outcome:** users can point to a passage and return without losing their place. Add heading anchors, an outline, active-file/title treatment, back/forward behavior, favorites, and recents. Resolve relative links from the source file, including a nested home file served at `/`. Preserve selection, open details, and scroll when navigating back. Scope local preferences to the workspace. **Depends on:** 01. **Accept:** duplicate headings have unambiguous anchors; encoded filenames work; a deleted target explains what happened. Document that generated heading anchors can change after a rename; durable item IDs come in 04.
+
+## 03 Find work from anywhere
+
+**Outcome:** one search locates a phrase, document, or heading across the folder. Add a keyboard-opened search/command dialog with snippets, explicit result types, empty results, and navigation to the matching passage. Begin with a small rebuildable text index and deterministic matching. Refresh it on file changes. Offer source-in-editor navigation only through an agreed local editor mechanism. **Depends on:** 02. **Accept:** a known phrase is findable in the large fixture; keyboard selection and Escape restore focus; stale requests cannot replace newer results. Review 01–03 with real project notes before expanding the model.
+
+## 04 Optional identity and a rebuildable index
+
+**Outcome:** richer work is recognizable without making plain Markdown invalid. Prepare D1's examples, then implement the agreed read-side schema and source locations. Model optional IDs, item kind, status, owner, next action, relationships, criteria, and evidence provenance as needed by the first real examples. Reuse and extend 03's index. Display useful diagnostics for malformed metadata, duplicate IDs, and unresolved references while keeping prose readable. **Depends on:** 03 and D1. **Accept:** existing boards render unchanged; the index rebuilds entirely from files; unknown metadata is not guessed or silently lost.
+
+## 05 One body of work, several views
+
+**Outcome:** document, board, and table offer consistent views of the same items. Add multiple board selection, filtering/sorting, saved local views, compact mode, and a side detail pane. URL state restores the view and selected item. Use the agreed board declaration to separate a view from a status; a section name alone must not become an inferred workflow rule. No dragging or content writes yet. **Depends on:** 01 and 04. **Accept:** counts and selections agree across views, filters remain applied during updates, and a disappearing selection is explained. Split board/detail and table/saved-views into two PRs if each needs a large review.
+
+## 06 Follow the reasoning and the evidence
+
+**Outcome:** a result leads to its criteria, plan, decision, and supporting files. Render decision options, rationale, backlinks, dependencies, and criterion-level evidence. Show origin, checked revision, and observed time where explicitly provided. Missing evidence and an agent's unsupported claim remain distinct from verified results. Begin with readable links; inline asset previews arrive in 10. **Depends on:** 04–05. **Accept:** the sample result reaches its source rationale in two navigation steps; broken links and evidence for an old revision stay visible.
+
+
+## 07 An attention-first overview
+
+**Outcome:** returning users can identify the next judgment without reading a log. Derive queues for explicit decision requests, blockers, and review requests. Each entry names why it appears, whose response is needed, and what it unblocks. Use simple visible ordering and link directly to 05/06's context. Include quiet and empty states. Do not treat file churn, heartbeat, or a finished agent run as progress. **Depends on:** 05–06. **Accept:** representative users can find the intended next judgment within the proposed 30-second target; ambiguous items stay unclassified.
+
+
+## 08 What changed since I last looked
+
+**Outcome:** readers distinguish meaningful changes from an unchanged busy process. Track local last-viewed markers and compare retained source revisions for explicit field/content changes. Show additions, removals, changed decisions, and evidence updates with source links. Define bounded retention and clearing before retaining snapshots. If history is unavailable, say so; modification time is not a diff. **Depends on:** 04 and 07. **Accept:** a returning view summarizes a known sequence of edits correctly; a first visit, cleared storage, or renamed source never invents history or authorship. No durable event journal is required.
+
+
+## 09 Live updates that preserve orientation
+
+**Outcome:** the workspace stays current without disturbing active reading. Use changed paths to invalidate affected documents, derived views, search results, and backlinks. Keep navigation updates when files are added/deleted. Add pause, pending-change count, restrained highlighting, and resume. Recover with a full reconciliation after reconnect or uncertain watcher state; never trust a path-only optimization when events may have been missed. **Depends on:** 05–08. **Accept:** unrelated edits avoid full active-document rerenders; focused controls, open details, and diagrams survive relevant changes; paused and reconnecting states catch up without claiming stale data is current.
+
+
+## 10 Local visual evidence
+
+**Outcome:** screenshots and diagrams are inspectable inside the work context. Serve an explicitly allowed set of local attachments with root containment and correct media handling; watch their changes as well as Markdown. Resolve paths relative to source files. Add image preview/gallery and Mermaid zoom, fullscreen, and local image/diagram downloads, with useful load/parse errors and keyboard dismissal. **Depends on:** 02 and 06; can precede 07–09 if needed by actual evidence. **Accept:** local images render and update; traversal/symlink escapes are refused; large diagrams can be read on narrow screens without losing the source context.
+
+
+## 11 A small vocabulary for visual documents
+
+**Outcome:** plans can communicate through comparisons, callouts, and progress. Implement the agreed readable conventions for callouts, option comparisons, metric/progress blocks, and a simple timeline. Use existing semantic data where possible. Keep the initial component list fixed, with text alternatives and no arbitrary executable content. Counts and metrics must name their source; unknown values should not display a fabricated percentage. **Depends on:** 04, 06, and 10. **Accept:** the real project brief communicates its plan using these blocks, remains useful in a text editor, and degrades intelligibly when a component's input is incomplete. Complex composition waits for 23.
+
+
+## 12 Start with useful project documents
+
+**Outcome:** a new user can begin locally and read useful project and agent reports. Provide copyable Markdown templates for a project, investigation, and agent result; useful empty-state instructions; and preserve basic browser print readability. Reports are ordinary source documents read through normal Work Board views, with links to plans, decisions and recorded criterion-level evidence. No report format creates verified acceptance or a new execution/handoff protocol.
+
+Document export is outside product scope: external shareable artifacts, portable snapshots and meeting packets have no demonstrated Work Board use case. Do not build HTML/PDF/ZIP packet generation, export previews, selection manifests, or a deferred export feature in another wave. Native browser printing remains a reading affordance, not a PDF service or artifact builder. An `init` CLI command still needs a separate API decision; copyable templates do not write source files. **Depends on:** 07 and 10–11. **Accept:** start from an empty folder, use the copyable templates through an existing editor/agent tool, and inspect the resulting project, investigation and result in ordinary Work Board views. Unknown outcomes and recorded evidence remain distinct from verified acceptance; the viewer does not create source files or mark history seen implicitly.
+
+
+## 13 Prove the complete reading workflow
+
+**Outcome:** wave 1 is a dependable tool, not only a convincing demonstration. Use it for real project notes while agents update the source through existing tools. Exercise the full large/empty/malformed fixtures, reconnects, rename/delete, keyboard focus, contrast, reduced motion, desktop/narrow layouts, and embedding. Measure agreed performance budgets and preserve all existing package guarantees. **Depends on:** 01–12. **Accept:** record the roadmap's wave 1 exit evidence and remaining limitations. Assess response/source ownership against the concrete examples; do not fix usability gaps by adding an agent execution engine.
+
+Use the [repeatable reading review](./reading-review.md) to gather technical, reader and device evidence. Record results and scope decisions in the roadmap.

package/docs/delivery/wave2.md

@@ -0,0 +1,43 @@
+# Wave 2 delivery — inform back and coordinate
+
+These requirements define contextual response and coordination outcomes. The [roadmap](../roadmap.md) owns completion and discussion decisions; the [delivery plan](./README.md) identifies the material needed for each review. Prefer one dependable response loop over many editing controls.
+
+## 14 Prove one safe source mutation
+
+**Outcome:** publish one intended source record without losing reviewed work. Use explicit question identity and expected revision. Preserve the agent-authored project document, revalidate workspace access, publish the new record without replacement, and expose typed rejection or an uncertain save outcome. A reviewed source can change after preflight; the independent record retains that context without claiming a transaction with every outside editor. Prove reconciliation and ordinary failure recovery, and document the filesystem limits. **Depends on:** 13 and D2. **Accept:** stale and competing writes, write failures, renames, permission failures, and repeated submissions cannot silently discard user content or report success without a known persisted result. Add a minimal visible action in this PR so the command is exercised through the real server.
+
+## 15 Respond to the exact thing you reviewed
+
+**Outcome:** feedback belongs to the proposal or result that prompted it. Build the agreed anchored response and revision-request surface over 14. Bind responses to the item and reviewed source revision; retain drafts during refresh, navigation, and recoverable failure. Show pending, saved, rejected, and uncertain outcomes distinctly. Recheck the content trust model and new write authorization; read-mode raw HTML must not gain permission to trigger edits simply because it is served by the same local application. **Depends on:** 14. **Accept:** changing the proposal while a response is drafted preserves the draft and identifies the revision difference before submission; failed submission does not clear input or produce a false saved confirmation.
+
+## 16 Record a decision and its consequence
+
+**Outcome:** a choice creates durable direction that the next contributor can use. Turn 06's read-only decision comparison into a decision action with selected option, rationale, reviewed revision, affected work, and next action. Show what will be recorded before saving. Distinguish a superseding decision from editing history. Keep this single-file where possible; do not automatically rewrite every affected task to simulate cross-file transactions. **Depends on:** 06 and 15. **Accept:** the choice survives reload and appears in linked context; a changed proposal does not inherit an earlier approval without qualification. Demonstrate recovery when the source moves or disappears.
+
+## 17 Narrow editing and honest undo
+
+The [ownership boundary](./source-editing-examples.md) keeps project edits in ordinary agent tools. Consult the roadmap before adding direct editing controls; the requirements below define what such controls would need to preserve.
+
+**Outcome:** routine updates no longer require leaving the work context. Add create/title/checklist/status actions one at a time through the same command path. Add explicit move controls, then optional drag-and-drop with the same keyboard behavior. Preserve unrelated formatting and meaningful source order. Offer undo based on the actual saved change and current revision; retain later editor or agent changes rather than restoring an entire obsolete file snapshot. **Depends on:** 14–16. **Accept:** edits round-trip to readable Markdown; an edit followed by another writer's change either undoes safely or explains the conflict. Keep cross-file moves and automatic one-file-per-item migration out until their partial-failure and recovery behavior has its own design and proof.
+
+## 18 One local agent handoff
+
+**Outcome:** one existing agent tool can receive complete direction and acknowledge it. Use D3's ordinary Markdown direction and copied instruction for an existing session. Carry goal, constraints, source path/revision, acceptance criteria, recipient, and next action. Record requested, acknowledged, rejected, and unavailable states. Use a handoff identity to recognize retries without creating duplicate work. An acknowledgment means receipt, not completed execution or accepted results. The [D3 walkthrough](./handoff-examples.md) defines ordinary receipt edits and copying a tiny prompt into an existing session. Preparing it does not launch agents. **Depends on:** 15–16, the ownership boundary, and D3. The agent must be able to acknowledge by editing ordinary files; a special writer or acknowledgment command cannot be mandatory. **Accept:** send one real handoff, observe receipt, and exercise unavailable tool, duplicate request, and lost-acknowledgment cases. Never silently switch agent/tool or assume a timed-out request was not received.
+
+## 19 Review a returned result against its criteria
+
+**Outcome:** the agent's result becomes inspectable work requiring explicit review. Receive artifact/source references, checked revisions, criterion-level claims, supporting evidence, and stated limitations. Keep execution state separate from work state. Support request-revision and explicit human acceptance through 15–16's versioned response path. Surface stale evidence or changes after review without silently carrying acceptance to a new result. **Depends on:** 06, 10, and 18. **Accept:** a returned run can be finished while its item remains in review; missing evidence stays missing; a human requests a revision, receives a new result, and accepts the specific reviewed version.
+
+The [ordinary-file result review walkthrough](./result-review-examples.md) composes existing result, attention, directive question and immutable response formats. Report status, work status and authored acceptance remain separate. Changed report contexts qualify earlier feedback; checked Git evidence revisions remain reported and are not compared with the current checkout. The roadmap records actual acceptance evidence and limits.
+
+## 20 Complete the first coordination loop
+
+**Outcome:** one real feature moves from proposal to accepted result locally. Run a real bounded feature through decision, handoff, acknowledgment, result, revision request, second result, and acceptance. Include a restarted browser/server, an offline/unavailable agent tool, and an editor changing a relevant file. Verify that another agent can resume from the resulting files without reconstructing a chat history. Record remaining failure modes and revise the interaction design. **Depends on:** 14–16 and 18–19, with the source ownership decision guiding 17. **Accept:** the roadmap's wave 2 exit is demonstrated with real source/evidence and no silent overwrites. Only then plan multiple contributors and broader adapters. This does not imply production-grade concurrent co-editing.
+
+## Deliberate exclusions
+
+No general rich-text editor, hidden task database, arbitrary script execution, agent scheduler, full terminal UI, or external two-way synchronization. The browser, local CLI/API, and tool adapter must share mutation semantics rather than invent parallel write paths. Use existing Effect and Platform conventions where needed; choose concrete API names and transports at their design gates.
+
+## Source contract references
+
+The [response contract](./response-write-examples.md) uses independently published question/response records, rather than replacing an agent’s project document. The [packet reference](./decision-write-examples.md) explains complete typed answers and explicit supersession. The [ownership boundary](./source-editing-examples.md) keeps ordinary agent file editing sufficient. Implementation status and acceptance evidence belong in the roadmap.

package/docs/delivery/wave3.md

@@ -0,0 +1,31 @@
+# Wave 3 delivery — collaborate locally
+
+These requirements extend [wave 2](./wave2.md) with successive contributions. The [roadmap](../roadmap.md) owns implementation status and admission decisions. Step 21 is the core collaboration outcome. The remaining steps are independently useful extensions; especially 24–26 should earn their place rather than block local collaboration.
+
+## 21 Successive contributions with clear ownership
+
+**Outcome:** several agents and a person can contribute without obscuring who owns the next action. Extend 18–19's single-contributor loop to explicit transfer, contribution references, conflicting proposals, and a visible current owner. Retain the expected source revision for every contribution and response. Start with coordinated turns and merges of reviewable proposals; simultaneous text co-editing is not a prerequisite and would need a separate design. **Depends on:** 20. **Accept:** two real contributors act on the same work, one stale contribution is identified, and the person resolves the next handoff without losing either proposal. An unavailable owner is visible, not reassigned silently. No remote multiplayer or new execution infrastructure is introduced.
+
+## 22 Several local projects, one attention view
+
+**Outcome:** a person can find the next judgment across explicitly selected local workspaces. Aggregate the attention/read model, preserving project-qualified IDs, source roots, per-project preferences, and independent availability. Opening a result returns to its original workspace and exact context. Scope folder access explicitly; do not scan the user's machine or widen serving to every filesystem. **Depends on:** 07–09 and 21. **Accept:** identical item IDs in two projects do not collide; one unavailable folder does not hide the others or route an action into the wrong project. Keep writes owned by the originating workspace.
+
+## 23 Richer plans and linked reviews
+
+**Outcome:** larger work can be understood and reviewed as a coherent whole. Extend the fixed component vocabulary with bounded split layouts, dependency maps, and timelines where explicit relationships/dates support them. Distinguish unknown dates from estimates and commitments. Help a reviewer follow linked plans, decisions, criteria, evidence, revisions and limitations inside the normal workspace. **Depends on:** 11–12 and 19. **Accept:** a reviewer follows those source links and sees missing or stale evidence clearly. Cycles and unresolved dependencies are shown. Shareable/exported packets are outside scope. Do not grow a freeform executable dashboard or plugin system to implement these views.
+
+## 24 One optional read-only GitHub adapter
+
+**Outcome:** a linked PR's current evidence no longer requires repeated copying. At D4, pick one repeated workflow and specify its authoritative fields. Read only explicitly linked PRs and their checks/review/merge state; record checked commit, last successful observation, refresh failures, and provenance. Keep credentials outside project content and make opt-in/out explicit. Local plans and decisions remain authored locally; the adapter does not overwrite them. **Depends on:** 19 and D4; can proceed independently of 22–23 after wave 2 exits. **Accept:** a changed PR revision makes old check evidence stale; unavailable or unauthorized GitHub access leaves the local board usable. No organization crawl, issue replication, write-back, cloud service, or generic connector framework.
+
+## 25 Read existing local test and build artifacts
+
+**Outcome:** locally produced results can support criteria without manual prose. Select one actual machine-readable report produced by the project's existing commands. Parse it through the same provenance/evidence model, including run identity, relevant source revision where available, completed/partial state, and failures. Observe results; do not turn the board into a command runner. Add another format only after the first reader proves useful. **Depends on:** 10 and 19; independent of GitHub adapter adoption. **Accept:** an interrupted report is incomplete, an unrelated revision does not verify the current work, malformed input yields a useful diagnostic, and deleting the artifact makes the evidence unavailable rather than leaving an eternal pass.
+
+## 26 Quiet rules and a real collaboration review
+
+**Outcome:** stable, explainable signals reduce attention overhead. Start with one observed need, such as surfacing a newly reviewable result. Show the source fact, the reason a rule fired, and its last action. Deduplicate unchanged events and allow disabling the rule. Rules may surface or suggest; handing off work or accepting results requires an explicit authority policy agreed separately. **Depends on:** 21 and a reliable trigger from 19, 24, or 25; no adapter is mandatory. **Accept:** repeated identical observations remain quiet, recovery does not flood the queue, and every surfaced item explains itself. Complete a real collaboration review, compare orientation/response effort with the earlier workflow, and retain only extensions that remove demonstrated friction.
+
+## Stop conditions for scope growth
+
+Pause an adapter or advanced view if it requires a second source of truth, organization-wide synchronization, a hosted component, or more maintenance than the manual step it replaces. Keep the existing local workflow complete when any extension is disabled. Expand only from observed use, not feature parity with a project-management suite. Release timing and additional API/package choices stay with the maintainer.

package/docs/experience.md

@@ -0,0 +1,89 @@
+# Work Board experience design
+
+The [north star](./north-star.md) states the intent and the [roadmap](./roadmap.md) owns status. This document describes the proposed experience, not current behavior.
+
+## Visual direction
+
+A calm workroom: warm paper, ink typography, dark evergreen navigation, precise rules, and restrained amber for attention. Let diagrams, evidence, and readable prose carry the page. Use system fonts so the experience works without downloads. Status always has a label; color alone does not communicate meaning.
+
+Documents keep a readable measure. Boards and evidence comparisons use available width. Dense work has a compact setting; initial orientation has breathing room. Motion explains an update and respects reduced-motion preferences.
+
+## Five connected scenes
+
+| Scene | Core question | Composition |
+| --- | --- | --- |
+| Overview | What needs me, and what changed? | Short project brief, attention cards, active work, meaningful activity |
+| Work | Where is each item, and what happens next? | Board/table over the same items, filters, persistent detail pane |
+| Decision room | Which choice should we make, and why? | Question, options, recommendation, consequences, anchored response |
+| Evidence | What supports this result? | Criteria beside artifacts, source revision, verified/claimed/missing distinctions |
+| Project brief | How does the whole plan fit together? | Narrative, metrics, roadmap, dependency sketch, related decisions |
+
+After `pnpm --filter @shivaedev/work-board build`, serve the package folder with a local static server and open `docs/mockups/index.html`. The prototype illustrates connected reading and coordination scenes. It is a design review artifact; use the roadmap and README to assess current behavior. All project names, counts, agent activity, timestamps, and evidence are fictional.
+
+## Navigation and interaction
+
+The sidebar provides project context and stable destinations. Global search finds documents, work items, and decisions; a result opens the relevant context. A work item opens beside its board rather than replacing it. A direct URL should restore selection and view when the underlying source still exists.
+
+Overview prioritizes explicit questions, blockers, and review requests. Each attention card states why it appears and the consequence of answering it. Unranked work remains available; the queue is not an opaque AI score.
+
+The decision room presents competing options with consequences and evidence. Recording a choice should display what will change and who receives the next handoff. A revision request stays attached to the exact proposal reviewed.
+
+Evidence separates a tool result from an agent's claim. A green check requires supporting evidence for the relevant revision. If a criterion has no evidence, show that gap. If the proposal changed after review, retain the decision context and ask for another review where needed.
+
+## Source and state boundaries
+
+Project files hold authored work. An index of those files may be cached and reconstructed. Personal UI preferences and last-viewed markers may live locally outside the authored documents. Their absence must not change project meaning.
+
+Optional metadata gives items stable identity, relationships, status, provenance, and acceptance criteria. The serialization format is a design decision, not fixed by these mockups. Ordinary Markdown remains readable. Legacy heading-based boards remain supported; missing fields are unknown rather than guessed.
+
+Human response writes need explicit reviewed identity/context, draft retention and clear save outcomes. Agents edit ordinary files and own the surrounding project Markdown. Follow the [ownership boundary](delivery/source-editing-examples.md); do not turn rare outside-editor races into a universal transaction requirement.
+
+## Essential states beyond the happy path
+
+| State | Intended experience |
+| --- | --- |
+| Empty workspace | Explain the folder model; offer a small local template |
+| Watching interrupted | Keep readable content, show freshness loss, catch up on reconnect |
+| File deleted/renamed | Preserve context and offer a resolvable location; do not silently redirect to unrelated work |
+| Invalid metadata/reference | Render readable prose and an actionable source diagnostic |
+| Stale external evidence | Show source revision and last check; never imply current verification |
+| Concurrent edit | Keep the user's draft and show the changed source before retrying |
+| Pending handoff | Distinguish requested, acknowledged, running, and returned |
+| Failed response/write | Retain input and explain whether anything was saved |
+| Paused live updates | Display paused state and pending changes; resume deliberately |
+
+These states need production designs and tests; the vision prototype does not implement the server, persistence, conflict handling, or real agent communication.
+
+## Prototype use
+
+The [prototype](./mockups/index.html) uses local CSS and JavaScript, no dependencies, and no external network requests. It is designed for direct file opening; environments that restrict file URLs can use a loopback static server:
+
+```sh
+python -m http.server 4782 --bind 127.0.0.1 --directory packages/work-board/docs/mockups
+```
+
+Then open `http://127.0.0.1:4782`. Navigation, board/table switch, filter chips, item detail, search, evidence tabs, and the decision response are illustrative interactions. All changes stay in memory and reset on reload. The response buttons simulate the interface only; they do not write files or contact an agent.
+
+On smaller screens, navigation wraps and the work layout becomes a vertical list; production should further tune touch navigation and accessibility with user tests. The prototype is a review artifact and is not an implementation starting point or a proposed framework/dependency choice.
+
+## Screen gallery
+
+These captures show the same fictional local prototype. The [combined board](mockups/images/vision-board.png) summarizes the visual direction; individual images preserve the detail for review.
+
+| Scene | Desktop | Mobile |
+| --- | --- | --- |
+| Overview | [Attention and activity](./mockups/images/overview.png) | [Narrow layout](./mockups/images/overview-mobile.png) |
+| Work | [Board and item context](./mockups/images/work.png) | [Stacked lanes](./mockups/images/work-mobile.png) |
+| Decision room | [Options and direction](./mockups/images/decision.png) | [Options on mobile](./mockups/images/decision-mobile.png) |
+| Evidence | [Artifacts and criteria](./mockups/images/evidence.png) | [Review on mobile](./mockups/images/evidence-mobile.png) |
+| Project brief | [Narrative and visual plan](./mockups/images/brief.png) | [Brief on mobile](./mockups/images/brief-mobile.png) |
+
+![Overview: work that needs your attention](./mockups/images/overview.png)
+
+![Work: board and selected item](./mockups/images/work.png)
+
+![Decision room: options and a contextual response](./mockups/images/decision.png)
+
+![Evidence: artifacts beside acceptance criteria](./mockups/images/evidence.png)
+
+![Project brief: a visual home for the plan](./mockups/images/brief.png)