Skip to content

Documentation restructure: make the README approachable #626

Description

@fain182

Problem

The README is 686 lines, and ~66% of it is reference material:

Section Lines Type
Available rules 312 reference
Rule Builders 115 reference
Usage 108 mixed
Quick Start 47 onboarding
Introduction 40 onboarding
Configuration reference 23 reference
Installation 21 onboarding
Integrations 4

It reads like a reference manual wearing a landing page's clothes: someone arriving from GitHub or Packagist to answer "what is this and do I need it?" has to scroll past the full catalog of every rule. There's also duplicated content — install is documented twice (Quick Start + Installation), and configuration is explained in three different places.

Goal

The README should have one job: convince the reader, get them to a first green check, and point them to where to go next. Everything that is consultation (the rule catalog, the builders) is reference — and reference is searched, not read, so it shouldn't sit in the reading flow.

Reference and long-form guides move into a docs/ folder in the repo (markdown, browsable on GitHub, versioned with the code, reviewed in PRs).

Target README

A slim landing page (~150–180 lines):

  • Hero — what it is + why it matters
  • Quick comparison — when to choose PHPArkitect vs the alternatives (Deptrac, PHPat, Pest arch testing) (new content)
  • Quick Start — install + init + check, unified (removes the duplicated Installation section)
  • Core concepts — ClassSet / Rule / Expression, with one example
  • A showcase recipe — one common architecture rule, linking to the cookbook
  • Rules at a glance — an index table, linking to the full reference
  • Further reading — links into docs/

Target docs/

Deliberately few files:

  • docs/rules.md — the full rule catalog + Rule Builders (the "what rules exist" and "how to compose them" belong together)
  • docs/configuration.md — the configuration reference table + config/baseline/output-format guide (the three duplicated config explanations merged into one)
  • docs/cookbook.md — copy-paste recipes for real scenarios: layered architecture, hexagonal, DDD bounded contexts, "the domain must not depend on the framework", naming conventions (new content)
  • docs/custom-rules.md — how to write your own Expression, based on the interface and a minimal example like IsFinal (new content)

Note on the comparison

Not a feature checkbox matrix (ages badly, easy to look biased) but an honest "when does each tool fit" framing. Every claim about other tools must be verified against their docs, not written from memory.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions