EIF 0.2.4

Four defects, all of them things the tooling told the operator that were not
true. Three were found by running it on real repositories rather than by
reading it, and the oldest had been failing since 0.2.0 in a suite that no
workflow runs on its own.

Fixed

doctor called an integration misconfigured when its executable never
started. Only exit code 127 counted as "could not be started". A Windows
shim that cannot reach its interpreter exits 9009 through cmd.exe, and a
failed spawn exits 1, both with nothing on stdout. Both were reported as
misconfigured, which sends you to a configuration file to fix a value that
is already correct. They now report unavailable, whose remediation already
says the right thing. A probe that exits 0 and prints an unparseable or
out-of-range version did start, and is still misconfigured.

upgrade refused to run because of drift that the upgrade repairs. The
pre-flight verification of the pinned runtime failed on a drifted
knowledge/index.md, and told you to run eif_init.py again, which is
exactly what the blocked command wraps. Because eifctl projects upgrade
pre-flights every project, one project's index drift stopped the whole fleet.
eif_verify_runtime.py --pre-upgrade now reports the two checks that the
managed-state refresh regenerates as notes rather than failures; the
post-upgrade run still checks everything, and bundle integrity still fails
closed in both.

upgrade told people to revert changes that did not exist. On a fresh
clone of a connected project the framework axis succeeded, the tree stayed
clean, and the command exited 1 saying "do not commit the changes." The only
finding was the absent .eif/workspace-runtime/, which is gitignored by
design and which every first checkout on a new machine lacks. That case now
succeeds and says what to run. A genuinely failing check distinguishes a
clean tree with nothing to revert from a run that did write managed state.

The framework's own repository had the line-ending defect it fixes for
instances. Seven top-level Markdown files reported as modified forever
under core.autocrlf=true, with identical blobs and an empty git diff.
.gitattributes now pins the repository to LF. No blob changed.

How three of these stayed hidden

scripts/tests/test_package_build.py had three failing checks on 0.2.0
through 0.2.3. It runs only through run_all.py and through
release-check.yml, which is workflow_dispatch only and has never been
run. The cause was in the suite itself: its Windows test shim is a .cmd
file, cmd.exe parses batch files in the console OEM code page rather than
UTF-8, and the suite deliberately runs from a directory containing a
non-ASCII character, so the shim could not reach its own interpreter. The
shim now carries paths through the environment. The product defect above is
separate and real: it is what made a dead shim look like a configuration
error.

Known limitations

Unchanged from 0.2.3. The package is distributed through GitHub Releases
rather than PyPI. integrations/vendor-docs/manifest.json still does not
validate against the provider-manifest schema; nothing enables that
integration, so no doctor run reaches it. release-check.yml still runs only
on demand, which remains the most likely place for the next silent
regression.

Install

python -m pip install ./engineering_intelligence_framework-0.2.4-py3-none-any.whl
eifctl version

Engineering Intelligence Framework v0.2.3

A scope correction, not a code change. Nothing about how EIF behaves is
different in this release.

What was removed

docs/product/linkedin-series.md held an audience definition, voice rules,
commenting rules, and the arc of a publication series. None of that
describes EIF. It describes a marketing practice, and a framework repository
that documents its own marketing practice is slowly becoming its marketing.

It moved to the maintainer's private communications repository, where the
drafts, the reaction data, and the named third-party threads it governed
already lived.

What stayed, and why the line falls there

The claims register is unchanged and stays public. It is the
machine-enforced half: the site build fails when a page states something the
register does not allow, and a bound nobody can verify is not a bound.
Publishing it is the mechanism rather than a gesture, and each entry names
the evidence for a capability, which is genuinely about the framework.

The test for anything else: if it describes EIF or the evidence for a claim
about EIF, it belongs here. If it describes a person we are trying to reach,
or how to reach them, it does not.

Also in this release

docs/README.md and ROADMAP.md no longer enumerate publication channels.
The claims register's preamble now says "any public copy about EIF, wherever
it appears" instead of listing surfaces, which is what it always meant.

Historical CHANGELOG entries keep their text and lose the dead link.
Rewriting history to hide that the file existed would be worse than a note
saying where it went.

Known limitations

Unchanged from 0.2.2, including the three installed-wheel
integration-status checks in scripts/tests/test_package_build.py that fail
identically on 0.2.0 through 0.2.3. Not a regression, not fixed here. The
package is still distributed through GitHub Releases rather than PyPI.

Install

python -m pip install ./engineering_intelligence_framework-0.2.3-py3-none-any.whl
eifctl version

Engineering Intelligence Framework v0.2.2

A patch on top of v0.2.1, published the same day and for the same reason
v0.2.1 existed: the fix was checked by installing the published wheel and
cloning a real connected project on Windows, rather than by trusting that it
was finished. It was not.

What was still broken

The managed .gitattributes block that v0.2.1 introduced covered only the
files EIF hashes. That left .gitattributes and .gitignore uncovered, so
both fell into the trap the block exists to close: EIF writes them as LF,
core.autocrlf wants CRLF, and git reports them modified forever with
nothing in the diff. A dirty .gitattributes is the worst one to leave,
because git reads the attribute stack from it while deciding how to
materialize everything else.

Separately, .eif/config.yaml, .eif/framework.lock.yaml and .gitignore
were still written through Python's text mode, so newline translation landed
them as CRLF on Windows while git stored LF. That mismatch predates v0.2.1
and was invisible until the new attributes made git assert a specific
ending. They are written as bytes now, the way the agent entrypoint and the
knowledge index already were for exactly this reason.

What changed in the test, which matters more

scripts/tests/test_line_endings.py asserted the mechanism: that the managed
block contained the right lines. That passed while the property was broken,
which is how v0.2.1 shipped. It now asserts the property end to end: clone a
connected project with core.autocrlf=true, upgrade it, and the tree must
still be committable-clean. core.autocrlf is set explicitly rather than
inherited, so the check means the same thing on a Linux runner as on the
Windows machine where the symptom appeared. It fails on v0.2.1 and passes
here.

Upgrading

Nothing beyond the normal path. A project created or upgraded on v0.2.2 gets
the complete block. A project already upgraded to v0.2.1 gets the two extra
lines on its next upgrade.

python -m pip install ./engineering_intelligence_framework-0.2.2-py3-none-any.whl
eifctl upgrade --instance-path ../my-project

A project committed before v0.2.2 with converted line endings needs one
normalization after the upgrade writes the block:

git -C ../my-project add --renormalize .

Known limitations

Unchanged from v0.2.1, including the three installed-wheel
integration-status checks in scripts/tests/test_package_build.py that fail
identically on v0.2.0, v0.2.1 and v0.2.2. They are not a regression and are
not fixed here. The package is still distributed through GitHub Releases
rather than PyPI.

Engineering Intelligence Framework v0.2.1

Everything in this release came from running the published 0.2.0 setup path
end to end on two real private repositories on Windows, as a new user would,
rather than from running the test suite again. No schema changes and no
migration: 0.1.1 through 0.1.3 project configs and framework locks stay
compatible, and registry v1 keeps its named migration.

Two things that blocked a new user

eifctl init <path> did not exist. It failed with unrecognized arguments, so the first command of the published "connect an existing
repository" path, in both the README and the project lifecycle guide, never
ran. The path is now accepted positionally or as --instance-path, and a
first-ever init defaults the project name to the directory name.

A fresh clone failed doctor on Windows because of line endings alone.
Git for Windows enables core.autocrlf system-wide. EIF hashes generated
files as LF and records those hashes in committed state, and nothing told git
to keep them LF on checkout, so a clone failed the knowledge-index hash check
on content nobody had edited. Every instance now carries an EIF-managed
.gitattributes block covering the config, both locks, the agent entrypoint,
the knowledge index, and a workspace's content root. doctor also names that
case explicitly instead of reporting a hand-edit that never happened.

Two things that made a fleet unpleasant

A routine upgrade that resolved to identical provenance still rewrote
.eif/framework.lock.yaml to move its timestamp, and workspace freshness was
decided by the workspace's git HEAD rather than by resolved content.
Registering one more project therefore invalidated the pinned snapshot of
every already-connected project. Together they meant a fleet pass with
nothing to do still dirtied every repository with a diff that had no content
behind it, and that diff then blocked the next run on its own clean-tree
gate. Both axes are idempotent now.

Everything else

• A pre-existing workspace-runtime problem was reported as axis=framework
  and blocked the very step that would have repaired it.
• doctor ends with its own verdict line. The wrapped script printed "all
  checks passed" before the wrapper's own checks had run.
• projects upgrade reports change=yes or change=no per axis, and says
  plainly when there is nothing to apply.
• workspace doctor prints the registered projects and their machine-local
  mapping, which its own help already promised.
• Error messages name the next command: committing the registry after
  projects add, rebuilding the machine-local map on a second machine,
  re-materializing a workspace runtime, rehydrating a pinned runtime, and
  --allow-dirty-project on detach.
• The private-workspace suites that shipped in 0.2.0 were registered in no
  runner, so no workflow had ever executed them. They are in the inventory
  now, with a new suite covering the line-ending contract, lock idempotence,
  the positional init form, and content-based workspace freshness.
• Rollback has an order: the managed .gitattributes goes before anything is
  restored from git, because while it is present git materializes text files
  according to it.

What this release does not fix

scripts/tests/test_package_build.py fails three integration-status checks
against an installed wheel, on this release and on the v0.2.0 tag alike.
The doctor reports a configured Graphify provider as misconfigured rather
than reaching its degraded, healthy and RTK-canary states. It was reproduced
against the tag before being written down, so it is not a regression from
this release and it is not fixed by it. It went unnoticed because the
workflow that runs that suite is workflow_dispatch only and has no recorded
run. The other 72 checks in that suite pass, including the whole workspace
lifecycle from a built wheel.

The packaged integrations/vendor-docs/manifest.json also does not validate
against its own schema. Found during the same investigation, out of scope
here, and left alone rather than changed without evidence about which side is
wrong.

Install

Download the attached wheel and install the local file:

python -m pip install ./engineering_intelligence_framework-0.2.1-py3-none-any.whl
eifctl version

pip install engineering-intelligence-framework still does not resolve. The
package is not on PyPI.

Projects generated before 0.2.1 and already committed with converted line
endings need one normalization after the upgrade writes the new block:

git -C ../my-project add --renormalize .

Engineering Intelligence Framework v0.2.0

What's Changed

• feat(site): unify EIF social banners with the orbit figure by @mike-arbuzov365 in #32
• release: EIF 0.2.0 private workspace by @mike-arbuzov365 in #33

Full Changelog: v0.1.1...v0.2.0

v0.1.1 - Project lifecycle stabilization

What's Changed

• Align Ukrainian copy and terminology by @mike-arbuzov365 in #28
• docs: clarify Ukrainian hero promise by @mike-arbuzov365 in #29
• docs: clarify methodology and fallback copy by @mike-arbuzov365 in #30
• Release v0.1.1 project lifecycle stabilization by @mike-arbuzov365 in #31

Full Changelog: v0.1.0...v0.1.1

Engineering Intelligence Framework v0.1.0

Engineering Intelligence Framework v0.1.0 is the first public release of
the quality-first control plane for governed AI-agent software development.

Highlights:

• persistent, lifecycle-aware engineering knowledge and a four-axis authority model;
• bounded execution, evidence, Knowledge Delta, privacy, schema, and merge gates;
• a real eifctl package with seven commands;
• four supported adapters: Claude Code, Cursor, Codex, and Hermes;
• optional RTK, Graphify, and vendor-documentation integration contracts;
• English-canonical framework docs with Ukrainian project-facing surfaces;
• a bilingual, privacy-preserving GitHub Pages presentation site.

Verification on the release commit:

• framework inventory: 29/29 suites, 1449/1449 checks, exact machine-readable total;
• site gate: 20 unit, 83/83 e2e, 3/3 axe, Lighthouse 100/100/100/100;
• package release gate: wheel and sdist index-valid, wheel clean-installed, eifctl version returned 0.1.0;
• privacy scan: 0 unsuppressed findings; relative Markdown links: all resolved.

Artifacts:

• engineering_intelligence_framework-0.1.0-py3-none-any.whl
  • SHA-256: 1d2c9fa13351a229ee70dc878aabc8baf9bb1bddcd6be3bc66f13bdd1c879062
• engineering_intelligence_framework-0.1.0.tar.gz
  • SHA-256: c3adfa3b74705328fc2a20f2940950778c3220bbd178f0d0987dfd8725279e94

This release is not on PyPI. Install from the attached wheel or clone the
repository and run python -m pip install .. See CHANGELOG.md for the
complete feature inventory and explicit limitations.