Battle-tested in one production project. Generalizability to other projects is a hypothesis, not yet a verified fact.
The methodology has been in active use through:
05. The stronger shared-ref protocol has not been exercised in production by anyone.It works as designed in that one context. Whether the same shape transplants cleanly to a different stack, team, or product category will become clear only as others try it.
Second instance: the methodology applied to itself. self-development/ runs this repo’s own development under these rules — strategy, nine pillars, chartered epics, locked items, DoD gates, an autonomous loop with tiered autonomy over the docs it edits, and a semi-annual self-evaluation. It is a real instance, but a docs-only one; it exercises the planning, review, and memory disciplines far harder than it exercises the UI-verification and testing disciplines.
Honest current state (v1.35.0 preparation): the first self-evaluation scored the project 8.11 average, minimum 6 and returned NOT READY for closed beta — one area (adopter discoverability) sits below the rubric’s minimum, and under the no area averaged away rule that single score decides the verdict. The blocker is not a doc gap. The eval named it “zero external promotion has happened,” which was already inaccurate when written — P5 records 13 GitHub topics, a live Pages site, and two awesome-list submissions. The accurate statement is that no active campaign has run, and as of 2026-08-19 none is planned: the staged distribution drafts were deleted by maintainer decision, on the position that a good project sells itself. The score and the verdict stand; what was removed is the prepared path to changing them, not the gap. That eval also flags its own weakness: it was conducted by the session that authored the release under review, so its scoring is biased toward charity.
v1.35.0 was merged into main through PR #38 but remains unreleased. E11 adds risk-based assurance and multidisciplinary software-squad guidance; independent review and maintainer acceptance remain pending. PR #40 subsequently merged the staged v1.36.0 changes, also unreleased. The latest tagged baseline is v1.34.0; see distribution status. Neither merge supplies external adoption evidence or changes the evaluation verdict above.
Distribution decision, 2026-10-18: the maintainer authorized preparation for six relevant directories and the housekeeping needed beforehand, revisiting the earlier passive-only position, then explicitly selected the latest content: the v1.36.0 preview including v1.35.0. Packages pin the merged source commit rather than fall back to the older v1.34.0 tag. Preparation, metadata corrections, and packages do not establish publication, adoption, release acceptance, or an improved milestone score.
Lean. This repo is published as a reference artifact, not a managed project.
What that means in practice:
If this approach to maintenance doesn’t work for you: fork freely. The CC BY 4.0 license exists for exactly this case. You don’t need permission to maintain your own fork; you can rename it, restructure it, and adapt it to your needs without involving the upstream — just keep the attribution.
Current practice: this repo follows the methodology’s 09_git_workflow.md rule in full. Every change lands on main via a feature branch and a PR — see PRs #13 onward, including every versioned methodology release since v1.19.0.
The exception below applied to this repo’s early life and is retired, on its own stated trigger: independent AI sessions now work in this repo, which is the second-contributor condition the exception named. The original text is preserved rather than deleted, because it documents a decision someone may have read and copied.
[!IMPORTANT] Superseded. The section below described this repo’s practice until the PR-only flow was adopted. It is kept for lineage; it no longer describes how this repo works.
The methodology’s own 09_git_workflow.md requires PR-only merges to the trunk and forbids direct commits. This repo deliberately doesn’t follow that rule — every commit here lands directly on main without a feature branch or PR.
Why the exception: this repo is solo-maintained. With one human + a paired AI session working the same branch, a PR-self-review adds no value:
The methodology’s PR-only rule exists for multi-contributor projects where the PR is the artifact that brings independent eyes to a change. With a single contributor pairing with their own AI, the rule’s reason for existing isn’t present.
Trigger for revisiting: when a second contributor (human or independent AI session) starts working in this repo, the exception ends. Branch protection gets enabled, feature-branch + PR flow gets adopted, the methodology’s rule applies in full.
This is the methodology’s own authority hierarchy at work: explicit user direction can override a general rule for a specific scope when the deviation is documented and the rationale is sound. The failure mode the rule guards against (“the trunk breaks because someone pushed a bad commit with nobody watching”) is mitigated here by working tree size: one contributor, small focused changes, immediate post-push verification.
Don’t take this as license to skip PRs on multi-contributor projects. It’s not. The exception is narrow.
Documents will change as understanding sharpens. Material changes will:
CHANGELOG.md, which is the single source of truth for what changed and why. Each release entry names the docs touched and, for landscape-informed additions, where the idea came from.Forks that need to pin to a specific state should pin to a specific commit hash or a tagged release.
If you’ve adopted this and learned something — what worked, what didn’t, what you adapted — the most valuable thing you can do is share it. Blog post, comment, talk at a meetup. Public experience reports help shape future iterations more than issues do.
If you find a factual error or a broken cross-link, an issue or PR is welcome.
For direct contact: polgarmiklos@gmail.com. No response SLA, but emails about real adoption experiences are read.
The bar for accepted PRs is high:
Most things people want to add or change are better expressed as a fork with a clear note in the fork’s README explaining what’s different and why. The upstream is intentionally narrow.
Extracted from the working practice of a real production project. The docs were written from scratch as a portable, abstract version. The source project’s name, domain, technology stack, and specific tooling appear nowhere in the methodology. This was a deliberate constraint at authoring time, not a transformation applied after the fact.