Harness Public Entrypoints Grill Status

Branch Dashboard

Glossary

Terms

• Entrypoint: A documented way to start Harness work, grouped publicly as Core, Atomic, or Commands.
• Core Entrypoint: A primary public path for starting a major Harness workflow.
• Command Capability: A dp CLI capability surfaced in the entrypoint overview but explained mechanically in Get Started or CLI docs.
• Implementation Entrypoint: The primary delivery path for turning accepted scope into shipped changes, centered on manual delivery with AFK delivery as a variant.
• AFK Delivery Variant: The unattended implementation-delivery route nested under the main implementation entrypoint.
• Atomic Skill Entrypoint: A standalone skill that operators may intentionally invoke without entering a full lifecycle phase.
• Theory Signal: Conceptual material that explains why Harness works the way it does, separate from first-action operator guidance.
• Redirect Alias: An old public URL kept as compatibility for readers and inbound links after the canonical route changes.
• Trust Page: The merged single-page trust/adoption surface that preserves all existing child-page content.

Relationships

• Implementation Entrypoint includes AFK Phase Delivery Flow as a variant.
• AFK Delivery Variant lives as a child route under Implementation Entrypoint.
• Entrypoint may be a Core, Atomic, or Commands page in the public overview.
• Redirect Alias points from old lifecycle-flow URLs to canonical /docs/harness/entrypoints pages.
• Tool Mention should link to a routed wiki tool page when one exists.
• Skill Mention should link to the source SKILL.md in wearedevpunks/skills.

Axioms

• Get Started remains the first-run practical surface for now.
• The public IA should answer "what can Harness Intelligence do?" before sending readers into theory.
• The canonical public route for Harness entrypoints is /docs/harness/entrypoints.
• Old lifecycle-flow URLs should redirect to the corresponding entrypoint pages.
• The entrypoint overview should include command capabilities but leave command mechanics to Get Started and CLI docs.
• AFK delivery should be a route-level child of the implementation entrypoint, not a sibling top-level entrypoint.
• Variants should keep detail pages where useful, but should not appear as a top-level overview category.
• Foundations should explain the model behind Harness, not compete with entrypoints for first-action guidance.
• Consolidation must preserve useful trust/adoption material instead of deleting it because pages are merged.
• Old trust/adoption child routes should disappear rather than redirect.
• Link density should improve discoverability without turning every paragraph into a reference table.

Flagged Ambiguities

• None.

Parked Branches

• None.

Locked Route Plan

Entrypoint Overview Categories

1. Core
2. Atomic
3. Commands

Do not display variants as a top-level category.

Canonical Entrypoint Pages

Atomic Entrypoints

• parallel-research: https://github.com/wearedevpunks/skills/tree/main/skills/agnostic/research/parallel-research
• handoff: https://github.com/wearedevpunks/skills/tree/main/skills/agnostic/generic/handoff

Command Capabilities

• dp update
• dp report

Redirects

Top-Level Harness Sidebar

1. Entry Points
2. Skills
3. Tools
4. Foundations
5. Prompt Surface
6. Exec
7. Trust

Implementation Task Outline

1. Move route IA: create /docs/harness/entrypoints, move flow pages, update metadata/sidebar titles, and add lifecycle-flow redirects.
2. Rewrite entrypoint overview and page titles: Core, Atomic, Commands; preserve existing phase-flow details.
3. Merge trust/adoption: combine all child-page content into one Trust page and remove child routes.
4. Link and theory pass: add validation/tool links, skill source links, and stronger theory signal across all Foundations pages.
5. Validate: run wiki type/build checks and browser smoke for moved routes plus redirects.

Remaining Questions

None. The requirements grill is done. Next direction: backlog/user-story creation or implementation planning.