agent-loss-map 0.18.0__tar.gz

agent_loss_map-0.18.0/CONTRIBUTING.md

@@ -0,0 +1,173 @@
+# Contributing
+
+The value of this harness is coverage. Every framework you add is a framework
+whose interop loss is now measured rather than assumed, and your name is on it.
+Adding one should take about twenty minutes and should not require understanding
+the audit modules.
+
+## Measuring a format, without changing anything
+
+A corpus entry is pure data, and the checks are driven entirely off its fields,
+so you can measure a format with a JSON file and no Python at all:
+
+```bash
+cat > my-format.json <<'JSON'
+{
+  "framework": "my-framework",
+  "agent_id": "my_agent",
+  "description": "What this is.",
+  "confidence": "documented",
+  "provenance": "Where you read the shape, and when",
+  "capabilities": [
+    { "name": "web.search", "description": "Search the web.",
+      "parameters": { "type": "object", "properties": { "query": { "type": "string" } } } }
+  ]
+}
+JSON
+
+agent-loss-map --corpus my-format.json
+```
+
+`--corpus` also accepts a directory of files, and is repeatable. Your format gets
+its own section in the report, computed by exactly the same checks as the bundled
+entries.
+
+Two things the loader refuses rather than guesses:
+
+- **`confidence` and `provenance` are required.** A finding with no declared
+  provenance looks as trustworthy as a real observation, which is the one thing
+  the tier exists to prevent. A misspelt tier is an error, not a downgrade to
+  `inferred`.
+- **A typo in a field name is an error.** `capabilties` would otherwise be
+  ignored and the entry would quietly under-report.
+
+`confidence` accepts short forms (`observed`, `documented`, `inferred`) and is
+normalised to the canonical tier in the report. A bundled framework cannot be
+overridden by a file; those entries are pinned to the upstream commit that was
+read.
+
+## Adding a framework to the corpus
+
+This is the version that goes in the package, for a format worth keeping. Open
+`agent_loss_map/corpus.py` and append a `ForeignAgent` to `CORPUS`:
+
+```python
+MY_FRAMEWORK = ForeignAgent(
+    framework="my-framework",
+    agent_id="my_agent",              # must match UACP's ^[a-zA-Z0-9_]{1,128}$
+    description="What this agent is for.",
+    capabilities=[
+        {
+            "name": "web.search",
+            "description": "Search the web.",
+            "parameters": {
+                "type": "object",
+                "properties": {"query": {"type": "string"}},
+                "required": ["query"],
+            },
+            "outputSchema": {"type": "object", "properties": {}},
+        }
+    ],
+    prose_claims=["What the docs promise a human reader."],
+    is_stateful=False,                # does a call see prior calls?
+    streams_tokens=False,             # per-token chunks, or only results?
+    supports_multimodal=False,        # non-string content parts?
+    provenance="https://... — read 2026-09-27",
+    confidence="documented-api",
+    source_shape="What kind of thing the fields above actually came from.",
+)
+```
+
+Then run it:
+
+```bash
+agent-loss-map
+```
+
+Your framework gets its own `PART 2` section in the report. You did not have to
+write a single check.
+
+### The one rule
+
+**Do not invent a serialization.** If your framework has no documented portable
+form for an agent definition, say so in `source_shape` and model the
+constructor or API surface instead. The AutoGen entry does exactly this and is
+therefore the weakest evidence in the corpus; a fabricated schema would be
+stronger-looking and worthless.
+
+Every finding is derived from what the source actually declares. That is the
+whole point of the tool, and an entry that guesses undermines every number in
+the report next to it.
+
+### Pick your confidence tier honestly
+
+| Tier | Means |
+|---|---|
+| `observed-serialization` | You read a real serialized artifact |
+| `documented-api` | Taken from official documentation of the public API |
+| `inferred` | Your modelling choice, not a documented shape |
+
+The CLI prints the tier for every entry, and the report says which findings rest
+on weaker evidence. If yours is `inferred`, the findings are still useful, but
+say so.
+
+### Choosing capability names
+
+Two things produce findings before your framework has even been tested, and both
+are worth seeing rather than papering over:
+
+- `name` must match `^[a-zA-Z0-9_.]{1,128}$` — use the source's real name. A
+  `SCHEMA_VIOLATION` here is a real result, not a harness bug.
+- A name with no dot is a `LOSSY` finding. That is the point.
+
+## Adding a new check
+
+Checks live in `adapters.py` (source → UACP), `spec_audit.py` (schema vs the
+prose) or `impl_audit.py` (schema vs the reference implementations).
+
+Two obligations come with every check:
+
+1. **A meta-test that proves the check fires.** Mutate a copy of the input so
+   the defect is absent, and assert the check goes quiet. A check that silently
+   stopped working is worse than no check, because the report still looks
+   healthy. The existing `test_meta_*` tests are the pattern to copy.
+
+2. **Evidence on every finding.** `test_every_divergence_carries_evidence`
+   enforces a non-empty `detail` and `evidence`. A reader must be able to check
+   your work.
+
+### Do not predict what you can observe
+
+`SCHEMA_VIOLATION` has exactly one source: `validate_descriptor()`, which runs
+the real JSON Schema validator over the artifact the adapter produced. Do not
+also check a schema pattern with a hand-copied regex. A copied pattern is a
+second source of truth that can drift from the schema it was copied from, and CI
+only pins the schemas. It also counted every such defect twice before this was
+fixed.
+
+### One field, one finding
+
+Report a divergent field once, however many witnesses it has. If both reference
+implementations disagree the same way about a field, that is one defect with two
+witnesses: cite both in `evidence` rather than emitting two findings.
+`duplicate_findings()` checks this over the whole report and the suite asserts it
+holds.
+
+## Running the tests
+
+```bash
+pip install -e ".[dev]"
+pytest -q
+```
+
+## Regenerating the report artifact
+
+`docs/sample-report.txt` is a captured run, committed so a reader can see the
+output without installing. After changing a check:
+
+```bash
+agent-loss-map > docs/sample-report.txt
+```
+
+CI re-runs the probe weekly and opens an issue if the corpus or the schemas
+have moved, so the published counts cannot go stale unnoticed.

agent_loss_map-0.18.0/FINDINGS.md

@@ -0,0 +1,381 @@
+# UACP interop conformance harness
+
+Finds where a UACP agent definition and framework-native agent definitions
+actually diverge, and whether UACP's own JSON Schemas agree with UACP's own
+normative text.
+
+## Why this exists
+
+UACP's `CONFORMANCE.md` defines L0 to L3 as a feature checklist: does your
+implementation have a stdio transport, does it do rate limiting, does it declare
+a `protocolVersion`. Passing that proves an implementation matches its author's
+reading of the spec. It says nothing about whether two implementations built by
+different people interoperate, which is the premise the whole project rests on.
+
+This harness tests the three things the checklist cannot:
+
+1. **Schema versus prose.** Build a message the spec *requires* an
+   implementation to accept, then validate it against the shipped schema and
+   report the rejection.
+2. **Schema versus the implementations.** Check that each reference
+   implementation can actually represent what the schema declares, and that the
+   two implementations model the same envelope. This is the class that found the
+   silent credential downgrade.
+3. **Cross-format divergence, in both directions.** Map a foreign agent
+   description into a UACP descriptor, validate the artifact actually produced,
+   and separately test whether a UACP capability survives being expressed in a
+   framework's native tool format.
+
+## Method
+
+Losses are computed, not asserted. `SCHEMA_VIOLATION` findings are observed by
+running the real validator over the artifact the adapter produced. Divergences
+in the reverse direction are found by walking the source JSON Schema and
+collecting keywords outside the target format's supported subset.
+
+Every corpus entry declares `confidence`:
+
+- `observed-serialization`: a real serialized artifact was read
+- `documented-api`: taken from official documentation of the public API
+- `inferred`: our modelling choice, not a documented shape
+
+Findings derived from weaker entries are weaker evidence, and the CLI says so.
+
+## Findings against UACP `main`
+
+Against `wippa-uacp@92093793`: **4 schema conflicts, 11 cross-format findings
+(2 blocker, 7 major, 6 minor; 15 in total).**
+
+A captured run of exactly these numbers is committed at
+[`docs/sample-report.txt`](docs/sample-report.txt), and CI re-runs the probe
+weekly and opens an issue if the result stops matching it.
+
+**UACP is at zero blockers.** Its schemas agree with its normative text, and the
+TypeScript and Python reference implementations model the same envelope. Both
+remaining blockers are loss measured in a *foreign* format:
+
+| Blocker | Whose defect |
+|---|---|
+| `csv.analyze.inputSchema.const` | A UACP capability using a JSON Schema keyword an OpenAI function-calling block cannot express |
+| `csv.analyze.inputSchema.oneOf` | As above |
+
+**A third blocker here used to be ours.** `$['id']` was a `SCHEMA_VIOLATION`
+against the `openai-function-calling` corpus entry, whose agent id `tool-caller`
+did not match UACP's `^[a-zA-Z0-9_]{1,128}$`. The corpus entry was right and the
+protocol was wrong: the same measurement against live MCP servers that rejected
+hyphens in *capability* names also rejected them in *agent ids*, and two of six
+servers announce a hyphenated `serverInfo.name`. `wippa-uacp` widened the pattern
+to `^[a-zA-Z0-9_\-]{1,128}$` in PR #6. Re-vendoring the schema is what cleared the
+finding — until then it kept reporting as live, which is the failure mode this
+document's provenance section warns about.
+
+The last two majors against UACP itself are `capability.async`, whose schema
+default of `true` means a plain request/response consumer waits for a stream
+that never arrives, and the `schemas.$id` / `$ref` finding described below.
+
+## Corrected counts
+
+Earlier revisions of this document reported 9 and 13, with 6 blockers and 12
+majors. Those counts were wrong: two defects were being emitted twice. A
+hyphenated agent id produced both a *predicted* `SCHEMA_VIOLATION` from a
+hand-copied regex and an *observed* one from the real validator, and
+`metadata.flowControl` was reported once per reference implementation rather
+than once with both cited as evidence. Both are fixed; `duplicate_findings()`
+now asserts that no two findings in a report share a `(code, field)` pair, and
+the suite includes a guard proving that check can see a duplicate when one is
+injected.
+
+## Fixed upstream
+
+The harness was written against its own protocol, so its early reports were
+mostly defects in UACP. Each is fixed upstream and retained here as a
+regression guard, so a regression re-opens it rather than passing silently.
+
+| Was | Defect | Fixed in |
+|---|---|---|
+| 2 blockers | `metadata.auth` in the TypeScript model, absent from Python. `from_dict` built metadata from a fixed field list without it, so an authenticated message decoded into a credential-free object with no error raised | `wippa-uacp@b3fe7a1f` |
+| 3 majors | `capability` in the schema's global `required` list, while the spec's message table gives `heartbeat`, `register`, `deregister` and `discover` no target capability. A conforming implementation had to invent a placeholder, and both halves sent the literal `_internal` | `wippa-uacp@b3fe7a1f` |
+| 1 major | `flowControl` documented in SPEC.md under "Flow control" and modelled by both implementations, declared by no schema, so a message carrying it validated against nothing | `wippa-uacp@b3fe7a1f` |
+| 1 blocker | Audit-trail credential persistence in plaintext | `wippa-uacp@e0463b44` |
+
+One of those meta-tests had itself gone vacuous and was rewritten. The
+implementation-agreement meta-test mutated the Python model by *adding* `auth`,
+which was correct while the defect was live. Once both halves carried `auth`,
+the mutation became a no-op and the test could no longer fail — a check that had
+quietly stopped working, which is the exact failure this harness exists to
+catch. It now removes the field instead, so reintroducing the silent credential
+downgrade anywhere in the observed field sets fails the suite.
+
+## Resolved in `main` at `7bcc2594`: one decision, three contradictions
+
+Section 12 promised that unknown fields "in the envelope or metadata" were
+silently ignored. The schema never did that for the envelope, which sets
+`"additionalProperties": false` at the top level while `$defs/metadata` sets it
+to `true`. Three defects shared that root, and resolving them separately invites
+inconsistent answers, so they were resolved as one decision about what the
+envelope is allowed to mean over time.
+
+The schema split was already correct, and the existing extension namespace in
+section 12 already routed growth through `metadata` with `vendor.extension_name`
+keys. So the prose was wrong, not the schema.
+
+**Forward compatibility.** Narrowed to `metadata`, which is what the schema
+encoded. The closed envelope is now a stated design decision rather than an
+accident, justified by the typo case: a mistyped `protocolVersion` or `traceId`
+is far likelier than a legitimate new field, and ignoring it would drop routing
+information.
+
+**Version pinning.** `"const": "0.1.0"` became the MAJOR-family pattern
+`"^0\.[0-9]+\.[0-9]+$"`. The exact pin made section 12's same-MAJOR
+interoperability rule impossible to honour, because a 0.1.1 message was invalid
+to a 0.1.0 validator. The published schema now tracks the released MAJOR line.
+
+**Message type set.** The closed `type` enum became
+`anyOf[known types, naming pattern]`. A MINOR bump may add a message type and
+section 12 requires unrecognised types to be tolerated, so a closed enum made
+both unreachable. This was a third instance of the same contradiction, found
+only by reading section 12 against section 18 together.
+
+**The governance cost, stated rather than implied.** No new top-level field can
+ship in a MINOR bump, because an earlier validator will reject it. Growth within
+a MAJOR series goes in `metadata` or as a new message type, and adding a
+top-level field is a MAJOR change that must not be used to avoid adding a
+metadata field. The spec also now notes that this differs from protobuf, which
+preserves and round-trips unknown fields rather than rejecting them.
+
+Verified against the validator: 0.1.0, 0.1.1 and 0.9.0 accepted; 1.0.0 and
+`"0.1"` rejected; known and new dot-separated types accepted; `Not A Type`,
+`agent.novel_type` and `9bad` rejected; unknown top-level field rejected;
+unknown metadata field accepted; a `traceid` typo rejected.
+
+## Fixed in `main` at `e0463b44`
+
+**Audit-trail credential persistence (was: blocker, `metadata.auth.token`).**
+Section 15.2 said implementations MUST never log token values. Section 16.3
+separately mandated writing "Full metadata JSON" to the audit trail and named no
+redaction hook, and L3 required a "full message log". The reference
+implementation followed 16.3 literally: `log_message` wrote
+`json.dumps(message.metadata.to_dict())` straight into the registry SQLite file.
+`create_redacted_log` already existed in `core/redact.py` and was never called
+from the audit path. So a bearer or API key token, and any secret-looking
+payload key, were persisted in plaintext, in the conformance level named
+"Security".
+
+Fixed by routing `log_message` through `create_redacted_log`, adding the
+normative requirement to 16.3, 15.2 and CONFORMANCE L3, correcting the "Full
+trace replay" claim to a redacted replay, and documenting the requirement on
+`metadata.auth` in the schema. Ten new tests read the SQLite file directly,
+bypassing any accessor-layer redaction; seven of them fail against the previous
+implementation. 94 tests pass: 84 pre-existing and unchanged, plus 10 new.
+
+The same investigation found a latent crash with no test coverage at all:
+`Message` has no `__post_init__`, so a caller can hand `log_message` a plain dict
+and the old code raised `AttributeError` on a diagnostic path. No existing test
+ever passed metadata to `log_message`, which is why it went unnoticed.
+
+## New blockers, found by comparing code to schema
+
+These are invisible from the schemas alone and needed a schema-versus-
+implementation check.
+
+**1.** The Python implementation cannot represent `metadata.auth` at all.
+`envelope.schema.json` declares it with `required: ['type','token']`.
+`MessageMetadata` in `python/wippa_uacp/core/types.py` has no such field, and
+`Message.to_dict` and `Message.from_dict` both handle a fixed field list, so a
+conforming envelope from a peer is silently degraded on decode.
+
+**2.** The two reference implementations disagree, and the failure mode is silent
+credential downgrade.** `typescript/src/core/types.ts` declares
+`auth?: { type, token }`. The Python one does not. A request authenticated by a
+TypeScript peer is decoded by a Python peer into metadata that has dropped the
+token, with no error raised. The message then relies entirely on section 15.4
+default-deny ACLs to be stopped. Silent downgrade is worse than either rejecting
+the message or honouring it, so 15.2 now requires rejecting a message whose
+`auth` the implementation cannot validate.
+
+**3.** `flowControl` is implemented in both languages and declared in neither
+schema.** Both `MessageMetadata` models carry it, and section 13 has a flow
+control section, but `envelope.schema.json` omits it entirely. Anything using
+flow control is outside the specification and will not survive validation against
+a conforming peer.
+
+
+### Remaining blockers and majors
+
+**4.** The schema set cannot be resolved offline.
+Every `$id` sits on `wippa.dev`, which does not resolve. `agent-descriptor`
+refs `capability.schema.json` *relatively*, which resolves against that `$id` and
+therefore also becomes unreachable. A standards-compliant validator attempts a
+network fetch and fails with `Unretrievable`. This harness had to build a local
+`referencing.Registry` just to validate. Air-gapped builds and offline CI break.
+
+**5.** A UACP descriptor cannot name a hyphenated MCP tool.** `capability.name`
+and `agent.id` are `^[a-zA-Z0-9_.]{1,128}$`, which rejects `-`. MCP tool names
+are conventionally hyphenated — `resolve-library-id`, `query-docs`,
+`get-library-docs` — and OpenAI's own function-name grammar
+(`^[a-zA-Z0-9_-]{1,64}$`) accepts all of them. A conforming UACP descriptor has
+to rename the tool, and a renamed tool is a different tool to any client that
+refers to it by name.
+
+Measured, not argued: `examples/context7.entry.json` is a live capture of
+Context7 4.1.1 and produces two blockers under released UACP, one per tool.
+DeepWiki's tools are underscored and pass, so this is a property of the name and
+not of the capture path.
+
+The two grammars are not subsets of each other, and that asymmetry runs both
+ways — UACP's dot-notation namespace is *also* rejected by OpenAI, so
+`csv.analyze` does not survive a conversion in the other direction either. Any
+format pair with this property forces a rename somewhere, which is the general
+problem this harness exists to make visible.
+
+Fixed in `main` at `0a4b166`: `-` added to the character class, additive so no
+valid name became invalid, and `agent.id` deliberately left strict since an agent
+is an identity rather than a namespace. The same change corrected SPEC.md, whose
+stated character set had excluded the dot its own namespace convention requires.
+
+Re-measured against the merged spec: Context7 and DeepWiki both go to zero
+blockers, and the tool names survive unrenamed, which was the whole point. The
+other direction is unchanged and is not a UACP defect — `csv.analyze` still does
+not survive conversion to an OpenAI function name, because OpenAI rejects dots.
+
+### Majors
+
+**6.** `capability` is mandatory for messages that have none.** It is in the
+global `required` list, so `heartbeat`, `register` and `discover` must all carry
+one, and the pattern requires at least one character. There is no honest value
+to supply. A conforming implementation must invent a placeholder.
+
+**7.** `async` defaults to true, inverting the common case.** A capability that
+omits `async` is treated as streaming or deferred, so a plain request/response
+capability must opt out explicitly. A consumer trusting the default waits for a
+`stream.end` that never arrives, which presents as a hang rather than a schema
+error.
+
+**8.** Agents with no machine-readable capabilities are a discovery blocker.
+AutoGen's `AssistantAgent` exposes `name`, `description` and a tool list, but no
+structured capability manifest with input and output schemas. A UACP registry
+consumer asking "who can do `csv.analyze`" can only substring-match free text.
+The answer is a guess, not a verifiable claim. This is the capability-overclaim
+problem in its purest form, and it is not fixable by an adapter.
+
+**9.** Stateful agents have no UACP representation.** AutoGen documents `run()` as
+mutating internal history and being called with new messages rather than
+complete history. A UACP descriptor has no lifecycle or state field, and the
+envelope is stateless message passing, so two calls that look identical on the
+wire mean different things on either side.
+
+**10.** Token streaming and result streaming are different things.** AutoGen emits
+per-token `ModelClientStreamingChunkEvent`s that are part of the agent's own
+message trace. UACP section 13 defines `stream`/`stream.end` as partial *results*
+correlated to a request by `replyTo` and sequence numbers. Mapping one onto the
+other conflates the agent's reasoning trace with the result stream, so a UACP
+consumer would receive internal reasoning it never asked for and could not tell
+the two apart.
+
+**11.** Heterogeneous content parts are unrepresentable.** `MultiModalMessage`
+accepts `content=[str, Image]`. The UACP payload is untyped so a list would
+validate, but the spec defines no modality, media type or part ordering, and an
+in-memory `Image` has no wire form. Nothing distinguishes it from an ordinary
+array payload.
+
+**12.** A missing output contract has to be fabricated.** UACP requires
+`outputSchema` on every capability. Neither AutoGen's `FunctionTool` nor an
+OpenAI function declaration carries one, so the adapter must invent a permissive
+schema and consumers will believe a guarantee the source never made.
+
+**13.** Rich JSON Schema cannot reach an OpenAI-style tool consumer.** A UACP
+capability using `oneOf` or `const` has no representation in an OpenAI
+function-calling `parameters` block, which supports a small fixed subset. The
+capability cannot be exposed without dropping the constraint or flattening it
+into prose. This is the only genuinely *bidirectional* blocker found, and it
+lives in the UACP-to-foreign direction.
+
+### Minors
+
+**14.** The OpenAI `strict` flag has no JSON Schema equivalent, so the guarantee
+is dropped in either direction and cannot be re-expressed as a UACP consumer
+check.
+
+**15.** Capability names without a namespace prefix (`web_search_func`,
+`get_weather`) must be renamed, so namespace-scoped registry queries will not
+match the original name.
+
+**A server whose own name contains a hyphen cannot describe itself.**
+
+`agent-descriptor.id` is `^[a-zA-Z0-9_]{1,128}$`, and an MCP server announces itself
+as `serverInfo.name`. Taking that as the agent id is the obvious mapping, and it
+fails for 2 of the 8 live servers measured here — `inside-ads` and
+`adoraads-beauty-gateway` each produce a blocker on their own name.
+
+The distinction that matters is that this is *not* the finding 5 defect and not
+fixed by it. There, a tool name had to be renamed, and the fix lets the real name
+through. Here the strictness is deliberate and correct — an agent is an identity,
+not a namespace — and the loss is unavoidable in that direction: the server
+cannot rename itself, since the name is what every existing client asks for.
+
+Neither reference implementation would have caught it. Both accept a hyphenated
+`AgentDescriptor.id`; only a schema validator rejects one, so a conformant
+validator and a working implementation disagree about the same object.
+
+Captured as `examples/adoraads-beauty.*`, and the capture script deliberately
+does not sanitise the name — doing so would make the probe pass and hide the
+loss, which is the opposite of what it is for.
+
+**No cross-pipeline cost ceiling, and a loop between conforming agents is silent.**
+
+Rate limiting is specified as a MAY and neither `Bus` implements it. More
+consequentially, nothing bounds a pipeline as a whole: a per-agent ceiling says
+nothing about the sum across every agent on the bus.
+
+Measured, not argued. Two agents, each individually conforming and each invoking
+the other's declared capability, ran at roughly 20,000 round trips per second.
+The only bound was the host language's recursion limit — tightening it from 1000
+to 200 scaled the round trips from 124 to 24, proportionally — and the initiating
+caller received an ordinary `response` with nothing indicating the pipeline had
+been cut short.
+
+The failure is silent, which is what makes it worth recording. It has the same
+shape as finding 7, where a request/response capability was documented as
+streaming and a consumer observed a hang rather than an error: in both cases the
+caller cannot distinguish a completed run from a truncated one.
+
+This cannot be closed by writing better code, because there is no claim to have
+failed — the spec is silent. `wippa-uacp` §15.8 records it as unspecified, and
+the harness reports it as a major `UNVERIFIABLE_CLAIM` that stays reported even
+against a perfect implementation.
+
+## Running it
+
+```bash
+uvx agent-loss-map                                # human-readable
+uvx agent-loss-map -- --json                      # machine-readable
+uvx agent-loss-map -- --fail-on-blocker           # CI gate
+```
+
+From a checkout, `pip install -e .` and then `agent-loss-map`. Tests need the dev
+extra: `pip install -e ".[dev]" && pytest -q`.
+
+## Adding your own framework
+
+Append a `ForeignAgent` to `agent_loss_map/corpus.py` and re-run. You do not have
+to write a check: the divergences for your framework are computed from the
+fields you declare. See [CONTRIBUTING.md](CONTRIBUTING.md), which also covers the
+provenance tiers and the one rule — do not invent a serialization you cannot
+source.
+
+## What would strengthen this
+
+- Observed serializations rather than constructor surfaces. The AutoGen entry is
+  the weakest evidence in the corpus for exactly this reason, and AutoGen does
+  publish a component-serialization mechanism that was not inspected here.
+- The implementation audit records observed field sets as data with provenance,
+  rather than parsing the dataclass and TypeScript interface at runtime. Parsing
+  them with regex would be more fragile than the value it adds. Re-reading them
+  is a manual step, so they can drift.
+- Decisions on the two remaining normative conflicts (`additionalProperties` and
+  the `const` version pin), which are design questions rather than defects and
+  are deliberately left to the spec owner.
+- LangGraph, CrewAI and OpenAI Assistants entries, which are the formats most
+  likely to be lossier than the two here.
+- A behavioural half: run two implementations against each other and compare
+  actual message sequences, which is what "interoperate" ultimately means.

agent_loss_map-0.18.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 wippa-studios
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

agent_loss_map-0.18.0/MANIFEST.in

@@ -0,0 +1,8 @@
+include LICENSE
+include README.md
+include CONTRIBUTING.md
+include FINDINGS.md
+recursive-include agent_loss_map/schemas *.json
+recursive-include docs *.txt *.json *.md
+recursive-include scripts *.py
+recursive-include examples *.json