Repository navigation
feat(releases): support AI-DLC 2.11.0 - #583
Merged
Merged
Conversation
eipasteur
requested review from
JWThewes,
jeromevdl,
leandrodamascena and
svozza
as code owners
October 18, 2026 19:12
This was referenced Oct 19, 2026
eipasteur
changed the title
JWThewes
reviewed
Oct 19, 2026
JWThewes
left a comment
JWThewes
left a comment
Contributor
There was a problem hiding this comment.
@eipasteur One P2 remains in composer prompt budgeting. The expanded annex causes supported inputs to lose authoritative catalog context; the inline comment records identical-input before/after measurements and the required regression.
Comment on lines
+263
to
+267
| hasInvokeToken(persona, knowledge) | ||
| ? invokeDialectAnnex({ | ||
| toolless: true, | ||
| checkpointLogInvoked: invokesCheckpointLog(persona, knowledge), | ||
| }) |
Contributor
There was a problem hiding this comment.
[P2] Reserve the complete stage catalog when budgeting the enlarged annex
@eipasteur The larger annex is placed before grounding, while the overflow path at lines 284–292 cuts the end of that grounding after discarding persona/knowledge. This change makes ordinary stock grounding plus a supported maximum report excerpt exceed the budget, removing authoritative stages and dependency details while retaining the output contract that requires the complete catalog.
Reproduced with actual stock grounding and the accepted 24,576-character report excerpt, comparing identical inputs before and after this PR:
- 2.8.2 and 2.9.0: all 33 catalog rows were retained before; only 27 row starts remain afterward.
- 2.11.0: all 33 rows were retained by the pre-change builder with the same input; only 11 row starts remain afterward.
- The last retained row is partial, and the output contract is still present in each truncated prompt.
This demonstrates missing required context, not a claim about a particular model response. Please budget complete required grounding/catalog, mode task, intent and output contract before lower-priority text, compacting or bounding the latter to fit. Add prompt-construction regressions using real stock grounding and the maximum accepted report excerpt, asserting every catalog row remains complete and the full prompt stays within CONTEXT_LIMIT.
…ct annex 2.11's prompt bodies instruct fourteen engine commands this runtime has no engine for. Each becomes its own `INVOKE_FAMILY_FIDELITY` family, never folded into an existing one that shares a first word: three are approximated, because the platform has a real seam for them that the annex names, and eleven stay unsupported with an answer the annex gives by name. The approximated three carry `annexed: true` as well, so their answer is judged by the same reach as a refused one: the seam is the annex's own answer rather than an always-available engine, so a prompt that invokes one without receiving the annex is a session with no answer at all. They are not named in `ANNEX_HANDLED_ENGINE_COMMANDS`, which is read only for a gap that already carries `annexed` and which the four pre-2.11 approximated families do not appear in either. The fidelity-evidence revision moves with that classification, to 6. What the collector decides changed twice on top of revision 5: `feat/release-scope-policy` judges a scope policy value by its authored type and activates one only from a field a consumer reads, and these fourteen families are now classified in their own right. A fork registered while the previous build was running holds a list that LOOKS current at revision 5 and still carries the old blockers, so upgrading the platform did not make that existing registration promotable. Revision 6 makes promotion re-collect the evidence from the immutable closure for such a record, the same lazy re-verification the earlier revisions already rely on. The registry's own rule is that every collector change bumps it, so eligibility follows the closure and this runtime rather than the moment the row was written.
The three 2.11 approximated engine commands are kept out of the fidelity gaps because the dialect annex answers them, and that answer only arrives where a prompt carries the annex. Nothing pinned that reach for them, so a fork moving one of those invocations into a body no prompt builder annexes — a scope, a rule — would promote as selectable with an empty unhonoured list while the consuming session received the command and no answer at all. Pin it both ways on the real release: `engine now` added to a scope body, which the compose grounding renders and no builder gates on, is named in `unhonouredValues` and refuses promotion, while the same command added to the reviewer knowledge, whose prompts all carry the annex through the shared persona tail, is still honoured.
… has The log-answer / log-decision row told every session to ask with `ask_question` and confirm with `confirm_summary`. Tool registration withholds `confirm_summary` wherever the resolved policy asks for no summary confirmation, and withholds both from a session that does not own the stage's checkpoint — a dispatched support with no answer path, and every reviewer. The row therefore advertised tools that were deliberately never registered, which is the mismatch already fixed for `learnings: off` in the MCP annex. Render the mapping from the same three facts `toolsForRole` reads: the resolved policy, checkpoint ownership and whether the session can ask. A session with both tools keeps the row verbatim; one without the confirmation is told so and puts what it would have confirmed in its output; one that owns no checkpoint is told it cannot raise either, to record the question it would have put, and to defer to the owning session. The refusal half — no plan-approval fingerprint, no receipt, no approved verification command — is identical in every form. Only a prompt whose own bodies invoke those two commands has its row adapted, so a release that never invokes them keeps the annex verbatim and the prompt of every older pinned release is unchanged.
…ed machinery The support section described what 2.11 handles, approximates and refuses, but left the sensor caveat to a generic "a real subprocess was not proved" line. A reader could not tell that a 2.11 pin currently runs with document sensors routed by the wrong flag and split across sibling modules they never receive — including the first 2.11 linter that is not self-contained — with its authored 1,200-second code budgets cut to a 600,000 ms ceiling and without its timestamp-heading exemption. Those three differences are now named, with the advisory severity that keeps them from holding a stage. The reach paragraph described one reach where there are two: a refusal that names a platform channel needs the session that receives the answer to own that channel, while an approximation the session performs itself needs only a prompt that carries the annex. Both are stated, together with the body a fork cannot earn a reach claim from, and the checkpoint row now says it is rendered for the session that receives it. Three refusals in the plan are engine MACHINERY rather than commands — the Plan Approval state machine, the review-finding ledger and unit-preserving replans — so no command scanner reports them and the annex is the only place they can be answered. Each now has its named answer, pinned by test, instead of resting on the generic rules.
The reviewer's checkpoint mapping was fixed in the helper that builds its prompt, but the live path does not use that helper: `runReviewer` hands a brief to `dispatchPersona`, which composes the prompt itself and defaulted both checkpoint ownership and `ask_question` to true. MCP nevertheless selects the reviewer tool list by role, which has neither, so a release whose shared knowledge invokes `engine log answer` told the live reviewer to call a tool its own session does not register. The two facts are now derived from `toolsForRole` — the function that really registers the tools — rather than from a caller's defaults: a role whose surface has no checkpoint tool even under a policy demanding both, and no `ask_question`, cannot own them, so the prompt and the trusted MCP scope cannot disagree. The reviewer dispatch also forwards the stage's resolved policy, and its prompt builder no longer restates the flags the role already decides. An author-role session is unchanged: it owns the checkpoints, so only the resolved policy decides whether a summary confirmation exists.
The promotion guard marks an engine command answered when the dialect annex reaches a prompt that instructs it, and it counts the composer's persona and knowledge. The composer, however, runs one-shot with no MCP configuration at all, and it received the annex verbatim: a promoted fork whose composer invokes an audit or a checkpoint command was told to record it with a note tool, to ask with a question tool and to confirm with a summary tool, none of which exist in that session. Reach was claimed and delivery was not. The annex now has a tool-less form, rendered for the composer: every answer whose channel is a platform tool is rewritten onto the JSON proposal the composer returns — the `rationale` names the command and what could not be performed — and the checkpoint row says plainly that no checkpoint can be raised here and that a person must take the question on the intent. Every refusal is unchanged, and a session that HAS the tools keeps the tool-bearing answers, because the redirect is a property of the receiving session rather than of the release.
2.11.0 carried a support ceiling (`maxSupportState: 'selectable'`) that made the registry refuse `certified` with `release_certification_withheld`, and so also kept it off the `stable` channel. The reason given was that eleven engine commands it invokes are answered by the dialect annex rather than reproduced. That is the same situation 2.8.2 and 2.9.0 are in, and both stay certifiable. Encoding it as a profile ceiling turned a judgement into a hard refusal and singled out one release for a property its peers share. What this build handles, approximates and refuses for 2.11 is published; with that table in hand, whether the claim is worth making is the administrator's decision. Removes the ceiling from the v2.11.0 profile, the `maxSupportState` mechanism and its refusal from the release registry, and the ceiling wording from the compatibility doc. The handled/approximated/refused table is unchanged: it is the evidence the decision rests on. The tests that asserted the refusal are replaced by the promotion that is now allowed — 2.11.0 reaches `certified` like 2.9.0, and the `stable` channel may point at it once it does.
…mpt is over budget When a compose prompt did not fit, only the persona and knowledge were cut, and whatever still overflowed was cut from the end, which is where the grounding sits. With a stock 2.8.2+ persona, the engine-command annex and a full report excerpt, a 2.11.0 composer lost 27 of the 33 stage catalog rows the output contract asks it to cover. The required sections (annex, execution environment, mode task, intent, grounding and contract) are now kept whole, and the persona with its knowledge and the report excerpt share the remaining space, each cut with a marker. A prompt that fits is unchanged.
…ker does not fit When the room left for the persona and the report excerpt was smaller than a truncation marker, the cut section still carried the whole marker, so the prompt went over the limit and fell to the last resort that cuts the grounding. A cut section now keeps the marker alone when it fits and gives way entirely otherwise.
eipasteur
force-pushed
the
feat/aidlc-211-release
branch
from
October 21, 2026 14:07
c17b10b to
6fffe15
Compare
eipasteur
commented
Oct 21, 2026
eipasteur
left a comment
eipasteur
left a comment
Contributor
Author
There was a problem hiding this comment.
The finding is addressed, with a test:
- [P2] An over-budget compose prompt keeps every section the model must act on whole: the engine-command annex, the execution-environment note, the mode task, the intent, the grounding with its full stage catalog and the output contract. The persona with its knowledge and the report excerpt share the remaining space, each cut with a marker, and a cut never exceeds its share. With real 2.8.2, 2.9.0 and 2.11.0 grounding, a stock-size persona and the maximum report excerpt, all 33 catalog rows arrive complete within the limit. A prompt that fits is unchanged: 87c24da, 6fffe15
The branch is rebased on main now that #582 is merged.
JWThewes
approved these changes
Oct 21, 2026
jeromevdl
added
the
area/agents
jeromevdl
added
area/backend
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In short
A deployment of Collaborative AI-DLC cannot use AI-DLC 2.11.0 today: registering it is refused because the platform does not know the release. After this PR an administrator can register the official 2.11.0, promote it, and, if they choose, certify it and make it the default for new intents, exactly as for 2.8.2 and 2.9.0. Its eleven scopes load and the settings it introduces are honoured (they are read and applied by #581 and #582, which this PR builds on).
2.11's prompts ask the agent to run fourteen commands of the upstream AI-DLC engine, which does not run on this platform. Each one now has an explicit answer telling the agent what to do instead: three are done by the platform itself, and eleven are declined with an alternative and a rule never to invent a result. The full list is in the compatibility documentation, so an administrator can judge the release before promoting it.
Stacked on #582 (
feat/aidlc-211-intent-settings).What changes
6a378b53c0a4fe0641ed7d8de8dfff94264d5b6a, with a compatibility fixture generated from the real release files (every file checked against the upstream git tree). 2.10.0 is not added.Behaviour by release
Validation
Limitations and follow-ups
mainonce feat(releases): promote 2.8.2, 2.9.0 and compatible forks #521 is merged; two release-matrix assertions from fix(sensors): run a release's sensor scripts the way the release declares them #580 then need to cover 2.11.0.