Public documentation v0.1.0
Software Factory v0.1.0 release notes
The first public publication of the Software Factory source monorepo and generated Hermes profile repositories.
| Repository | Status |
|---|---|
| https://github.com/jack-michaud/software-factory | source tag profiles/v0.1.0 |
| https://github.com/jack-michaud/software-factory-pm-profile | generated tag/release v0.1.0 |
| https://github.com/jack-michaud/software-factory-builder-profile | generated tag/release v0.1.0 |
| https://github.com/jack-michaud/software-factory-orchestrator-profile | generated tag/release v0.1.0 |
| https://github.com/jack-michaud/software-factory-reviewer-profile | generated tag/release v0.1.0 |
| https://github.com/jack-michaud/software-factory-publisher-profile | generated tag/release v0.1.0 |
| https://github.com/jack-michaud/software-factory-docs-profile | generated tag/release v0.1.0 |
User-visible changes
The source repository is public, six installable generated profile repositories are public, generated profile repositories are tagged and released as v0.1.0, the source repository is tagged profiles/v0.1.0, and public repositories use the MPL-2.0 license.
Install
Install a generated profile with Hermes using the install matrix. For example: hermes profile install https://github.com/jack-michaud/software-factory-pm-profile.git --name softwarefactorypm.
Upgrade
Update an installed profile with hermes profile update softwarefactorypm --yes, replacing softwarefactorypm with the local profile name you installed.
Validation summary
The initial publication was verified against public GitHub repository state, remote heads and tags, profile releases, MPL-2.0 license files, README install/source contracts, and public-safety scans.
Docs deployment target contract
The public docs now describe the Software Factory docs sprite environment-variable contract: distribution.yaml declares expected env vars, .env remains user-owned runtime state, PM creates deployed-docs tasks only when a target exists, and docs profiles publish only to the explicit or env-named dedicated docs sprite.
Conditional disposable validation
The public docs now explain the conditional disposable/test-profile validation workflow: static reviewer checks are the default for low-risk docs/comment/typo/static-sufficient changes, while behavior-risk changes or explicit human requests use a PM-created disposable validation chain with randomly suffixed profiles, focused acceptance, at most two remediation iterations, reviewer/evidence gating, publication or rollout, and cleanup or explicit retention.
Builder source-update workflow
The public docs now describe the Builder source-map and git-flow doctrine installed in the production and meta Builder profiles: use the PM Source Map, clone or fetch canonical source repositories, create a topic branch, edit source-controlled files only, treat installed profile directories as deployment output, avoid unscoped publish/push/install actions, and provide repository, branch, commit, diff, validation, and coverage evidence for review and publication.
PM Source Map requirements
The public docs now describe the PM Source Map requirement installed in the production and meta PM profiles: PM-created profile/source-update tasks must identify the canonical monorepo, affected source paths, generated or installable role repositories, runtime verification targets, expected branch naming, publisher/submodule follow-through, reviewer checks, and disposable validation decision and rationale. Installed ~/.hermes/profiles directories are runtime verification targets, not source of truth.
Profile-managed project-specific skills
The public docs now explain that published/shared skills should remain reusable across Software Factory projects, while project-specific instructions, checklists, routing notes, examples, and conventions belong in local profile-managed skills until generalized, reviewed, and published.
Known limitations
Branch protection and mandatory PR-review policy are deferred for v0. Repository descriptions and topics may be empty until a later repository-settings pass. Generated repositories are artifacts; make routine changes in the source monorepo and republish through the approved workflow.