STE-Code REPOSITORY v1.3.0

STE-Code REPOSITORY v1.3.0

Tag family. REPOSITORY-v1.3.0 versions the repository - .agents/, the
root tooling, and the Makefile. 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. The range holds 69 commits, of which nine are the
security-audit work. The large diff below is dominated by a repo-wide
formatter and line-ending normalisation pass, not by security hardening -
the 594-file figure describes the whole range, not the audit.

Headline stats (all at 6dc5e4e)

Metric	Value
Tag	REPOSITORY-v1.3.0
Range	REPOSITORY-v1.2.0..HEAD
Base commit	0c510d3
Tip commit	6dc5e4e
Wall-clock span	~13h 21m, same day
Commits in range	69 (68 non-merge + 1 merge)
Files changed (release range)	594
Insertions / deletions	+35,530 / −14,791
Dominant contributor to that diff	repo-wide prettier/Markdown reformat + .gitattributes LF pass
Security-audit commits within the range	9
Benchmark self-test	181 → 202 checks (+21 capsule checks)
make check at HEAD	202/202, all policies pass (dev, user, bench)
New NETWORK_COMMANDS entries	9
Fuzz corpus seed	DEFAULT_FUZZ_SEED = 7
Absolute machine paths in skill front matter	0 (was 22 - closes a v1.2.0 OPEN item)
Standard version	STANDARD-1.1.0 unchanged

Test counts and policy results are facts at HEAD, not range measurements.
Every other row is measured across the release range.

This is a repository release

REPOSITORY v1.3.0 is a maintenance and hardening release for the machinery that
builds, tests, and confines STE-Code work. It does not change the STE-Code
standard.

The release does four things:

1. it closes a set of jail and benchmark audit findings;
2. it introduces a formatting toolchain and applies it across the repository;
3. it grows the hook suite and adds a confined child launcher for benchmark
   work;
4. it closes one release-hygiene item carried over from v1.2.0, and records one
   that regressed.

Most of the commits in the range belong to items 2 and 3. Most of the risk
reduction belongs to item 1.

Security audit

Nine commits in the range are audit work: e731f5b, 05400b5, c4f5767,
678cd39, b8cfa8d, 5338c46, 07b5561, 509f85d, 6dc5e4e.

I1 - the jail fails closed

e731f5b makes the jail plugin refuse rather than pass when it cannot judge a
call. _build_chain() now tracks missing components, and a hook-to-component
map lets a refusal name the component that failed to load. If the plugin cannot
load its chain, register still registers - but it registers a refusal hook
that blocks every tool call. Both failure paths are closed: a jail that cannot
judge a call refuses it. Guarded by 6/6 fail-closed checks in the jail suite.

B3 - new escalation tools are denied by default

678cd39 replaces a hardcoded bench deny list with a subtraction:

BENCH_ALLOWED_ESCALATION_TOOLS = frozenset({"delegate_task", "cronjob"})
denied_tools = NETWORK_TOOLS + [
    t for t in ESCALATION_TOOLS if t not in BENCH_ALLOWED_ESCALATION_TOOLS
]

The effective set is byte-equivalent to the previous one. The value is
anti-fail-open behaviour for future additions: a newly added escalation tool
is denied in the bench policy unless it is explicitly allowed. Guarded by 6/6
bench-escalation checks.

Attribution note. 678cd39 carries this code. Its sibling b8cfa8d has a
commit message describing the same change but a diff that does not contain it;
the two branches were developed in parallel and reconciled by a merge. Cite
678cd39 for B3.

B2 - modern package runners are blocked

07b5561 adds nine entries to NETWORK_COMMANDS: nix, guix, pipx, uvx,
uv, poetry, npx, bunx, deno. Matching is per command word, so
pnpm dlx and cargo install are already covered by the existing pnpm and
cargo denials. Guarded by 27/27 package-runner checks.

C2′ - the fuzz corpus is reproducible

509f85d gives the corpus generator DEFAULT_FUZZ_SEED = 7, threaded through
the generator constructor, its run loop, and the CLI. The previous behaviour
seeded from OS entropy, which made a corpus impossible to reproduce. The
effective seed is now written into the corpus header record, so a corpus states
the seed that produced it. Guarded by 4/4 fuzz-determinism checks.

C4′ - the capsule scheduler is tested

6dc5e4e adds capsule-scheduler tests to the benchmark self-test: missing
dependencies, escape-set scoping, a capsule with no sees, a capsule whose
dependency has no escapes on disk, multi-document YAML, and malformed YAML. The
self-test goes from 181 to 202 checks; the 21 new checks cover the
capsule scheduler.

The self-test counts in this note are measured at the tip, not taken from commit
messages: four commits in this range assert "make check 180/180", but the value
immediately before the capsule commit was 181.

D4 - the hook directory repairs itself safely

05400b5 gives link-hooks.sh classification predicates and a prune step.
--force never blind-deletes: it removes an entry only when that entry is
positively classified as disposable - a retired hook, a symlink into the
canonical source, or a stale copy of a canonical hook. When checksum comparison
cannot classify an entry, the script refuses instead of guessing.

Vocabulary scripts - a bug fix as well as a privacy fix

5338c46 replaces a hardcoded absolute JSON path in four vocabulary scripts
with a path derived from the script's own location. The commit's own message
records that the hardcoded path did not exist in this checkout, so those
scripts were provably non-functional before the fix, not merely leaking a local
path. This is a bug fix and a privacy fix, not path hygiene.

Test results

Suite / group	Result
make check total	202/202
Benchmark self-test	202/202 (was 181)
I1 fail-closed	6/6
B3 bench escalation	6/6
B2 package runners	27/27
C2′ fuzz determinism	4/4
Policy suite	dev, user, bench - all pass

The jail-suite groups are reported per group by the jail tests. They are not a
subset of the 202 and must not be added to it.

Tooling and formatting

The largest share of the range is a formatting programme, not a feature.

• A prettier-based format toolchain lands under .agents/format/: Format.sh,
  Markdown.py, prettier.config.js, .prettierignore, and .editorconfig.
• A repo-wide Markdown structural reformat pass (051788a) runs across
  ste-code/ and .agents/.
• .gitattributes enforces LF line endings (11e62a2).

This is what produces the headline diff. Files across .agents/benchmark/
show near-symmetric insert/delete profiles characteristic of reflowing rather
than of behaviour change - a documentation or configuration file that reports
several hundred changed lines with no functional delta is a formatting
signature.

The 594-file, +35,530 / −14,791 diff describes the whole range, whose majority is
the formatter and LF pass; the audit is nine commits inside that range, and its
diffs are small and targeted.

ste-code/ is touched in this range, unlike in v1.2.0 where it was near-zero.
The changes appear under ste-code/grouped/, ste-code/linguistics/, and
ste-code/templates/, and are consistent with the formatter pass. This note
does not repeat v1.2.0's claim that no artifact tier was rebuilt:
ste-code/artifacts/ was not measured separately for this release, so that
claim is not carried forward.

Hooks and confinement

• The hook suite grows: memory anonymisation, command scrubbing, shared hook
  helpers, prompt context, post-edit format QA, and a self-QA check, together
  with the link-hooks.sh and install.sh wiring described under D4.
• A confined child launcher for benchmark work lands alongside the benchmark
  runner and its lockdown documentation.
• Privacy-scrub jail plugins, a skills reorganisation, and memory and USER
  document rewrites round the programme out.

Narrow the confinement claim. The jail suite verifies that the covered
write-confinement escape cases are blocked. It does not make the shared write
gate universal - direct write calls outside the shared funnel remain, and that
v1.2.0 item is still ...

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...

STE-Code REPOSITORY v1.1.0

STE-Code REPOSITORY v1.1.0

Tag family. REPOSITORY-v1.1.0 versions the whole repository build-out —
benchmark, tooling, model config, skills, the scripts/→tools/ migration,
and hygiene. It does not version the STE-Code standard; the companion
STANDARD-v1.1.0 covers only the wording (rules, categories, dictionary,
levels, FLAVOR), and no STANDARD-* or FLAVOR-* tag is moved or created
here.

Scope of this release. All measurements below are taken at the release tag
commit 830d06c (v1.1.0 = STANDARD-1.1.0 = REPOSITORY-1.1.0), not
at any later HEAD. Post-tag commits are out of scope.

Headline stats (all at 830d06c)

Metric	Value	Note
Files changed (0cf59e4..830d06c)	2,605	rename-aware (diff.renameLimit=3000); the 2,622 figure is the rename-unaware count
Lines	+319,500 / −158,750	rename-aware; identical ±3,077 delta on both sides is moved-file detection
Commits	432 (430 non-merge + 2 merge)	the range; 591 is all history behind the tag, not this release
ste-code/ impact	1,061 files, +269,168 / −98,217	exact match, confirmed
Standard rule count	54 rules + 4 GR = 58	was 51+4=55 at v1.0.0; +3 rules (wording story in STANDARD-v1.1.0)

This is a repository release

REPOSITORY v1.1.0 is a build-out release for the machinery that builds, tests,
and benchmarks STE-Code work. It does not change the STE-Code standard — the
companion STANDARD-v1.1.0 carries that story. The release brings the benchmark
into existence, completes the scripts/→tools/ migration, settles the default
model indirection behind STE_MODEL, and reorganises skills and the merge
stage.

The benchmark was born here

REPOSITORY-v1.1.0 is where the STE-Code benchmark comes into existence. At the
tag, .agents/benchmark/ holds 35 tracked files and three colour-named engines
are present:

• RED — a deterministic adversarial test-case generator (adversarial.py,
  build_red_cases(tier, per_technique, seed)). Per its own header, RED cases
  are "pure seeded transforms, no LLM" — fast and reproducible, with an
  LLM-driven "novel escape" round explicitly deferred to later.
• BLACK — a split-half A/B verifier (verification.py, black.py). Splits
  are hashed with blake2s over the case id, never random.shuffle, so the
  partition is reproducible without storing it; it implements Partition plus
  stratified / axis / temporal / variant-holdout split strategies and a
  degeneracy check.
• PURPLE — purple.py / purple_stitch.py, which stitch RED and BLUE
  activity into a shared view.

These are real, substantial modules (b90aa59, 1aa19e7, 10d3cab), and the
corpus they score was also established here: 59 cases across 14 categories
(category-1-readme … category-14-gen-readme; categories 9–14 are the gen-*
generation set), with a control-group orchestrator (orchestrator-control.py)
running the same cases against a plain assistant.

The benchmark numbers the project quotes today were set in this release. As
recorded in AGENTS.md at the tag: STE-Code scored 96.6 % (57/59) pass rate
and 0.919 average, versus the control group's 11.9 % (7/59) and
0.471. These scores are read from AGENTS.md at the tag, not re-run by
this release; treat them as attributed, not independently asserted. The corpus
size (59 cases, 14 categories) was verified directly; the scores were not.

Framing boundary — born, not hardened. The five-colour architecture, the
WHITE remedy layer, the run_pipeline.py driver, and the entire
status-honesty rewrite are v1.2.0, not this release. At 830d06c only
RED, BLACK, and PURPLE exist as modules; there is no red.py,
blue.py, or white.py and no run_pipeline.py. Do not read
"five-colour", "WHITE remedy", or "honesty" framing back into v1.1.0.

The migration landed, then the repo spent weeks repairing it

The scripts/ → tools/ migration is the structural headline of the repository
side: 184a798 ("migrate scripts/ into tools/ hierarchy"), 1e47fd7 ("move
scripts to tools, fix all path references, add docs"), and 9485865
("reorganize into hierarchical directory structure") fold the legacy scripts/
tree into a tools/ hierarchy. At the tag, .agents/scripts/ is gone (0
entries) and .agents/tools/ holds 18 unit directories
(adaptation, artifacts, benchmark, continuation, extension, extraction, finalize, grouping, lib, linkcheck, maintenance, prompts, quality, refinement, release, runners, shared, trajectory).
Note tools/grouping (not tools/merge) — corroborating the stage rename
below.

The honest shape of this release is that the migration did not land clean. A
repair tail runs through the rest of the range, all fallout from the move:

• 0291d03 — after the move, scripts still walked up the old directory depth;
  28 tool scripts had their PROJECT resolution collapsed from six
  .parent hops to four (the changelog's "26+" undercounts; 29 files touched:
  28 scripts + .gitignore).
• 6b000e5 — syntax errors and CRLF issues left by the migration.
• bddc852 — wrapper path resolved relative to tools/, not .agents/.
• e7119a3 — oneshot wrapper path relative to .agents/, not project root.
• 4de14e3 — model name + wrapper path corrected in tools and config.
• cd3b2cd — a duplicate config file "created by path resolution bug" removed.
• f946325 — all remaining .agents/scripts/ references rewritten to tools/.

Eight follow-up fixes for one move. That migration-then-repair arc is far more
interesting than the flat Added/Changed/Fixed buckets convey, and it is the real
narrative of the repository side.

The default model settled on tencent/hy3:free — via STE_MODEL

The changelog headlines 2000b8b ("Update default agent model to
poolside/laguna-s-2.1:free") as a Changed item. At the tag that headline is
false: git show 830d06c:.agents/config/agents.yaml reports
default_model: tencent/hy3:free. The poolside/laguna value was a short-lived
intermediate, abandoned inside this very release.

The true arc across the range (all 2026-07-31):

Step	Commit	Effect
base	0cf59e4 (v1.0.0)	default_model: deepseek-v4-pro
1	2000b8b	→ poolside/laguna-s-2.1:free (the changelog's headline)
2–5	dff1158, 94fd2e3, 4beed8f	→ tencent/hy3:free across agents/benchmark/scripts/docs
6	8dd744b	model reference moved behind the STE_MODEL env var
7–8	a76bd57, 005c80d	runners switch to tencent/hy3:free via STE_MODEL
tip	830d06c (v1.1.0)	default_model: tencent/hy3:free

So the durable, defensible headline is not a model name at all: the model
stopped being hardcoded and became STE_MODEL-driven (8dd744b). That single
indirection is why the churn could settle quickly, and it is the architectural
change v1.1.0 actually leaves behind. Published as "updated default model to
poolside/laguna-s-2.1:free," the note tells readers the opposite of what
shipped.

Reorganization, rename, and a stamp that nearly stuck

Three more repository-side changes are worth naming on their own.

• Skills reorganization [8c2c6ea] — 41 files changed (+76 / −7,836),
  overwhelmingly deletions and moves that de-duplicated skill content, plus
  path-reference rewrites in .agents/uml/database-layout.md and
  worker-lifecycle.md.
• Merge → grouping rename [fe91d38] — 41 files changed (+382 / −852),
  "rename merge stage to grouping with semantic awareness." Corroborated
  structurally: the unit directory is tools/grouping, not tools/merge; also
  touches .gitignore and ste-code/README.md.
• Version-stamp fix [830d06c, the tip commit] — "stamp the version being
  released, not the previous tag." A pre-tag sync had read the old tag and
  stamped 1.0.0 onto a 1.1.0 release; the fix exports STE_RELEASE_VERSION
  ahead of the claim sync, makes facts.py honour it for all three tracks,
  drops a stray claim site, and genuinely restamps CITATION.cff, ROADMAP.md,
  and FLAVOR.md. It is the most self-aware commit in the range — the release
  fixing the way it lies about itself. One honest caveat: it left FLAVOR.md
  half-stamped (the stamper rewrites only registry-declared blockquote
  patterns; the H1 and some prose still read STANDARD-1.0.0).

The .gitignore extracted-tracking saga (and a wrong attribution)

The changelog's Fixed section attributes 17b4f8d to "Negate
ste-code/extracted/ in .gitignore, add STE-Code extraction feedback." That
attribution is false about its own diff: git show 17b4f8d adds exactly one
file, .agents/feedback/exchange.md (+42 lines), and touches nothing in
.gitignore. The first half of that commit message was copied verbatim into the
changelog.

The real .gitignore negation work is 2a29611 ("negate extraction directory
to track extracted files") and a430bf7 ("re-enable tracking of
ste-code/extracted/ files"), both already in the changelog's Tooling sec...

STE-Code REPOSITORY v1.0.0

STE-Code REPOSITORY v1.0.0

Tag family. v1.0.0 is the full first release. It is accompanied by two
companion tags that slice the same content along a different axis:
STANDARD-1.0.0 carries the ASD-STE100 → code-documentation adaptation (the
rules, categories, dictionary, and level prompts), and FLAVOR-1.0.0 carries
the linguistic extension layer. Neither companion tag changes the other; they
are parallel views of one release, and v1.0.0 bundles both.

Tag, commit, and how to read these numbers

This note describes the first public release of the STE-Code standard. Every
measurement in it was taken at the release tag commit 0cf59e4 (tagged
v1.0.0), not at any later HEAD. Post-tag commits are explicitly out of
scope; we do not mix tag facts with working-tree facts.

Item	Value
First commit in range	bb1b29a - "chore: Initialize clean repository - fully anonymized, generalized"
Release tip (this note)	0cf59e4 - the tip commit's subject reads "roadmap: 6-phase master integration plan …", but that commit actually adds a 7-phase roadmap (Phase 0-6); see "Contradictions in the original published note"
Full release tag	v1.0.0 = 0cf59e4
Companion standard tag	STANDARD-1.0.0 = 7e20b0d (earlier than v1.0.0)
Companion flavor tag	FLAVOR-1.0.0 (linguistic layer extension)

Measurement rule. All file, line, commit, and content counts below are
measured at 0cf59e4. They are not re-derived from HEAD, and they do not
reflect any later patch.

Headline stats (all at 0cf59e4)

This is the initial repository import plus the first release, so the line
counts are dominated by file creation, not churn. The +113,800 is the volume
of new content introduced across the range; the −34,521 is in-range
refactoring and shaping of that new content, not deletion of a pre-existing
product. Read it as a founding footprint, not as edit activity.

Metric	Value
Files changed (bb1b29a..0cf59e4)	1,850
Lines	+113,800 / −34,521 (creation-dominant, not churn)
Commits	159 total (148 non-merge + 11 merge)
ste-code/ impact	961 files, +45,079 / −10,518
Adapted rule units	55 (51 writing rules + 4 grammar recommendations)
Code-domain categories	22
Dictionary entries adapted	560 (from ~2,149 source ASD-STE100 words)
Level system prompts	4 assembled (~1.2K-45K tokens) + level-5 full specification (~100K)
FLAVOR checking layers	12 specified, 5 enforced by reference linter
FLAVOR workflows	17
Benchmark	59 tests / 14 categories
Quality markers	0 FIXME (substance verified), 0 CRLF
Quality sweeps	2 passes over 65 files
Control-group pass rate	11.9% (committed, verifiable)

This is a standard release

There is no prior standard to correct, deprecate, or supersede - this is the
first one. v1.0.0 ships the STE-Code adaptation of ASD-STE100 Issue 9
(January 2025, ASD Europe) tailored to code documentation, the companion
FLAVOR-1.0.0 linguistic layer, and a benchmark that measures how well the
adaptation holds up.

What actually shipped:

• STANDARD-1.0.0 - the adaptation itself: 51 writing rules + 4 grammar
  recommendations, 22 code-domain categories, a controlled dictionary of 560
  adapted entries, and 4 deployable level system prompts plus a level-5 full
  specification.
• FLAVOR-1.0.0 - the linguistic layer: 12 specified checking layers
  (semantic roles, single referent, epistemic marking, quantifier precision,
  register profiles, and beyond), 17 workflows, and a reference linter.
• Benchmark - 59 tests across 14 categories, with a committed control-group
  baseline at 11.9% pass.

Because it is the first release, the framing throughout is "here is what we
built and how we know it is true," not "here is what changed." Where the
original published note drifted into marketing claims, these notes replace each
with a verified fact and name the source.

The central theme: a faithful, auditable adaptation

The whole point of v1.0.0 is that someone took a real, published industry
standard - ASD-STE100 Issue 9 - and adapted it, rule by rule, for the specific
job of writing code documentation. The work was not invention; it was
translation under discipline. The theme that runs through every chapter is
fidelity with evidence: each rule, category, and dictionary entry can be
traced back to its source, and each claim about the release can be checked
against the tree at 0cf59e4.

Concretely, the adaptation produced:

• 51 writing rules drawn from ASD-STE100's sections 1-9, reshaped for
  code-domain use (comments, error messages, config files, identifiers, and so
  on).
• 4 grammar recommendations (the "GR" units) carried over as guidance rather
  than hard rules.
• 22 code-domain categories - the controlled vocabulary is organized into 22
  noun categories drawn from the source standard's part-of-speech taxonomy.
• A controlled dictionary of 560 adapted entries, sampled and reshaped from
  roughly 2,149 source ASD-STE100 words.
• 5 deployable writing depths - 4 assembled level system prompts plus a
  level-5 full specification - so the same standard can be applied at anything
  from a tight inline-comment budget to specification-grade documentation.
• A linguistic FLAVOR layer that extends the base standard with semantic and
  epistemic checks, and a benchmark to measure whether the adaptation
  actually improves writing.

The "auditable" half of the theme is why this note names the tag commit on every
page and why it keeps separating verified facts from reported ones.

What the standard contains

Using the corrected counts verified at 0cf59e4:

• 55 adapted rule units - 51 writing rules + 4 grammar recommendations. This
  is the canonical v1.0.0 number. (Trajectory note: rules 2.3, 6.6, and
  8.7 were added after v1.0.0, in the v1.1.0 line, bringing that release to
  54 + 4 = 58 units. So the standard is 55 at first release, 58 by v1.1.0 -
  the counts are not portable across releases; measure each tag directly.)
• 22 categories - verified by counting ## Category headings in
  a-categories.md (Category 1 "Official Parts Information" … Category 22
  "Animals, Plants, and Other Life Forms").
• 560 adapted dictionary entries - counted from ## WORD (pos) headings in
  the dictionary file; 452 approved and 108 marked UNNAPROVED (a persistent
  source-file typo). These are adapted from ~2,149 source ASD-STE100 words
  (the source dictionary's approved + unapproved counts). The dictionary does
  not contain 2,149 entries - that figure describes the source surveyed,
  not what was adapted.
• 4 assembled level system prompts plus a level-5 specification:
  • Level 1 - level1/system-prompt.txt, 4,473 bytes (~1.2K tokens)
  • Level 2 - level2/system-prompt.txt, 17,884 bytes (~4.5K tokens)
  • Level 3 - level3/system-prompt.txt, 31,160 bytes (~8K tokens)
  • Level 4 - level4/system-prompt.txt, 126,528 bytes (~45K tokens)
  • Level 5 - a full specification (~100K tokens) delivered as 51 per-rule
    summary.md directories rather than a single assembled prompt file; a
    standalone ste-code-level5-max.txt (228,903 bytes) also exists.

The level prompts are deliberately sized so a consumer can pick the depth that
fits their budget - from an ultra-tight level-1 prompt for inline use up to the
specification-grade level-5 material.

The FLAVOR linguistic layer

FLAVOR-1.0.0 adds a linguistic extension on top of the base standard. The
layer stack in FLAVOR.md specifies 12 checking layers:

1. Epistemic Marking
2. Actor Model
3. Single Referent Rule
4. Semantic Roles
5. Verb Frames
6. Negation Control
7. Scope Bracketing
8. Discourse / Anaphora
9. Quantifier Table
10. Regist...

STE-Code STANDARD v1.1.0

STE-Code STANDARD v1.1.0

Tag-family note. This is a STANDARD release: it covers only the wording of the standard — rules, categories, dictionary, adaptation levels, and the FLAVOR linguistic layer. The companion REPOSITORY-v1.1.0 covers the whole repository (benchmark, tooling, model config, skills, scripts→tools migration, hygiene). All measurements below are taken at the release tag commit 830d06c (v1.1.0 = STANDARD-1.1.0 = REPOSITORY-1.1.0), not at any later HEAD. Post-tag commits are out of scope.

Headline stats (all at 830d06c)

Metric	v1.0.0 (0cf59e4)	v1.1.0 (830d06c)	Delta
Rule units	55 (51 rules + 4 GR)	58 (54 rules + 4 GR)	+3 rules
Code-domain categories	22	22	—
Dictionary entries	560 (corrected from the ~2,149 figure published at v1.0.0)	560	corrected in this range
Adaptation levels	5	8	+3 tiers
FLAVOR layers	12 specified / 5 enforced	12 specified / 5 enforced	—
Workflows	17	17	—

The brief's own most load-bearing omission: the published v1.1.0 changelog never states the rule count at all. The standard grew, the count was corrected, and neither fact appeared in the original note.

The standard grew (and the record caught up)

The headline of this release is plain, and the original changelog left it out entirely: the standard got bigger. Three new rules joined the adapted corpus —

• ste-code/adapted/a-sec2-rule2.3.md (Section 2, Multi-word Nouns),
• ste-code/adapted/a-sec6-rule6.6.md (Section 6),
• ste-code/adapted/a-sec8-rule8.7.md (Section 8),

— introduced by 64a9ccb ("Phase D: adapt rule sections 1–9 + GR appendices to code domain") and landed via 88ea3d7 ("Adapt Section 02 - Multi-word Nouns - PASS"). Neither commit is listed in the changelog's "Added" section.

The adapted corpus moved from 51 rules + 4 GR = 55 at v1.0.0 to 54 rules + 4 GR = 58 at v1.1.0. That is consistent with the published v1.0.0 note ("55 at first release, 58 by v1.1.0") and with the v1.2.0 note ("54 rules + 4 GR"). Across the family there is no contradiction — only an omission in the v1.1.0 changelog.

Growth is only half the story. This release also corrected the numbers it had inherited, which is where the more interesting honesty lives.

The numbers caught up

8a34daa ("Correct base standard counts in FLAVOR.md") is listed in the changelog as a bland Documentation line. It is actually three corrections at once, and each one walks back an overstatement:

Field in ste-code/linguistics/FLAVOR.md	Before (v1.0.0 era)	After 8a34daa
Rules	51	54
Adaptation levels	5	8
Dictionary entries	~2,149	560

The dictionary figure is the clearest tell: a-dictionary.md holds 563 ##-level entry headings that did not change between tags (203,102 B → 203,150 B). The "2,149" was never the real count — it was inflated by roughly 3.8×. v1.1.0 is the release that fixed an overstatement it inherited from v1.0.0, not one that shrank a living dictionary.

The correction has a self-aware wrinkle worth keeping. 8a34daa was preceded by a near-identical edit in c96764f at 15:13, reverted two minutes later by 16fd49d ("ste-code/ is production-grade and is not hand-edited… restore adapted/a-dictionary.md and linguistics/FLAVOR.md"), then re-made properly at 15:16 as a specification edit — 8a34daa's own body: "This is a specification document, not generated pipeline data." The project briefly reached into generated territory, pulled back, and then corrected the authored spec the right way. That is the boundary-policing culture showing through.

Two new artifact tiers shipped

Separate from the count corrections, this range added real deliverables that the changelog never states outright (they surface only as churny "Other" lines such as d105199, 9ec35fa, 98267d0): the artifact tier set grew from level0…level5 (6 dirs) to _base, level-1, level-2, level0…level5 (9 dirs). Two ultra-minimal tiers (level-1, level-2) plus a shared _base landed here — another size-of-the-standard gain the note omits.

A contamination reached the published artifacts

38996ce is logged in the changelog as "Correct rule numbering for technical nouns in principles and LLMs documentation." That wording hides what it actually fixed. The commit's three touched files — ste-code/artifacts/level0/01-principles.md, ste-code/artifacts/level0/system-prompt.txt, and ste-code/artifacts/llms-full.txt (the flagship all-in-one artifact) — carried a real defect:

-**Rule 超额1.11 — Do not use different technical nouns for the same item.**
+**Rule 1.11 — Do not use different technical nouns for the same item.**

超额 (roughly "over-quota") is a CJK token that leaked from the generating model straight into shipped output. This was LLM-contamination, not a numbering slip, and it reached llms-full.txt. The honest framing is found-and-corrected contamination, not a "numbering fix." Worth stating plainly: a model-generated artifact shipped with a non-English garbage token, and this release removed it.

The release that fixed how it lies about itself (and left one gap)

The tip commit 830d06c ("Stamp the version being released, not the previous tag") is the most self-aware commit in the range. A sync had been running before tagging, so the facts engine read the old tag and stamped 1.0.0 onto a 1.1.0 release. The fix exports STE_RELEASE_VERSION ahead of the claim sync, makes facts.py honour it for all three tracks (core, STANDARD, FLAVOR), drops a stray claim site, and genuinely restamps CITATION.cff, ROADMAP.md, and FLAVOR.md.

One gap is fair to name: 830d06c restamps FLAVOR.md's Flavor version: and Base standard: blockquote lines to 1.1.0, but the registry-backed stamper only rewrites those declared patterns. The file's H1 still reads v1.0.0, and a stale STANDARD-1.0.0 lingers in prose, an ASCII diagram, and a table. So the very commit that fixed version-stamping left FLAVOR.md half-stamped — exactly the class of drift it was reaching for but only partly solved.

Contradictions resolved

Contradiction	v1.0.0 / inherited	v1.1.0 (830d06c)
Dictionary entries	~2,149 (inflated)	560 (measured ~563 headings)
Adaptation levels	5	8
Rule units	"55 stable" narrative	55 at v1.0.0, then 58 at v1.1.0 (+3 rules)
CJK contamination in shipped artifacts	present (超额)	corrected (38996ce)
Version stamp	1.0.0 stamped on a 1.1.0 release	1.1.0 stamped (FLAVOR.md H1 left at 1.0.0)

Version boundary

• STANDARD-v1.1.0 = 830d06c = 54 rules + 4 GR = 58, 22 categories, 8 levels, 560 dictionary entries.
• Built on STANDARD-v1.0.0 (0cf59e4 = 51 + 4 = 55).
• Next standard increment: STANDARD-v1.2.0 — which, per the v1.2.0 notes, carries no rule-count change (stays 54 + 4 = 58). The wording story of v1.2.0 is the benchmark honesty work, not the corpus.

STE-Code STANDARD v1.0.0

STE-Code STANDARD v1.0.0

Tag, commit, and scope

This note describes only the standard wording in the first release of
STE-Code: the ASD-STE100 Issue 9 adaptation to code documentation, its
controlled vocabulary, the deployable level prompts, and the FLAVOR linguistic
layer. Repository infrastructure (the .agents/ Hermes toolchain, the benchmark
harness, quality sweeps) is covered by the parallel REPOSITORY-v1.0.0 release,
not here.

Every measurement was taken at the release tag commit 7e20b0d
(STANDARD-1.0.0), not at any later HEAD. Post-tag commits are out of
scope. (The full first release bundles additional content at 0cf59e4; see
REPOSITORY-v1.0.0 for that whole-repository story.)

Item	Value
Standard tag	STANDARD-1.0.0 = 7e20b0d
Source standard	ASD-STE100 Issue 9 (January 2025, ASD Europe)
Companion repository tag	REPOSITORY-v1.0.0 = 0cf59e4
Companion flavor tag	FLAVOR-1.0.0

Tag family. STANDARD-* releases cover only the standard wording.
REPOSITORY-* releases cover the whole repository. This note deliberately does
not describe .agents/, the benchmark, or tooling.

Headline stats (standard wording, at 7e20b0d)

Metric	Value
Adapted rule units	55 (51 writing rules + 4 grammar recommendations)
Code-domain categories	22
Dictionary entries adapted	560 (from ~2,149 source ASD-STE100 words)
Level system prompts	4 assembled (~1.2K–45K tokens) + level-5 full specification (~100K)
FLAVOR checking layers	12 specified, 5 enforced by reference linter
FLAVOR workflows	17

This is a standard release

There is no prior standard to correct, deprecate, or supersede — this is the
first one. STANDARD-1.0.0 ships the STE-Code adaptation of ASD-STE100 Issue
9 tailored to code documentation, plus the companion FLAVOR-1.0.0 linguistic
layer. The framing is "here is what we built and how we know it is true," not
"here is what changed."

The central theme: a faithful, auditable adaptation

The whole point of v1.0.0 is that a published industry standard — ASD-STE100
Issue 9 — was adapted, rule by rule, for code documentation. The theme is
fidelity with evidence: each rule, category, and dictionary entry traces
back to its source, and each claim can be checked against the tree at
7e20b0d.

The adaptation produced:

• 51 writing rules drawn from ASD-STE100's sections 1–9, reshaped for
  code-domain use (comments, error messages, config files, identifiers).
• 4 grammar recommendations (the "GR" units) carried as guidance.
• 22 code-domain categories — the controlled vocabulary organized into 22
  noun categories from the source standard's part-of-speech taxonomy.
• A controlled dictionary of 560 adapted entries, sampled and reshaped from
  roughly 2,149 source ASD-STE-Code words.
• 5 deployable writing depths — 4 assembled level system prompts plus a
  level-5 full specification — so the same standard applies from a tight inline
  comment up to specification-grade documentation.
• A linguistic FLAVOR layer that extends the base standard with semantic and
  epistemic checks.

What the standard contains

Using the corrected counts verified at 7e20b0d:

• 55 adapted rule units — 51 writing rules + 4 grammar recommendations.
  (Trajectory note: rules 2.3, 6.6, and 8.7 were added after v1.0.0, in
  the v1.1.0 line, bringing that release to 54 + 4 = 58 units. So the standard
  is 55 at first release, 58 by v1.1.0 — counts are not portable across
  releases; measure each tag directly.)
• 22 categories — verified by counting ## Category headings in
  a-categories.md (Category 1 "Official Parts Information" … Category 22
  "Animals, Plants, and Other Life Forms").
• 560 adapted dictionary entries — counted from ## WORD (pos) headings;
  452 approved and 108 marked UNNAPROVED (a persistent source-file typo).
  Adapted from ~2,149 source ASD-STE100 words (the source dictionary's
  approved + unapproved counts). The dictionary does not contain 2,149
  entries — that figure describes the source surveyed, not what was adapted.
• 4 assembled level system prompts plus a level-5 specification:
  • Level 1 — level1/system-prompt.txt, 4,473 bytes (~1.2K tokens)
  • Level 2 — level2/system-prompt.txt, 17,884 bytes (~4.5K tokens)
  • Level 3 — level3/system-prompt.txt, 31,160 bytes (~8K tokens)
  • Level 4 — level4/system-prompt.txt, 126,528 bytes (~45K tokens)
  • Level 5 — a full specification (~100K tokens) delivered as 51 per-rule
    summary.md directories rather than a single assembled prompt file; a
    standalone ste-code-level5-max.txt (228,903 bytes) also exists.

The FLAVOR linguistic layer

FLAVOR-1.0.0 adds a linguistic extension on top of the base standard. The
layer stack in FLAVOR.md specifies 12 checking layers:

1. Epistemic Marking
2. Actor Model
3. Single Referent Rule
4. Semantic Roles
5. Verb Frames
6. Negation Control
7. Scope Bracketing
8. Discourse / Anaphora
9. Quantifier Table
10. Register Profiles
11. Lifecycle States
12. Definition Discipline

Be precise about enforcement. The reference linter, ste_code_lint.py,
implements 5 of the 12 layers: semantic_roles, single_referent,
epistemic, quantifiers, and register. The remaining 7 are specified but
not yet enforced by the shipped tool.

Be precise about documentation, too. Layers 6 (Negation Control), 7 (Scope
Bracketing), 8 (Discourse / Anaphora), and 12 (Definition Discipline) point
their spec anchors at a SPECIFICATION.md that does not exist — not at the
tag, and not at HEAD. So 4 of the 12 advertised layers have no backing
specification document, in addition to not being linted. This is a live repo
inconsistency (see below), not a claim of this note.

Known standard-internal inconsistencies

These are inconsistencies inside the v1.0.0 standard/flavor files themselves
— not errors in this release note, but a reader who opens the repo will hit
them, so they are stated here:

• artifacts/README.md says 19 categories; the standard has 22. The actual
  a-categories.md has 22, and ste-code/README.md agrees. The artifacts
  README is stale at the tag. (This note's "22" is correct.)
• ste-code/README.md says "53 rules" in its quality block, while the same
  file's Stage 4 box says "51 rules + 4 GR." 53 matches neither 51 nor 55. Do
  not propagate the 53.
• artifacts/sweep-report.md is referenced but missing. git cat-file at
  the tag confirms it does not exist.
• SPECIFICATION.md is missing at the tag and at HEAD. Four FLAVOR layers
  (6, 7, 8, 12) anchor their specs there, so those layers have no backing spec
  document.
• The reference linter enforces 5 of 12 FLAVOR layers (see above). The other
  7 are specified but not enforced.

Contradictions in the original published note (corrected here)

The original published v1.0.0 note was a flat, marketing-style draft. Where it
stated a number the verified tree contradicts, this note uses the verified
value. Each correction is RESOLVED in these notes:

#	Original claim	Verified correction	Status
1	"2,149 dictionary entries"	560 adapted entries from ~2,149 source ASD-STE100 words	RESOLVED
2	"18 workflows"	17 workflows (WORKFLOWS.md)	RESOLVED
3	"5 level system prompts (1.2K–45K)"	4 assembled prompts (~1.2K–45K) + level-5 full specification (~100K)	RESOLVED
4	implied 55 rules stable	55 at first release, 58 by v1.1.0 (rules 2.3, 6.6, 8.7 added later)	RESOLVED

Note that "55 adapted rules" in the original was correct for v1.0.0 — the
error was only in the dictionary count, the workflow count, and the level-prompt
count.

Version boundary

• STANDARD-1.0.0 (7e20b0d) is the first standard wording release.
• The next standard increment is STANDARD-v1.1.0, which adds rules 2.3,
  6.6, and 8.7 (bringing the count to 54 + 4 = 58 units). When reading later
  standard notes, remember that "54 rules" describes v1.1.0 onward, not the
  v1.0.0 first release.
• The whole-repository story for this release lives in REPOSITORY-v1.0.0.

---

Adapted from ASD-STE100 Issue 9 (January 2025), ASD Europe. All counts
verified at tag 7e20b0d; post-tag commits are out of scope. See
ste-code/README.md for full Credits & References.