Skip to content

Latest commit

 

History

History
72 lines (56 loc) · 3.09 KB

PRODUCT.md

File metadata and controls

72 lines (56 loc) · 3.09 KB

Product

Register

brand

Users

Staff+ engineers, architecture leads, and platform-minded technical leaders who need architectural decisions to remain discoverable, enforceable, and useful after the original discussion ends. They are evaluating whether adrkit can make decision governance practical for both human- and agent-authored plans without introducing another external system of record.

Product Purpose

adrkit turns architecture decision records into typed, machine-readable data that stays in git. It helps teams validate decisions, locate the records that govern a change, understand why a choice was made, and prevent accepted constraints from silently drifting. The website should make that difference immediately legible, establish technical credibility, and move qualified users into the quickstart or the decision corpus.

Product Boundary

Per ADR-0037, adrkit's boundary is to govern human-reviewed decisions rather than generate a general-purpose architecture wiki. Generated knowledge systems may consume and present the decision corpus as a downstream read model, but generated content does not change decision lifecycle, ratification, typed relationships, or what a decision affects. This boundary lets adrkit integrate with documentation ecosystems without adding model providers, connectors, or another source of truth.

Brand Personality

Exacting, consequential, trustworthy. The voice is direct and technically precise without becoming cold, theatrical, or bureaucratic. It treats architectural decisions as durable engineering infrastructure, not process ceremony.

Anti-references

  • Generic dark developer-tool landing pages that use neon accents, terminal cosplay, glowing grids, or hacker aesthetics as a substitute for product meaning.
  • Interchangeable SaaS layouts built from repeated icon cards, vague claims, and decorative metrics.
  • Documentation themes that expose navigation and prose without first explaining why the product matters.
  • Editorial-magazine treatments that make governance feel ornamental rather than operational.

Design Principles

  1. Make the governing idea tangible: show how a decision connects to the code it affects instead of relying on abstract claims.
  2. Earn trust with specificity: distinguish what works today from what is planned, and use real commands, records, and constraints as proof.
  3. Treat decisions as infrastructure: the experience should feel durable, inspectable, and operational rather than ceremonial.
  4. Keep humans visibly in control: adrkit routes and explains; it never pretends to replace architectural judgment.
  5. Reward deeper inspection: the homepage should lead naturally into the quickstart, schema, and dogfooded ADR corpus.

Accessibility & Inclusion

Target WCAG 2.2 AA. Maintain visible keyboard focus, semantic structure, strong text and control contrast, reduced-motion alternatives, and color-independent status cues. Technical examples must remain readable at narrow widths and usable with zoom or reflow.