Skip to content
Draft
26 changes: 26 additions & 0 deletions .agnir/evidence/2026-09-02-agnir-core-0.2-parallel-lineage.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
# Svif Agnir Core 0.2 parallel-lineage evidence — 2026-09-02

## Fork boundary

This source lineage is forked from coherent Svif validation checkpoint `329984f94483a7cbbb21a6faa42b9cf9ed84fed2`.

Project identity is preserved as `urn:svif:project:svif-core`.

The source branch establishes a different logical Continuity Lineage and VCS selector binding:

- lineage: `urn:svif:lineage:agnir-core-0.2-parallel`;
- selector: `refs/heads/feature/agnir-core-0.2-parallel`.

The fork does not reinterpret the Git ref name or commit SHA as lineage identity. The ref is a selector/binding; the commit is a revision receipt.

## Real Project divergence

This source lineage advances a real Svif contract in `spec/PROJECT_BINDING.md`: provider-local parallel continuity may bind multiple independently advancing continuity contexts to one stable Svif Project identity, while provider-specific lineage/selector configuration remains outside the provider-neutral Svif Orchestrator kernel.

The self-host test is generalized so it derives the currently selected lineage/selector from the Svif Project Binding and then verifies the real Agnir provider resolves the same logical lineage. This removes the previous target-lineage hard coding and makes the test valid for independently selected lineages of the same Project.

## Publication rule

The source fork must publish `AGNIR.yaml`, `SVIF.yaml`, source-local State / Next Actions, the real Project change, generalized self-host test, and this evidence in one coherent branch-advancing revision. The target validation lineage remains unchanged by this source checkpoint.

A later source→target integration must still stage the integrated Project result without moving the target ref, reconcile target continuity, then publish the integrated target and reconciled target continuity together.
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
# Svif Agnir Core 0.2 real-consumer validation complete — 2026-09-02

## Outcome

The first real Svif consumer validation of Agnir Core `0.2` / `repository-filesystem/0.2` completed on temporary branches without changing Svif `main`.

Project identity remained `urn:svif:project:svif-core`.

## Lineages and receipts

- common coherent baseline: `329984f94483a7cbbb21a6faa42b9cf9ed84fed2`;
- target lineage `urn:svif:lineage:agnir-core-0.2-validation`, selector `refs/heads/feature/agnir-core-0.2-validation`;
- target pre-integration revision `79c5b7c7ee2ed545492702bea43d0f7135602f35`, CI `33619053159` success;
- source lineage `urn:svif:lineage:agnir-core-0.2-parallel`, selector `refs/heads/feature/agnir-core-0.2-parallel`;
- source revision `d2d0c1bf25526b54490cce14c5aa8797c85c4d54`, CI `33618885830` success;
- unpublished staged candidate `4b86b3adafe08cc2f7fd48eb4f685d2b633b25c3`;
- reconciled two-parent target `1cd25539c75f8a2a32c84b822c0db80b176fd319`;
- semantic self-host test repair `e48ae07faa6a716f7e2cd83cdcefdce6d02d8c7e`, CI `33619491154` 3/3 success.

Target and source both made real, different Project changes. The staged candidate existed while fresh ref reads still showed the pre-integration target and source revisions. Its tree contained both Project changes but retained target lineage/selector binding.

The target ref then advanced once from `79c5b7c7...` directly to the reconciled two-parent revision `1cd25539...`; the staged candidate was never target truth.

## Verification finding

The first post-publication run `33619306602` had repository-integrity and portable-contracts green and one runtime failure caused only by a self-host test asserting an obsolete workflow-stage heading. Commit `e48ae07...` changed that test to assert stable binding-driven semantics. Run `33619491154` then passed all three jobs.

## Independent source resume

After target publication and repair, source ref still resolved to `d2d0c1bf...`. Fresh source `AGNIR.yaml` still resolved Project `urn:svif:project:svif-core`, source lineage `urn:svif:lineage:agnir-core-0.2-parallel`, and the parallel selector. Source-local State remained intact.

## Validated semantics

The real Project validates explicit 0.1→0.2 migration, two independent lineages, lineage/selector/revision separation, binding-driven discovery, lineage-local checkpoints, staged integration without target publication, target reconciliation before publication, coherent target advancement, and independent source survival. Svif's generic Orchestrator remained Continuity-Provider-neutral.

This evidence does not migrate Svif `main`, change released `v0.2.0-preview.1`, or publish Agnir Core `0.2`; it is input to Agnir release readiness.
107 changes: 107 additions & 0 deletions .agnir/evidence/2026-09-02-agnir-core-0.2-real-consumer-validation.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,107 @@
# Agnir Core 0.2 real-consumer validation — Svif — 2026-09-02

## Authorization and scope

The Principal authorized continuing Agnir Core `0.2` work and using Svif as the first real consumer validation. Evidence is carried on temporary Svif branch `feature/agnir-core-0.2-validation`; authoritative Svif `main` remains unchanged during the experiment.

Source baseline:

- Svif `main`: `dac058789a27f32f4ed1949874c1954f31f12bd8`;
- Project identity: `urn:svif:project:svif-core`;
- baseline Agnir Core/profile: `0.1` / `repository-filesystem/0.1`;
- baseline stable Agnir operational release: `v0.1.1` at `e9712357ab590e5c1e5357b3cf3219d07d789aff`.

Experimental Agnir source:

- repository: `iorLab/agnir`;
- branch: `feature/core-0.2-lineage`;
- checkpoint revision: `414dba1e50ad1bdcae3ca91d19c6768fdaa030cc`;
- Core/profile candidate: `0.2` / `repository-filesystem/0.2`.

## Explicit Project migration

The validation branch migrates its provider-owned `AGNIR.yaml` explicitly rather than treating the Core-line change as a compatible upgrade.

Selected migrated binding:

- Project identity: `urn:svif:project:svif-core` (preserved);
- logical lineage: `urn:svif:lineage:agnir-core-0.2-validation`;
- VCS selector: `refs/heads/feature/agnir-core-0.2-validation`;
- existing State / Next Actions / Decisions / Evidence locators: preserved.

`SVIF.yaml` constrains the founding Agnir Continuity Provider to compatibility `0.2`, profile `repository-filesystem/0.2`, and matching provider-specific lineage/selector configuration.

## Real consumer implementation pressure

The pre-validation Svif `AgnirFilesystemContinuityProvider` hard-coded Agnir Core/profile `0.1`. The real consumer therefore required an adapter change, not just manifest edits.

The candidate adapter:

- preserves Core/profile `0.1` support;
- recognizes Core/profile `0.2` as a distinct supported compatibility line;
- requires `continuity.lineage` on Core `0.2`;
- keeps logical lineage identity distinct from VCS selector binding;
- optionally constrains expected Core/profile from the Svif binding;
- fails explicit selected-selector binding absence/mismatch rather than guessing;
- records the resolved Agnir lineage in Svif runtime checkpoint evidence;
- keeps the generic Svif Orchestrator interface unchanged.

Focused tests cover Core `0.2` discovery, binding mismatch/absence, compatibility mismatch, lineage requirement, and lineage-preserving checkpoint behavior while retaining Core `0.1` cases.

## Draft PR and first CI pressure

Svif Draft PR `#3` was opened from `feature/agnir-core-0.2-validation` to `main` only to exercise the real repository checks. The PR body explicitly states that green initial CI is not sufficient for merge.

First migration commit:

- `52c1e7c37c1678fd848c6a0ef1e9b36fedd3ce18` — `test: migrate Svif validation branch to Agnir Core 0.2`.

CI run `33615826969` returned:

- `portable-contracts`: **success**;
- `repository-integrity`: **failure** because the checker hard-coded `version: "0.1"` / `repository-filesystem/0.1`;
- `runtime-kernel`: **failure**, but every newly added Core `0.2` adapter test passed. Three old tests failed because two hard-coded the current Project binding as `0.1` and one expected still-valid release/public-distribution markers that had been dropped from the branch-local Next Actions rewrite.

This was useful real-consumer evidence: the provider adapter itself handled Core `0.2`, while Project-level checks and continuity preservation still encoded single-compatibility assumptions.

## Non-weakening repair

Repair commit:

- `891cbc4d980b90f86992bd2f3a48e326d49b505a` — `fix: preserve Svif gates across Core 0.2 migration`.

The repair did not add historical `0.1` marker comments to trick string tests and did not skip repository-integrity. Instead:

1. `checks/check_repository.py` now parses the current Agnir/Svif scalar binding and verifies coherence. It accepts only supported Core/profile pairs (`0.1`/`repository-filesystem/0.1` or `0.2`/`repository-filesystem/0.2`), requires Svif compatibility/profile to match Agnir, and for Core `0.2` requires matching logical lineage and selector binding while rejecting selector==lineage identity.
2. Plugin/discovery tests distinguish two legitimate layers: the current selected Project may be explicitly migrated to experimental Core `0.2`, while the released Skills-only first-use bootstrap remains on its published Core/profile `0.1` baseline until an intentional distribution release changes it.
3. `.agnir/next-actions.md` restores still-valid `v0.2.0-preview.1`, Codex CLI, ChatGPT desktop/Codex, immutable candidate, universal Plugins Directory, ChatGPT Web, and public/personal ChatGPT path work instead of erasing those obligations just because the active lineage focuses on Core `0.2`.

## Green migrated baseline

Follow-up CI run **`33616508143` completed successfully** on the repaired migrated branch:

- `repository-integrity`: success;
- `portable-contracts`: success;
- `runtime-kernel`: success.

This proves that the real Svif Project can consume the experimental Agnir Core/profile `0.2` binding without weakening the product's portable contracts, Plugin packaging/distribution checks, or existing Core `0.1` adapter/bootstrap coverage.

## Fresh real-Project discovery checkpoint

The next checkpoint adds `tests/test_agnir_core_0_2_self_host.py`, which loads the actual Svif repository root through the real `AgnirFilesystemContinuityProvider` with explicit Core/profile `0.2` and selector context. It verifies Project identity, logical lineage, and recovery of the real branch-local State / Next Actions / Evidence.

The checkpoint also records run `33616508143` in branch-local State and preserves the complete release/distribution worklist. This creates the coherent source baseline from which a second logical lineage can be forked.

## Remaining acceptance sequence

Real-consumer validation is not complete until:

1. the self-host checkpoint CI is green;
2. a second temporary branch is explicitly forked into a different logical lineage with the same Project identity;
3. source and target lineages diverge and checkpoint independently;
4. staged integration leaves the target ref unchanged while unreconciled;
5. target continuity is reconciled before target publication;
6. integrated target + source both fresh-resume coherently;
7. final evidence is fed back into Agnir Core `0.2` release readiness.

No merge to Svif `main`, no stable Core `0.2` success claim, and no Agnir `v0.2.0` release claim should be made before that sequence is observed.
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
# Svif Agnir Core 0.2 reconciled integration evidence — 2026-09-02

## Scope

This evidence records the first real Svif two-lineage integration under the Agnir Core `0.2` candidate.

Project identity throughout: `urn:svif:project:svif-core`.

Target lineage:

- logical lineage: `urn:svif:lineage:agnir-core-0.2-validation`;
- selector: `refs/heads/feature/agnir-core-0.2-validation`;
- pre-integration revision: `79c5b7c7ee2ed545492702bea43d0f7135602f35`;
- CI run: `33619053159` — repository-integrity, portable-contracts, runtime-kernel all success.

Source lineage:

- logical lineage: `urn:svif:lineage:agnir-core-0.2-parallel`;
- selector: `refs/heads/feature/agnir-core-0.2-parallel`;
- revision: `d2d0c1bf25526b54490cce14c5aa8797c85c4d54`;
- CI run: `33618885830` — repository-integrity, portable-contracts, runtime-kernel all success.

Common coherent baseline: `329984f94483a7cbbb21a6faa42b9cf9ed84fed2`.

## Independent divergence

The lineages advanced independently from the common baseline.

Target changed `ARCHITECTURE.md` and target-local continuity. Source changed `spec/PROJECT_BINDING.md`, generalized lineage/binding tests, and source-local continuity. The source and target therefore exercised real, non-identical Project work rather than merely changing lineage labels.

## Staging without target publication

A staged integration tree was built from the target tree plus source Project/test changes while deliberately retaining target `AGNIR.yaml`, target `SVIF.yaml`, and target continuity as the provisional target context.

Unpublished two-parent staged candidate:

- `4b86b3adafe08cc2f7fd48eb4f685d2b633b25c3`;
- first parent: target `79c5b7c7ee2ed545492702bea43d0f7135602f35`;
- second parent: source `d2d0c1bf25526b54490cce14c5aa8797c85c4d54`.

After creating the candidate, fresh ref reads still observed:

- target ref → `79c5b7c7ee2ed545492702bea43d0f7135602f35`;
- source ref → `d2d0c1bf25526b54490cce14c5aa8797c85c4d54`.

This proves the integration candidate existed without advancing the target publication boundary.

## Candidate content verification

The staged candidate was inspected directly and showed both Project changes:

- target Continuity Provider architecture text in `ARCHITECTURE.md`;
- source provider-local parallel-continuity contract in `spec/PROJECT_BINDING.md`.

Its `AGNIR.yaml` still exposed target lineage `urn:svif:lineage:agnir-core-0.2-validation` and target selector `refs/heads/feature/agnir-core-0.2-validation`; source lineage/selector metadata was not copied into target binding truth.

## Reconciliation

The final target continuity is reconciled from:

1. actual integrated Project candidate;
2. previous target continuity;
3. relevant source continuity and source evidence;
4. the Principal-authorized real-consumer validation intent;
5. observed source/target CI and ref stability.

The reconciled target records both Project changes and the integration receipts while preserving target logical lineage identity and selector binding. The source lineage remains independently resumable and is not collapsed into target continuity.

## Publication requirement

The final target revision must use the same two parents as the staged candidate but a tree containing reconciled target continuity and this evidence. Only that final revision may advance `feature/agnir-core-0.2-validation`.

The staged candidate itself is evidence, not authoritative target truth.

After publication, full target CI and fresh target/source resume are still required before this real-consumer validation is considered complete.
17 changes: 17 additions & 0 deletions .agnir/evidence/2026-09-02-agnir-core-0.2-target-divergence.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
# Svif Agnir Core 0.2 target divergence evidence — 2026-09-02

## Target-only advancement

Target lineage `urn:svif:lineage:agnir-core-0.2-validation` on selector `refs/heads/feature/agnir-core-0.2-validation` advances independently from common checkpoint `329984f94483a7cbbb21a6faa42b9cf9ed84fed2`.

Project identity remains `urn:svif:project:svif-core`.

The target-only real Project change updates `ARCHITECTURE.md`: the generic Svif Orchestrator consumes an already selected continuity context and must not enumerate sibling provider contexts, infer Project identity from provider-local lineage/selector/revision metadata, or silently switch contexts when selection is unresolved.

The source lineage remains a separate continuity line and carries a different real Project change in `spec/PROJECT_BINDING.md`. No source continuity or source selector metadata is published as target truth at this checkpoint.

## Integration precondition

This target checkpoint is accepted only after its product CI and fresh target self-host discovery pass. Staged source→target integration may begin only when the source lineage is independently green as well.

At staging time the target ref must remain at this pre-integration checkpoint until target continuity has been reconciled against the actual integrated Project candidate, previous target truth, relevant source continuity/evidence, and Principal intent.
Loading
Loading