Squashed 'shared/' changes from a2b57d2..ddaae5d
ddaae5d chore(release): publiseringsklar for open/ — README for standalone rot + MIT + policy-filer f98b287 docs(plan): V1 RATIFISERT — og :275 er en andre tabellrad, ikke prosa d6bced7 docs(plan): SS11 ankrer ikke SS8 — funnet var reelt, men ikke raden som ble bestilt 3174475 docs(plan): §7.2 — feilanker-failuremoden var ikke hypotetisk, den inntraff git-subtree-dir: shared git-subtree-split: ddaae5d637ba4ee8425291d99cfe5c8f7b632001
This commit is contained in:
parent
8a86f2ab6d
commit
e0fa223591
8 changed files with 428 additions and 46 deletions
59
CODE_OF_CONDUCT.md
Normal file
59
CODE_OF_CONDUCT.md
Normal file
|
|
@ -0,0 +1,59 @@
|
|||
# Contributor Covenant Code of Conduct
|
||||
|
||||
## Our Pledge
|
||||
|
||||
We as members, contributors, and leaders pledge to make participation in our
|
||||
community a harassment-free experience for everyone, regardless of age, body
|
||||
size, visible or invisible disability, ethnicity, sex characteristics, gender
|
||||
identity and expression, level of experience, education, socio-economic status,
|
||||
nationality, personal appearance, race, religion, or sexual identity
|
||||
and orientation.
|
||||
|
||||
We pledge to act and interact in ways that contribute to an open, welcoming,
|
||||
diverse, inclusive, and healthy community.
|
||||
|
||||
## Our Standards
|
||||
|
||||
Examples of behavior that contributes to a positive environment:
|
||||
|
||||
* Demonstrating empathy and kindness
|
||||
* Being respectful of differing opinions and experiences
|
||||
* Giving and gracefully accepting constructive feedback
|
||||
* Accepting responsibility and apologizing for mistakes
|
||||
* Focusing on what is best for the community
|
||||
|
||||
Examples of unacceptable behavior:
|
||||
|
||||
* Trolling, insulting or derogatory comments
|
||||
* Public or private harassment
|
||||
* Publishing others' private information without permission
|
||||
* Other conduct which could reasonably be considered inappropriate
|
||||
|
||||
## Enforcement Responsibilities
|
||||
|
||||
Community leaders are responsible for clarifying and enforcing our standards of
|
||||
acceptable behavior and will take appropriate and fair corrective action in
|
||||
response to any behavior that they deem inappropriate, threatening, offensive,
|
||||
or harmful.
|
||||
|
||||
## Scope
|
||||
|
||||
This Code of Conduct applies within all community spaces, and also applies when
|
||||
an individual is officially representing the community in public spaces.
|
||||
|
||||
## Enforcement
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||||
reported to the community leaders responsible for enforcement at
|
||||
hello@fromaitochitta.com.
|
||||
|
||||
All complaints will be reviewed and investigated promptly and fairly.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
|
||||
version 2.1, available at
|
||||
[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
|
||||
66
CONTRIBUTING.md
Normal file
66
CONTRIBUTING.md
Normal file
|
|
@ -0,0 +1,66 @@
|
|||
# Contributing to portfolio-optimiser-commons
|
||||
|
||||
Thank you for your interest. Please read this first — the workflow here is deliberately
|
||||
narrower than most repositories, and knowing that up front saves you wasted effort.
|
||||
|
||||
## Code of Conduct
|
||||
|
||||
Please read and follow our [Code of Conduct](CODE_OF_CONDUCT.md).
|
||||
|
||||
## Pull requests are not accepted
|
||||
|
||||
The pull-request tab is **switched off** on this forge, across every repository in the
|
||||
organisation. That is a published position, not an oversight: this project is solo-maintained,
|
||||
and an enabled-but-permanently-empty PR queue would promise a review capacity that does not
|
||||
exist.
|
||||
|
||||
Use **issues** instead. A well-argued issue carries the same information as a patch and costs
|
||||
you less to write.
|
||||
|
||||
## What belongs here, and what does not
|
||||
|
||||
This repository is the framework-neutral core. Before opening an issue, check which side of the
|
||||
boundary your point falls on:
|
||||
|
||||
| Your point is about | Raise it in |
|
||||
|---|---|
|
||||
| The normative specs, the example bundles, the golden fixtures | **here** |
|
||||
| Behaviour of the MAF implementation | [`portfolio-optimiser`](https://git.fromaitochitta.com/open/portfolio-optimiser) |
|
||||
| Behaviour of the Claude Agent SDK implementation | [`portfolio-optimiser-claude`](https://git.fromaitochitta.com/open/portfolio-optimiser-claude) |
|
||||
|
||||
A change that is true of only one of the two stacks does not belong here, however correct it
|
||||
is — that is the whole point of the shared core. See the Non-goals in the [README](README.md).
|
||||
|
||||
## Reporting an issue
|
||||
|
||||
Useful issues on a specification repository look different from bug reports on code. The most
|
||||
valuable ones name a specific place in the text:
|
||||
|
||||
- **Quote the section and the sentence**, not just a line number. Line numbers here go stale
|
||||
quickly; a section heading plus the wording you are reading survives an edit above it.
|
||||
- Say which of the two things you are claiming: that the specification is **internally
|
||||
inconsistent**, or that it is **inconsistent with an implementation**. They have different
|
||||
remedies, and conflating them is the most common way a report stalls.
|
||||
- For a fixture, state the input, the output you expected, and the output you got.
|
||||
|
||||
## If you are maintaining a consuming repository
|
||||
|
||||
Sync is **pull-only**, and all edits land here first:
|
||||
|
||||
```sh
|
||||
git subtree pull --prefix=shared commons main --squash
|
||||
```
|
||||
|
||||
**Never run `git subtree push` from a consuming repository.** The reason, and what it cost the
|
||||
one time it happened, is documented in the [README](README.md).
|
||||
|
||||
## Conventions
|
||||
|
||||
Commits follow [Conventional Commits](https://www.conventionalcommits.org/)
|
||||
(`type(scope): description`). Changes to normative text are ratified before they land; the
|
||||
reasoning behind each ruling is recorded in [`docs/plan/`](docs/plan/), including for the
|
||||
rulings that were later reversed.
|
||||
|
||||
## Questions?
|
||||
|
||||
Open an issue.
|
||||
21
LICENSE
Normal file
21
LICENSE
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
MIT License
|
||||
|
||||
Copyright (c) 2026 Kjell Tore Guttormsen
|
||||
|
||||
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.
|
||||
117
README.md
117
README.md
|
|
@ -1,25 +1,43 @@
|
|||
# shared/ — framework-neutral core
|
||||
# portfolio-optimiser-commons
|
||||
|
||||
This directory holds the parts of the project that are **independent of any AI agent
|
||||
framework** and are meant to be **shared, unchanged, between both reference
|
||||
implementations**:
|
||||
Framework-neutral shared core of the portfolio-optimiser method: the normative specs, example bundles and golden fixtures vendored by both reference implementations.
|
||||
|
||||
- **this repository** — the method built on Microsoft Agent Framework (MAF);
|
||||
- **a sibling repository** (built later, in sequence) — the same method on the
|
||||
**Claude Agents SDK**.
|
||||
[](LICENSE)
|
||||
|
||||
Sharing one identical core is what makes the two implementations a *fair comparison*:
|
||||
both consume the same concept, the same example data, and the same expected outcomes,
|
||||
so the only thing that differs is the agent framework itself.
|
||||
This repository is the **source of truth** for everything in the portfolio-optimiser method
|
||||
that is **independent of any AI agent framework**. It holds no runnable code — only
|
||||
normative specifications, example data, and expected outcomes.
|
||||
|
||||
## Contents (growing)
|
||||
Two reference implementations consume it, unchanged, as a `git subtree` at `shared/`:
|
||||
|
||||
- [`CONCEPT.md`](CONCEPT.md) — the business concept, written for a non-specialist
|
||||
(e.g. a business developer at another company).
|
||||
- [`portfolio-optimiser`](https://git.fromaitochitta.com/open/portfolio-optimiser) — the
|
||||
method on **Microsoft Agent Framework (MAF)**;
|
||||
- [`portfolio-optimiser-claude`](https://git.fromaitochitta.com/open/portfolio-optimiser-claude)
|
||||
— the same method on the **Claude Agent SDK**.
|
||||
|
||||
Sharing one identical core is what makes the two implementations a *fair comparison*: both
|
||||
consume the same concept, the same example data, and the same expected outcomes, so the only
|
||||
thing that differs is the agent framework itself. The second implementation is built from the
|
||||
specifications alone, without reverse-engineering the reference code.
|
||||
|
||||
## Contents
|
||||
|
||||
- [`method-spec.md`](method-spec.md) — the **normative method specification**, framework-neutral
|
||||
(the prose never names a concrete agent toolkit — enforced by a guard test): the 8-step loop,
|
||||
the verdict JSON contract, the inbox/outbox folder contract, the promotion-gate semantics, the
|
||||
IR projection + golden suite as the only ground truth, and the budget/provenance requirements.
|
||||
- [`ingest-spec.md`](ingest-spec.md) — the **normative ingest specification**, framework-neutral
|
||||
(same guard rule): the deterministic ingest step that materializes real data sources as OKF
|
||||
bundles BEFORE the loop — the polymorphic manifest schema (file/CSV, SQL, HTTP as extension
|
||||
point), the credential-reference rule, the verdict-layer reservation, the ingest provenance
|
||||
frontmatter with an explicit timestamp, the index-generation requirement, and the
|
||||
golden-extraction format.
|
||||
- [`CONCEPT.md`](CONCEPT.md) — the business concept, written for a non-specialist (e.g. a
|
||||
business developer at another company). Written in Norwegian.
|
||||
- [`examples/bygg-energi-mikro/`](examples/bygg-energi-mikro/) — the first example knowledge
|
||||
bundle (OKF / LLM-wiki): one office building, one LED-retrofit measure, with a seed expert
|
||||
verdict encoding the realization gap and a golden-suite of expected validator outcomes. A
|
||||
small **dev fixture** for exercising the agentic loop; a realistic full-scale example comes later.
|
||||
verdict encoding the realization gap and a golden-suite of expected validator outcomes. A small
|
||||
**dev fixture** for exercising the agentic loop; a realistic full-scale example comes later.
|
||||
- [`examples/nav-golden-hierarchy/`](examples/nav-golden-hierarchy/) and
|
||||
[`examples/nav-golden-escape/`](examples/nav-golden-escape/) — the **nav-golden** fixture class:
|
||||
`bundle/` in, `expected-read-context.md` out, exercising the navigation contract (method-spec §3
|
||||
|
|
@ -33,45 +51,52 @@ so the only thing that differs is the agent framework itself.
|
|||
framework-neutral Agent Skill: a `SKILL.md` persona prompt (energy-advisor / M&V role + the
|
||||
realization-gap methodology the validator cannot compute) and a canonical
|
||||
`references/example-verdict.json`. Both reference implementations instantiate the reviewer from
|
||||
this one artifact; `shared/` stays pure data (each stack reads the JSON with its own loader).
|
||||
- [`method-spec.md`](method-spec.md) — the **normative method specification**, framework-neutral
|
||||
(the prose never names a concrete agent toolkit — enforced by a guard test): the 8-step loop,
|
||||
the verdict JSON contract, the inbox/outbox folder contract, the promotion-gate semantics, the
|
||||
IR projection + golden suite as the only ground truth, and the budget/provenance requirements.
|
||||
The sibling implementation is built from this spec alone, without reverse-engineering the
|
||||
reference code.
|
||||
- [`ingest-spec.md`](ingest-spec.md) — the **normative ingest specification**, framework-neutral
|
||||
(same guard rule as the method spec): the deterministic ingest step that materializes real
|
||||
data sources as OKF bundles BEFORE the loop — the polymorphic manifest schema (file/CSV, SQL,
|
||||
HTTP as extension point), the credential-reference rule, the verdict-layer reservation, the
|
||||
ingest provenance frontmatter with an explicit timestamp, the index-generation requirement,
|
||||
and the golden-extraction format.
|
||||
this one artifact; this repository stays pure data (each stack reads the JSON with its own loader).
|
||||
- [`docs/plan/`](docs/plan/) — the decision record: how each ruling in the specifications above was
|
||||
arrived at, including the ones that were later reversed. Working documents, not normative, and
|
||||
written in a mix of Norwegian and English.
|
||||
|
||||
## Rules
|
||||
## Vendoring this repository
|
||||
|
||||
- **Nothing in here may import or depend on a specific agent framework.** If it does,
|
||||
it does not belong in `shared/`.
|
||||
- **Repo layout (decision R1, realized 2026-07-03):** the shared core lives in its own
|
||||
repository, [`portfolio-optimiser-commons`](https://git.fromaitochitta.com/ktg/portfolio-optimiser-commons)
|
||||
— the **source of truth**. Each implementation repo consumes it as a **git subtree**
|
||||
at this unchanged `shared/` path (so tests and the `PORTFOLIO_SHARED_ROOT` default
|
||||
resolver are unaffected). Do not edit commons content anywhere else without syncing.
|
||||
This repository is **vendored, not installed** — there is no package to add. Each consuming
|
||||
repository carries it as a `git subtree` under `shared/`, so the specs and fixtures are present in
|
||||
a normal checkout with no extra tooling.
|
||||
|
||||
## Subtree sync (pull-only — run from the consuming repo's root)
|
||||
Register the remote once, from the consuming repository's root:
|
||||
|
||||
The remote is registered as `commons`
|
||||
(`ssh://git@git.fromaitochitta.com/ktg/portfolio-optimiser-commons.git`).
|
||||
```sh
|
||||
git remote add commons https://git.fromaitochitta.com/open/portfolio-optimiser-commons.git
|
||||
git subtree add --prefix=shared commons main --squash
|
||||
```
|
||||
|
||||
**All edits land in commons first** (clone it, commit, push there), then each
|
||||
consuming repo pulls them in:
|
||||
Then pull updates with:
|
||||
|
||||
```sh
|
||||
git subtree pull --prefix=shared commons main --squash
|
||||
```
|
||||
|
||||
**Never run `git subtree push` from a consuming repo.** Observed 2026-07-03: because
|
||||
this repo's history contains commits that create/delete the `shared/` prefix, the
|
||||
push re-split leaked the consumer's *entire* history into commons (cleaned up by
|
||||
force-push the same day). Pull-only keeps commons the clean source of truth.
|
||||
**Sync is pull-only. All edits land here first** — commit and push in this repository, then pull
|
||||
them into each consumer.
|
||||
|
||||
See the target picture for the full architecture: `docs/plan/2026-06-26-maalbilde-agentic-loop.md`.
|
||||
**Never run `git subtree push` from a consuming repository.** Observed 2026-07-03: because a
|
||||
consumer's history contains commits that create and delete the `shared/` prefix, the push re-split
|
||||
leaked the consumer's *entire* history into this repository (cleaned up by force-push the same
|
||||
day). Pull-only keeps this repository the clean source of truth.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- **Not a runnable system.** No pipeline, no CLI, no package. The specifications describe
|
||||
behaviour; the two implementation repositories provide it.
|
||||
- **No framework dependency.** Nothing here may import or depend on a specific agent framework.
|
||||
If it does, it does not belong in this repository — that is what "framework-neutral" buys, and a
|
||||
guard test in each consumer enforces it for the two normative specs.
|
||||
- **Not a general-purpose knowledge-format standard.** The bundle layout follows the upstream Open
|
||||
Knowledge Format where it applies; this repository does not seek to replace or extend it beyond
|
||||
what the method needs.
|
||||
- **Not a home for implementation decisions.** Anything true of only one of the two stacks belongs
|
||||
in that stack's repository, not here.
|
||||
- **No inbound patches through this forge.** See [CONTRIBUTING.md](CONTRIBUTING.md).
|
||||
|
||||
## License
|
||||
|
||||
[MIT](LICENSE) © 2026 Kjell Tore Guttormsen
|
||||
|
|
|
|||
62
SECURITY.md
Normal file
62
SECURITY.md
Normal file
|
|
@ -0,0 +1,62 @@
|
|||
# Security Policy
|
||||
|
||||
## Reporting a Vulnerability
|
||||
|
||||
If you discover a security issue, please report it responsibly.
|
||||
|
||||
**Please do NOT report security issues through public issues.**
|
||||
|
||||
### How to Report
|
||||
|
||||
Email: hello@fromaitochitta.com
|
||||
|
||||
Include:
|
||||
- Description of the issue
|
||||
- Steps to reproduce
|
||||
- Potential impact
|
||||
- Any suggested fixes (optional)
|
||||
|
||||
### What to Expect
|
||||
|
||||
- Acknowledgment within 48 hours
|
||||
- Regular updates on progress
|
||||
- Credit in the fix announcement (if desired)
|
||||
|
||||
## What the attack surface here actually is
|
||||
|
||||
This repository ships **no executable code** — no package, no pipeline, no CLI. It contains
|
||||
normative specifications, example knowledge bundles, and golden fixtures. There is no dependency
|
||||
tree to keep patched and nothing here that runs on your machine.
|
||||
|
||||
That narrows the realistic reports to three kinds, and all three are worth sending:
|
||||
|
||||
1. **A specification that mandates unsafe behaviour.** The specs are binding on the
|
||||
implementations that consume them, so a weak rule propagates. The ingest specification in
|
||||
particular governs a boundary where untrusted external data enters the system: its
|
||||
credential-reference rule (manifests carry *references* to credentials, never the credentials
|
||||
themselves) and its verdict-layer reservation exist for this reason. A gap in that text is a
|
||||
real vulnerability report even though no code changes.
|
||||
2. **A secret or personal data in the repository or its history.** The example bundles are
|
||||
synthetic. If you find something that is not, report it — including in the git history, which
|
||||
is public in full.
|
||||
3. **A fixture that would make a consuming gate pass when it should fail.** The golden suites are
|
||||
the only ground truth the implementations check themselves against. A fixture that silently
|
||||
sanctions unsafe behaviour weakens every consumer at once.
|
||||
|
||||
## Supported Versions
|
||||
|
||||
| Version | Supported |
|
||||
| ------- | ------------------ |
|
||||
| latest | :white_check_mark: |
|
||||
| < latest| :x: |
|
||||
|
||||
Consumers vendor this repository as a `git subtree`, so a fix here reaches them only when they
|
||||
pull. If a report leads to a change in normative text, both reference implementations are
|
||||
notified — but their pull is their own action, on their own schedule.
|
||||
|
||||
## Scope Note
|
||||
|
||||
The portfolio-optimiser method is a **technical framework**. Deploying organizations own their
|
||||
own data protection, risk, and compliance assessments (DPIA/ROS). The specifications describe
|
||||
technical prerequisites (local-only operation, provenance, no silent egress) but make no
|
||||
compliance guarantees.
|
||||
|
|
@ -406,6 +406,23 @@ hvorfor: det finnes et ANDRE anker vi ikke siterte, og det er normativt.**
|
|||
> Et åpenbart tomt treff hadde vært tryggere. **Regel, samme klasse som `git log -S`-regelen
|
||||
> under: sitér SEKSJON + ORDRETT TEKST når mottakeren står på en annen ref — eller skriv
|
||||
> hvilken ref numrene gjelder.**
|
||||
>
|
||||
> **⚠️ Failure-moden er ikke lenger hypotetisk — den INNTRAFF (målt 2026-08-01).**
|
||||
> `portfolio-optimiser` stilte MCP-spørsmålet **på nytt** fem dager etter at det var avgjort
|
||||
> (`20260731T193214Z`), med S2.2 ført som blokkert på oss — nøyaktig utfallet avsnittet over
|
||||
> beskrev som «den mest sannsynlige konklusjonen». Kjennelsen var korrekt, allerede levert
|
||||
> (`20260726T190922Z`) og allerede ført her i §7.2; **det som ikke overlevde pull-grensen var
|
||||
> ankeret.** Svar sendt `20260801T175201Z` med begge refs oppgitt eksplisitt.
|
||||
>
|
||||
> To ting generaliserer, og de er verdt mer enn korreksjonen:
|
||||
>
|
||||
> 1. **Et feil linjeanker svikter STILLE.** Kostnaden er ikke at mottakeren blir forvirret —
|
||||
> den er at mottakeren *rimelig* konkluderer at kjennelsen din hviler på løs grunn, og
|
||||
> behandler et avgjort spørsmål som åpent igjen. Ingen av partene ser feilen; begge ser en
|
||||
> uenighet som ikke finnes.
|
||||
> 2. **Et spørsmål som kommer TILBAKE er et signal om VÅR formidling, ikke om deres hukommelse.**
|
||||
> Riktig første grep er ikke «det sa vi allerede», men å lese hva den forrige meldingen
|
||||
> faktisk bar (`~/.claude/coord/<dem>/archive/`). Feilen lå der.
|
||||
|
||||
`:29-31` sier at MCP-veien ikke krever spec-endring. `http`-punktet sier **normativt hvor den
|
||||
hører hjemme** — som en utvidelse av `http`-familien, med **MUST** på de samme kontraktene.
|
||||
|
|
|
|||
|
|
@ -730,3 +730,52 @@ etter den formuleringen finner 4 av 5 treff og står igjen med to like sannsynli
|
|||
O2. Tellingen «5 av 7» (§4.1, §5) står uendret — det var formen, ikke antallet, som var feil ført.
|
||||
|
||||
*Ingen normativ fil rørt av denne korreksjonen; `ingest-spec.md` står fortsatt på `bfa5a9b`.*
|
||||
|
||||
---
|
||||
|
||||
## 10. RATIFISERT 2026-08-02 — og en andre tabellrad som økt 6 ikke fanget
|
||||
|
||||
**Operatøren ratifiserte V1 2026-08-02**, ordrett: *«Jeg kan ta okf-kostnaden nå, men vi må
|
||||
starte i en ny sesjon.»* Utførelsen ligger dermed hos neste økt, ikke hos den som mottok
|
||||
vedtaket.
|
||||
|
||||
**Begge gater er oppløst, og den andre falt av seg selv.** okf-gaten var lukket fra før (pin
|
||||
`2504011`, økt 4). Ratifiseringsgaten er nå gitt. Den tredje betingelsen som har ligget i
|
||||
STATE — at V1 skulle vente på §9-amendment-pakken — var aldri en gate i egen rett: den var
|
||||
**batching** mot at endringen utløser `llm-ingestion-okf`s regenerering av fire DEFAULT-fasiter.
|
||||
Når operatøren tar den kostnaden nå, har batchingen ingenting å batche mot. V1 er frikoblet fra
|
||||
pakken, og S2.3 (`{type: "doc"}`, spurt `20260802T191837Z`) endrer ikke utfallet.
|
||||
|
||||
### Ankere re-målt 2026-08-02 (vår egen ferskvare-regel)
|
||||
|
||||
| Sted | Seksjon | Ordrett i dag | Behandling |
|
||||
|---|---|---|---|
|
||||
| `:34` | §1 Scope | «such (`generated: true` plus a manifest reference, §7) everywhere it is presented.» | prosa — mekanisk |
|
||||
| `:70` | §3 Layer separation | «the ingest stamp (`generated: true` plus an `ingest_manifest` reference, §7) and MUST NOT» | prosa — mekanisk |
|
||||
| `:82` | §3 Layer separation | «ownership stamp — `generated: true` together with an `ingest_manifest` reference — while» | prosa — mekanisk |
|
||||
| `:214` | §7 Provenance | «\| `generated` \| Literally `true` — the machine-generated marker (§1 honesty rule). \|» | feltrad — skriv om/splitt |
|
||||
| `:275` | §11 Load-bearing | «\| Stamp integrity (curated writers) \| … the complete ownership stamp (`generated: true` with `ingest_manifest`) stops being rejected … \|» | **rød-betingelse** |
|
||||
|
||||
### Korreksjonen: det er TO tabellrader, ikke én
|
||||
|
||||
Økt 6 korrigerte «de 5 linjene» fra homogene til 4 + 1 og pekte ut `:214`. Re-målingen viser at
|
||||
korreksjonen selv var ufullstendig: **`:275` er også en tabellrad, og den står i §11s
|
||||
load-bearing-tabell.** Det er ikke prosa som beskriver stempelet — det er en **rød-betingelse i
|
||||
konformanskontrakten**. Å endre den endrer hva en konformant implementasjon må bevise, og er
|
||||
derfor en sterkere handling enn å redigere §1- og §3-prosaen.
|
||||
|
||||
De «fire mekaniske» er i praksis **tre** (`:34`, `:70`, `:82`). `:214` og `:275` krever hver sin
|
||||
vurdering. `:152` og `:309` overlever (feltnavn, ikke literal).
|
||||
|
||||
Dette er andre gang en verifiseringsrad i denne planen påsto homogenitet som ikke fantes. Regelen
|
||||
står: **sjekk hva linjene FAKTISK bærer — og hvilken tabell de står i — før noe føres som
|
||||
mekanisk.**
|
||||
|
||||
### Varslingsplikt, utløst av utførelsen
|
||||
|
||||
Endringen utløser den lovede meldingen til `llm-ingestion-okf` — den setter i gang deres
|
||||
regenerering av de fire DEFAULT-fasitene. Den sendes i **samme økt** som tekstendringen, ikke
|
||||
senere. `portfolio-optimiser-claude` varsles samtidig; de vet ennå ikke at id-en er
|
||||
`process:okf-ingest`.
|
||||
|
||||
*`ingest-spec.md` er fortsatt urørt på `bfa5a9b` i det dette skrives.*
|
||||
|
|
|
|||
83
docs/plan/2026-08-02-ss11-mangler-rad-for-ss8.md
Normal file
83
docs/plan/2026-08-02-ss11-mangler-rad-for-ss8.md
Normal file
|
|
@ -0,0 +1,83 @@
|
|||
# Funn-notat — §11 ankrer ikke §8 (og heller ikke §10)
|
||||
|
||||
**Status:** FUNN, registrert. **Ikke et underlag, ikke et forslag, ikke bestilt.**
|
||||
Køplassering er operatørens. Commons forbereder underlaget, operatøren ratifiserer — og vi
|
||||
bestiller ikke vår egen kø, heller ikke for funn vi selv gjør.
|
||||
|
||||
**Foranledning:** `portfolio-optimiser` meldte 2026-08-01 (`20260801T175832Z`) at `method-spec.md`
|
||||
§11 mangler en rad for deres portefølje-brede budsjettsøm (S3.4/F10: globalt token-tak håndhevet
|
||||
før kall, wave-admission med reservasjon, oppstartsnekt). Undersøkelsen av den forespørselen ga
|
||||
to atskilte resultater, og bare det ene er vårt.
|
||||
|
||||
---
|
||||
|
||||
## 1. Forespørselen: avvist på akse
|
||||
|
||||
§1 (Scope and conformance) definerer metoden ordrett som «a swarm of agents generates candidate
|
||||
cost-saving measures for **one project at a time**». §8 (Budget and stop criteria) er følgelig
|
||||
den **per-run** termineringskontrakten.
|
||||
|
||||
Globalt tak på tvers av prosjekter, wave-admission med reservasjon og oppstartsnekt for et
|
||||
prosjekt som ikke kan finansieres er **orkestrering over metoden**, ikke en søm i den. Deres
|
||||
S3.4/F10 er riktig plassert hos dem, og at de bærer den som
|
||||
`tests/test_portfolio_budget_loadbearing.py` (6 målte røde mutasjoner) er sømmen dokumentert der
|
||||
den hører hjemme.
|
||||
|
||||
Konsekvensen av å legge raden inn likevel er konkret og var avgjørende: §11 er en MUST-tabell.
|
||||
En konformant implementasjon som kjører ett prosjekt uten portefølje-orkestrering ville blitt
|
||||
**ikke-konform på en søm spec-ens egen scope-klausul ikke governerer**.
|
||||
|
||||
Svar sendt `20260802T190344Z`.
|
||||
|
||||
## 2. Det undersøkelsen faktisk fant, og det er vårt
|
||||
|
||||
§11 har **tolv rader**. Ingen av dem ankrer **§8**:
|
||||
|
||||
- fail-closed når `usage` mangler i et svar (MÅ feile, aldri stille slutte å telle),
|
||||
- det strukturerte stop-eventet med breached kind + limit + observed value,
|
||||
- cap-objektenes nekt av ikke-positive verdier.
|
||||
|
||||
**§10** (Startup contracts) har heller ingen rad.
|
||||
|
||||
Samtidig sier §1 punkt 3 ordrett:
|
||||
|
||||
> proves **every** load-bearing seam with a test that FAILS when that seam is detached (§11).
|
||||
|
||||
Enten er §11-tabellen enumereringen av «every» — og da mangler §8 og §10 — eller så er den det
|
||||
ikke, og da har «every» ingen enumerering i spec-en. **Spenningen er intern i vår egen frosne
|
||||
tekst.** Den er vår å løse, ikke konsumentens.
|
||||
|
||||
## 3. Verifisering (målt, ikke antatt)
|
||||
|
||||
```
|
||||
$ sed -n '421,435p' method-spec.md | grep -ciE 'budget|token|meter|usage|cap|startup|max_rounds'
|
||||
1
|
||||
```
|
||||
|
||||
Det ene treffet er en **substring-falsk-positiv**: «es**cap**ing» i navigasjons-raden. Reelt
|
||||
antall §11-rader som nevner budsjett, måler eller oppstart er **null**.
|
||||
|
||||
```
|
||||
$ sed -n '423,434p' method-spec.md | grep -c '^|'
|
||||
12
|
||||
$ sed -n '24p' method-spec.md
|
||||
3. proves every load-bearing seam with a test that FAILS when that seam is detached (§11).
|
||||
```
|
||||
|
||||
## 4. Åpent spørsmål stilt til `portfolio-optimiser`
|
||||
|
||||
Av de 6 målte røde mutasjonene i `test_portfolio_budget_loadbearing.py` — hvor mange treffer
|
||||
**per-run-målerens** søm (usage mangler → feil; cap krysses → strukturert stop), og hvor mange
|
||||
treffer portefølje-admissionen? Den første halvdelen er in-scope for §8 og kunne vært
|
||||
referansetest-kolonnen i en rad vi faktisk kan skrive. Den andre halvdelen forblir deres.
|
||||
|
||||
Ubesvart per 2026-08-02. Ingen purring — de sa selv at det ikke blokkerer noe hos dem.
|
||||
|
||||
## 5. Hva som IKKE er gjort her
|
||||
|
||||
- Ingen rad er skrevet.
|
||||
- Ingen ordlyd er foreslått.
|
||||
- `method-spec.md` er ikke rørt.
|
||||
|
||||
En §8-rad ville vært en endring i frossen, subtree-konsumert tekst og krever operatørens
|
||||
ratifisering på lik linje med V1.
|
||||
Loading…
Add table
Add a link
Reference in a new issue