Re-pin the indexing engagement on the version that can be installed

`1.0.0` declared the data layer as a dependency resolved through a path that
existed only in its author's working copy, so no application could install it --
not partially, but at the install itself, which is why none ever ran it. `1.0.1`
declares that package a PEER, supplied by the application. That is the shape that
makes a single verifier structural rather than something verified afterwards.

Nothing exported moved, which is what makes it a patch: the only thing that
changed for a caller is a requirement it could never have satisfied.

Two facts the new engagement adds, both worth having before wiring anything. The
package is published to no registry and distributed as TypeScript source, so
whatever builds the application compiles it -- our image installs from git and
Bun compiles at serve time, which fits, but a JavaScript-only toolchain could not
consume it. And `1.0.0` is superseded rather than withdrawn: the tag stays and
keeps resolving, because a pinned reference is never taken away from under a
consumer -- a policy the provider holds even for a version that never worked.

This commit is contained in:

Sylvain Duchesne

2026-08-17 12:26:21 +02:00

parent 279faa4541

commit 319e7082cc

2 changed files with 12 additions and 3 deletions

									
										.project/contracts.yaml
									
		+1
		-1
	
												View File
												
				@@ -42,4 +42,4 @@ consume:

				    pullFrom: https://gitea.reconnexion.apps.gueraud.net/Sylvain/ng-helpers.git/.project/concepts/indexing/indexing-layer/contract_indexing-layer.md

				    # Pinned on the TAG, never on a branch: a branch moves under us and the pin would stop

				    # naming a state anyone can go back to. Re-pin to the next tag at each upgrade.

				    ref: v1.0.0

				    ref: v1.0.1