0020 Installation Profile And Knowledge Boundaries

Date: 2026-07-21

Status

Accepted. Amended by decisions 0026 and 0027.

Context

Decision 0019 made the repository-centered workflow authoritative. Installation must make that boundary physically true: a consumer should receive generic repository guidance and the safe maintenance binary without upstream product history, application assumptions, or a second source of truth.

Decision 0026 added explicit-only onboarding skills to the core. Decision 0027 ended the former compatibility profile rather than continuing a two-product installer.

Decision

Harness has one product profile: core.

Core installs:

• the compact repository map and workflow;
• generic product, plan, and decision structure;
• optional templates for durable plans, decisions, runbooks, and measured Harness improvements;
• explicit-only onboarding and proposal-audit skills; and
• the checksum-verified Rust harness maintenance binary.

Core does not install:

• consumer product policy or architecture;
• application commands, credentials, fixtures, logs, or validation;
• a database, schemas, orchestration, or background processes; or
• upstream history, tests, CI, release scripts, and product decisions.

The engineering-wisdom advisory skill is an independent explicit opt-in, not a second product profile. It stores no state and establishes no consumer policy.

Installation and updates preserve unknown existing files. In particular, they do not automatically delete artifacts from the end-of-life compatibility product. Removal of consumer-owned legacy bytes requires a separate explicit decision in that repository.

Alternatives Considered

1. Keep a compatibility profile. Superseded by decision 0027 because its implementation and release train kept two products in one repository.
2. Install upstream architecture and examples. Rejected because their names and placement would make them appear authoritative for the consumer.
3. Offer many feature flags. Rejected because combinatorial profiles obscure the small stable core.
4. Install advisory philosophy by default. Rejected because repository authority, not upstream taste, must decide engineering policy.

Consequences

• Fresh installations have one product and one authority path.
• Consumer repositories receive no fabricated application truth.
• The installed binary can safely deliver later core improvements.
• Historical product implementations remain in Git rather than in consumer payloads or current documentation search.