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 .