UI Design Phase Flow Backlog

Source requirements:

• UI design phase flow grill status
• UI design phase flow grill log

Provider: Linear

Linear sync:

• Project: HARNESS-INTELLIGENCE
• Team: Internal Projects (IP)
• Milestone: none assigned. The Linear connector in this session required an existing milestone UUID and did not expose milestone creation.
• Module: Design Phase And Visual Evidence
• Epics:
  • IP-273
  • IP-274
  • IP-275
  • IP-276
• Active stories:
  • IP-277
  • IP-282
  • IP-287
  • IP-292
  • IP-294

Provider payload guidance:

• Epic issues were created as top-level Linear issues in HARNESS-INTELLIGENCE.
• Active stories were created or reshaped as child issues with parentId.
• The initial fine-grained child stories were canceled after review because related changes belong in the same area-owned story.
• Ordering was represented with native blockedBy relations where scope genuinely depends on earlier behavior.

Active ordering:

• IP-275 is blocked by IP-274.
• IP-276 is blocked by IP-273 and IP-275.
• IP-287 is blocked by IP-282.
• IP-292 is blocked by IP-277 and IP-287.
• IP-294 is blocked by IP-292.

Module: Design Phase And Visual Evidence

Harness should gain a route-gated design phase that reads existing design systems, grills only the right constraints, produces approved artifacts, writes backlog context, and carries durable visual evidence into delivery and PR review.

Epic: Design Phase Route-Gated Lifecycle

Linear: IP-273

Outcome: Agents can run a dedicated design-phase flow that turns existing design evidence and lean user requirements into approved design artifacts, backlog context, and an activated delivery handoff.

Scope:

• Route every entry through the design-phase router.
• Preserve the accepted phase model: intake, grill, prototype, approval, backlog, delivery-handoff.
• Support direct entry only when prerequisite evidence is valid.
• Keep web and mobile inside the same outer lifecycle.

Story: Design-Phase Skill Supports The Full Route-Gated Design Lifecycle

Linear: IP-277

Outcome: Agents can run design-phase as one coherent route-gated skill that reads design evidence, asks a lean grill, delegates artifact production, waits for approval, writes backlog context, and activates delivery.

Acceptance signals:

• Every entry into design-phase goes through the router and emits selected phase, evidence, next file, stop-or-reenter decision, and blockers.
• Intake reads available routes, theme CSS or tokens, global styles, component files, screenshots, Figma/design inputs when available, content sources, and brand constraints.
• Missing Figma or screenshots do not block by default; low-confidence intake asks one concrete clarification or requests one screenshot.
• Grill branches default to one user-visible page or flow and stay limited to goals, scope, constraints, conflicts, hard requirements, content ownership, surface, and non-negotiables.
• Prototype phase reads artifact intent first, generates design directions as direct artifact input, and delegates image or prototype artifact work away from the main orchestration thread.
• Image requests use image generation plus web/mobile frontend image skills when available and fall back to prototype artifacts only when image generation is unavailable.
• Approval is tracked per user-visible scope unit, and backlog conversion is blocked until an approved artifact set exists.
• Delivery handoff activates delivery-phase with backlog scope, approved artifact links, target surfaces, frontend taste skills, and validation expectations.

Epic: Repo Settings Source Of Truth For Provider Configuration

Linear: IP-274

Outcome: Harness repos have one authoritative settings source for backlog provider, asset provider slug, repository manager, and required-tool checks.

Scope:

• .devpunks/settings.json has precedence when present.
• Existing repos can be backfilled from current repo history when the settings file is missing.
• Scaffold init captures both backlog provider and repository manager selection.
• Provider CLI requirements are committed with repo settings and checked during scaffold/update validation.

Story: Repo Settings And Scaffold Flows Own Provider Configuration

Linear: IP-282

Outcome: Harness repos have one provider configuration area where repo settings, scaffold init, backward-compatible backfill, required-tool checks, and wiki-provider cleanup move together.

Acceptance signals:

• .devpunks/settings.json records backlog provider, asset provider slug, repository manager, and required tools.
• When settings exist, they take precedence over wiki docs, inferred history, and legacy provider files.
• Missing settings can be generated from current repo history or existing provider hints; conflicts surface for operator review.
• Scaffold init prompts for repository manager selection alongside backlog provider selection and persists both into repo settings.
• Scaffold/update validation treats the selected repository manager CLI as mandatory and checks it with the same seriousness as other required tools.
• Existing backlog-provider wiki pages stop acting as configuration and point to repo settings if kept as explanatory docs.

Epic: Repo Asset Management Skill For Durable Visual Assets

Linear: IP-275

Outcome: Agents have one concise internal skill for choosing provider-specific asset hosting behavior, so design, backlog, implementation, and PR evidence use durable links without duplicating CLI guidance.

Scope:

• Provide a minimal progressive-disclosure skill for repo asset management.
• Preserve provider guidance for GitHub, GitLab, Azure, and Bitbucket.
• Let phase skills reference the shared skill instead of copying provider commands.
• Keep provider-specific command details in references.

Blocked by:

• IP-274.

Story: Repo Asset Management Skill Owns Provider Asset Guidance

Linear: IP-287

Outcome: Agents have one concise shared skill for durable repo asset hosting, with provider-specific guidance colocated under that skill instead of duplicated across phase skills.

Acceptance signals:

• The skill has a concise entrypoint with progressive disclosure.
• Provider-specific behavior lives in references for GitHub, GitLab, Azure, and Bitbucket.
• GitHub guidance identifies release asset upload as the clean CLI path and avoids promising a generic gh repo bucket.
• GitLab guidance prefers generic package storage for neutral asset hosting and explains release upload when release UX matters.
• Azure guidance points to blob storage as the durable bucket path and distinguishes it from artifacts or run-scoped uploads.
• Bitbucket guidance points to Cloud Downloads or documented API/pipe behavior and is clear when no first-party generic CLI path is assumed.
• The skill explains how to choose backlog attachments versus repo-provider attachments.
• Design-phase, write-backlog, implement-spec, and delivery-phase reference the shared skill instead of copying provider commands.

Blocked by:

• IP-282.

Epic: Visual Evidence Handoff For Design Backlog And PR Review

Linear: IP-276

Outcome: Approved design artifacts and UI implementation reviews carry durable graphical evidence from design approval into backlog items and PR before/after review.

Scope:

• Approved artifact sets include durable visual asset links.
• Backlog writing prefers backlog attachments and falls back to repo-provider attachments.
• Delivery handoff activates delivery with explicit before/after PR evidence guidance.
• PR evidence follows the existing UI screenshot evidence contract.

Blocked by:

• IP-273.
• IP-275.

Story: Design Backlog Flow Carries Approved Visual Artifacts Into Backlog

Linear: IP-292

Outcome: When a design scope is approved, design-phase and backlog writing keep the visual evidence with the backlog item using durable attachment behavior.

Acceptance signals:

• Approved artifact sets include generated images, prototype URLs, screenshots, or other inspectable artifact links when available.
• Artifact sets distinguish image references from prototype artifacts and carry enough design and acceptance context for later implementation.
• Backlog provider attachments are preferred when the provider supports them.
• Repo-provider attachments are used when backlog attachments are unavailable or unsuitable.
• Backlog items link durable visual assets in their implementation context.
• The fallback path is explicit rather than silently dropping visual evidence.

Blocked by:

• IP-277.
• IP-287.

Story: Delivery And Implementation Closeout Carry Before-After UI Evidence Into PR Review

Linear: IP-294

Outcome: When design-approved UI work moves into delivery, delivery-phase and implementation closeout carry durable before/after visual evidence into PR review.

Acceptance signals:

• Delivery handoff includes approved artifact set links.
• Delivery handoff includes before/after screenshot expectations for UI changes.
• Delivery handoff names the configured repo asset manager as the evidence path.
• Delivery activation includes browser or screenshot verification expectations.
• UI evidence links are durable provider-hosted assets.
• PR evidence follows the existing UI screenshot evidence contract.
• Implementation notes, PR body, or PR-ready handoff reference the same evidence links.
• Local temp files and non-durable browser URLs are not accepted as final evidence.

Blocked by:

• IP-292.

Superseded Linear Stories

These were created in the first pass, then canceled because they split related changes too finely:

• IP-278, IP-279, IP-280, IP-281: folded into IP-277.
• IP-283, IP-284, IP-285, IP-286: folded into IP-282.
• IP-288, IP-289, IP-290, IP-291: folded into IP-287.
• IP-293: folded into IP-292.
• IP-295: folded into IP-294.

Deferred Scope

• Linear milestone creation is deferred until a connector/tool path exposes milestone creation or an existing milestone UUID is selected.
• Actual design proposals, generated images, and prototypes are future design-phase runtime outputs, not backlog seed data.
• Implementation plans and file-level task breakdowns belong to future SPEC.md and PLAN.md artifacts.