STE-Code REPOSITORY v1.2.0

STE-Code REPOSITORY v1.2.0

Tag family. REPOSITORY-v1.2.0 versions the repository - the development
machinery, agent confinement, the benchmark harness, and the root tooling. It
does not version the STE-Code standard. STANDARD-1.1.0 remains the
version of the standard and is unchanged by this release. No STANDARD-* or
FLAVOR-* tag is moved or created here.

Scope of this release. All measurements in this note are taken at the tag
commit 0c510d3. The working tree at research time (f6a505a) was two
commits past the tag and is out of scope; the figures are measured from the
tree at the tag, not read from HEAD.

Headline stats (all at 0c510d3)

Metric	Value
Tag	REPOSITORY-v1.2.0
Range	STANDARD-1.1.0..REPOSITORY-v1.2.0 (tag commit 0c510d3)
Tip commit	0c510d3
Standard version	STANDARD-1.1.0 unchanged
Files changed (release range)	387
Insertions / deletions	+22,752 / −24,783
Net line change	−2,031
Commits in range	182 (180 non-merge + 2 merge: 4a66bee, d40ac8a)
ste-code/ impact	3 files, +9 / −8 (editorial only)
Files deleted in range	86
README.md files added	24 (all under .agents/)
Skill renames	19
Core shared lib modules	9 (of 24 .py files total in tools/lib/)
Absolute machine paths in skill front-matter	22
Adapted rule files	54 rules + 4 GR (+ dictionary + categories = 60, plus expanded/)
Empty commit subject	3ed5631 ([])

Every row above is measured across the release range at the tag commit
0c510d3; none is read from the working tree at f6a505a or from HEAD.

This is a repository release

REPOSITORY v1.2.0 strengthens the machinery that builds, tests, and maintains
STE-Code. It does not change the STE-Code standard.

The canonical adaptation remains at STANDARD-1.1.0. The 54 rules, the
dictionary-derived guidance, the categories, and the published level artifacts
remain unchanged for consumers - git diff --stat across the release range for
ste-code/artifacts/ is empty, so no artifact tier was rebuilt. Changes under
ste-code/ are limited to 3 files / +9 / −8 of editorial and linguistic
consistency corrections (including a documented deploy noun-form consistency
correction that preserves deploy as the accepted noun form in the adapted
terminology); no artifact tier was rebuilt.

This release is about making the repository more disciplined in three ways:

1. shared infrastructure replaces repeated local implementations;
2. development agents receive clearer boundaries and stronger confinement;
3. the benchmark becomes more honest about what it observed, what it inferred,
   and what it only simulated.

The result is not "a finished self-improving benchmark." It is a stronger
foundation for one.

The central theme: make hidden assumptions explicit

Earlier repository machinery often relied on conventions:

• scripts independently found the repository root;
• scripts wrote files through their own local helpers;
• agent profiles carried overlapping skills;
• benchmark sentinels could signal completion before proving useful work;
• a driver requested a live run while downstream stages could still be forced
  into offline mode.

v1.2.0 moves these assumptions into shared code, explicit status records,
confined write paths, and documented operating modes.

The release therefore adds substantial infrastructure, but its most important
work is corrective: it makes it harder for the toolchain to report success that
it did not measure.

Shared repository infrastructure

The .agents/tools/lib/ library is now the common foundation for repository
tools, built around nine core shared modules (the directory also holds
additional helpers and tests for a total of 24 .py files, but these nine are
the maintained core family): repo_root, ste_io, ste_config, ste_runtime,
ste_paths, ste_time, ste_retry, ste_cli, and ste_checkpoint.

Those nine modules provide reusable components for:

• repository-root discovery (repo_root);
• confined file input and output (ste_io);
• per-unit configuration (ste_config);
• runtime option resolution (ste_runtime);
• virtual-environment and wrapper paths (ste_paths);
• timestamps (ste_time);
• retries (ste_retry);
• common command-line flags (ste_cli);
• resumable checkpoints (ste_checkpoint).

This replaces repeated root derivation, repeated configuration literals, and ad
hoc file-writing patterns across the toolchain. The immediate benefit is
consistency: a tool no longer needs to decide independently where the repository
is, where it may write, or how it should load its defaults.

The migration is intentionally incomplete rather than falsely declared finished.
Some scripts still use direct write calls outside the shared file-I/O funnel.
The repository now documents this honestly: confinement is strongly encouraged
and increasingly adopted, but it is not yet a universal invariant.

A more confined agent environment

v1.2.0 introduces a tracked Hermes jail and three purpose-specific profiles:

• dev-ste-code for repository authoring and maintenance;
• ste-code for applying the methodology as a consumer;
• benchmark-ste-code for benchmark and adversarial work.

The profiles load different skill sets from one canonical source:
.agents/skills/. Skills are linked rather than copied (the link unit is the
skill group, not the skills/ directory itself), so profile-specific
capabilities do not drift from their maintained source. Each profile also
carries a .no-bundled-skills marker so Hermes' own bundled skills do not mix
into the canonical set. The subsets genuinely differ: dev-ste-code gets four
groups, benchmark-ste-code and ste-code each get one.

The jail applies layered controls to file writes, shell commands, network
access, delegation paths, and opaque subprocesses. The restrictive user and
benchmark profiles use an additional kernel-backed confinement layer where
available - its policy set (WRAPPED_POLICIES = {"user", "bench"}) lives in
jail-exec-wrap/__init__.py, and an unknown profile falls back to the stricter
benchmark policy (_STRICT_FALLBACK = "bench") rather than receiving permissive
access. The profile control surface is a deny list (PROFILE_CONTROL_SUBDIRS:
config.yaml, jail.yaml, hooks, plugins, skills, memories, cron,
auth.json, .env, hermes.db, commands, agents), and the benchmark
profile re-denies that same surface inside its own writable home so a benchmark
session cannot rewrite its own config.yaml to disable the jail. Resolution is
most-specific-match-wins, so a nested writable tree (such as
.agents/benchmark/) still wins over a broader denied root.

This is not a claim that every repository write is now impossible to misuse. It
is a practical boundary: a benchmark session should not be able to rewrite its
own profile, disable its own controls, or write outside its intended workspace
through an ordinary tool path.

The benchmark records its evidence

The benchmark has grown from a simple scorer into a five-colour developmental
harness (each module's docstring matches the roles below):

• RED generates deterministic adversarial cases;
• BLUE builds and evaluates defensive probes;
• WHITE aggregates observations into remedy hypotheses;
• BLACK challenges the harness's conclusions;
• PURPLE stitches RED and BLUE activity into a shared view.

The colours communicate through persisted records and bounded filesystem
sentinels. A missing signal produces an explicit timeout or deferred state
rather than an indefinite wait - BLUE polls RED's purple.json up to a bounded
--await-timeout and records a deferred state if it never appears; BLACK never
awaits another process past a bounded timeout.

The most important benchmark changes are about status honesty.

No work is not a passing result

BLUE now records no-escape ("status": "no-escapes", with empty residual and
resistance tables) and deferred ("status": "deferred" when a round produced no
probes - explicitly not a successful defense) rounds. RED and PURPLE sentinels
distinguish generated work from model-scored work (model_scored, scored,
simulated, mode keys; the pass rate is None unless something was actually
scored). Offline-derived pass values come from a deterministic resistance table
(_offline_resistance(), computed with no model call from the escape records
themselves) rather than being treated as unexplained success.

These changes remove an earlier ambiguity in which an empty or incomplete round
could appear more successful than the evidence justified. The fix is guarded by
self-tests that assert blue_passed matches table and
blue_passed is not falsely zero - the exact bug class the story describes.

Live mode now reaches downstream stages

Previously, the pipeline driver could be invoked as live while BLUE, WHITE, and
BLACK were still given --skip-live internally. That meant a run could look
live at its entry point while substantial downstream work remained offline.

v1.2.0 corrects that propagation. The flag is now derived from the driver's own
state - run_pipeline.py builds
skip = ["--skip-live"] if args.skip_live else [] and threads it, plus
live = [] if args.skip_live else ["--model", args.model], into every
downstream stage, persisting skip_live into the run record. A downstream phase
is forced offline only when the driver itself is offline.

This is an implementation repair, not evidence that a full live benchmark run
has already succeeded. No live scored benchmark result is published by this
release. The next validation step is to capture a minimal live run that proves
the complete chain from a RED case, through target execution and evaluation, to
an evidence-linked terminal record.

RED can publish a ledger before model scoring

RED now writes an escape ledger even when it runs in emit-only mode. The ledger
records that its cases were generated rather than model-measured: it carries
"generator": "RED", model_scored: False, and
"escape_source": "model-run" if model_scored else "generated", and an
emit-only round is explicitly marked as publishing a GENERATED ledger.

That distinction matters because generated cases are useful pipeline inputs, but
they are not proof of model failure or model resistance. Downstream code can now
see the difference instead of treating an absent ledger and an empty attack
surface as the same event.

Feedback is explicit

BLACK-confirmed defended technique/placement pairs can be persisted to
excluded_pairs.json and passed back to RED via --exclude-pairs for later
cycles (the file is written every cycle, including empty, so RED always has
something to read; the round-trip is verified end to end). This allows the
harness to reduce repeated work against attack cells already marked as defended
under its declared policy.

The resulting coverage value is a scheduling and progress signal. It is not a
general proof that an artifact is robust, that an attack family is exhausted, or
that the benchmark has achieved empirical convergence. A technique and placement
pair is coarser than the full space of natural-language adversarial inputs. The
closure calculation reads the pair space dynamically from RED
(_red_pair_space()), currently 80 technique×placement pairs with a
documented 10×8 fallback if RED cannot be imported, and signals RED-obsolete
at a 0.95 coverage threshold (RED_OBSOLETE_COVERAGE).

What the benchmark can claim now

At this release, the benchmark can claim that it has:

• deterministic adversarial-case generation;
• explicit offline versus generated versus model-scored provenance in key
  records;
• bounded sentinel-based orchestration;
• a corrected live/offline flag path;
• an append-only knowledge representation;
• a feedback mechanism for previously defended attack cells;
• self-tests for many pipeline and status-handling conditions.

It cannot yet claim that it has:

• demonstrated a complete live end-to-end evidence chain;
• measured a published benchmark score;
• proved model resistance;
• proved an artifact improvement;
• performed a paired control-versus-candidate artifact experiment;
• automatically promoted an artifact change.

Those are deliberately separate future milestones.

A more reliable repository layout

Run state, benchmark output, temporary files, audit reports, and generated
machine-local artifacts are no longer treated as repository content, and 86
files were deleted from version control in the release range as a result. The
repository now ignores their ephemeral outputs while keeping an explanatory
README for the directories that still need one - but the pattern is not
uniform across all four:

• .agents/state/, .agents/tmp/, and .agents/benchmark/tests/ each keep a
  README via a !…/README.md negation;
• .agents/audit/ and ste-code/audit/ are ignored wholesale with no README
  exception.

So the "keep the README" behaviour holds for three of the four directory
families, not all of them. The statement is precise: ephemeral outputs are
ignored; a README is preserved only where the ignore rule grants it.

This makes a checkout easier to inspect: committed files describe source,
policy, tools, tests, and documentation; local run directories describe one
machine's execution and are not mistaken for durable project truth.

Documentation also moves closer to the code it describes. The 24 README.md
files added in the range (all under .agents/) give individual tool units a
local README, while the documentation site keeps the larger architectural view.

Known limitations

This release intentionally records unresolved work, and follows the
contradictions it set out to resolve. Each item below is tagged RESOLVED
(ship-stop bug class fixed in this release) or OPEN (still outstanding, or
flagged for later review).

Contradictions resolved (repository view)

Item	Status	Evidence
Harness false-success ambiguity	RESOLVED	RED/BLUE distinguish generated from model-scored (model_scored, scored/simulated/mode); offline pass values from a declared resistance table; self-tests assert blue_passed matches table and blue_passed is not falsely zero
Live-run forced-offline	RESOLVED	--skip-live derived from driver's flag (run_pipeline.py: skip = ["--skip-live"] if args.skip_live else []); a live entry point no longer silently leaves downstream offline
Research-number and editorial corrections	RESOLVED	notes cite git-exact measurements at 0c510d3; adapted terminology preserves deploy as the accepted noun form
Merge re-introducing a lump commit	OPEN	a merge in the range re-introduced a large lump change; history should be reviewed before relying on automated changelog generation
Absolute paths in skill source (22)	OPEN	22 absolute machine paths (/Users/nikola/…, /Volumes/CORSAIR/…) remain in source: front-matter across .agents/skills/**/SKILL.md
Write gate incomplete	OPEN (partial)	shared write funnel not yet universal; some direct open(...,"w") writes remain under .agents/
Non-conventional and empty-subject commits	OPEN	history contains 3ed5631, whose commit subject is genuinely empty ([])

Outstanding behavioural limitations

The benchmark's live route is implemented but has not yet been demonstrated
through a captured, scored live run in this release. Current benchmark processing
is not yet a paired experiment between a frozen control artifact and a candidate
artifact. WHITE remedies are proposals and must not be treated as applied
artifact changes or as approved improvements without explicit human review and
later paired evidence.

Next milestone

The immediate next milestone is intentionally narrow:

1. run one bounded live benchmark cycle;
2. prove that a RED-generated input is the exact input consumed by target
   execution;
3. record the model configuration, artifact identity, output, and evaluation;
4. ensure no simulated or deferred record can be interpreted as measured;
5. preserve the canonical standard and published artifacts throughout.

Only after that evidence chain is proven should the project add a paired
control-versus-candidate experiment for optimizing LLM-facing artifact wording.

Migration notes

After cloning or updating, the steps are:

make skills-link
make skills-check
make check

make check now includes the jail test suite. The jail target verifies that
the covered write-confinement escape cases are blocked; it does not make the
shared write gate universal. release-check is a separate target and is
deliberately not a prerequisite of check. Benchmark output, temporary state,
and local run records are intentionally ignored and should remain out of version
control.

A live benchmark invocation incurs model calls, rate limiting, and cost; using
the scheduler with a bounded run configuration is expected. A run without
--skip-live propagates live mode to downstream phases rather than forcing them
offline; v1.2.0 does not include a captured scored live run, so any future
result is measured only when its output records prove the complete evidence
chain.

Version boundary

• REPOSITORY-v1.2.0 versions repository infrastructure and development
  machinery.
• STANDARD-1.1.0 remains the version of the STE-Code standard.