chore(deps-dev): Bump typescript from 5.9.3 to 7.0.2 in /services/mcp-public-gateway - #148
Open
dependabot[bot] wants to merge 1 commit into
Conversation
dependabot
Bot
added
dependencies
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/services/mcp-public-gateway/typescript-7.0.2
branch
from
July 26, 2026 11:26
3be4186 to
a746088
Compare
Owner
|
🔒 Held — not declining; kept open for rebase. What breaks (reproduced): Revisit when: |
Bumps [typescript](https://github.com/microsoft/TypeScript) from 5.9.3 to 7.0.2. - [Release notes](https://github.com/microsoft/TypeScript/releases) - [Commits](https://github.com/microsoft/TypeScript/commits) --- updated-dependencies: - dependency-name: typescript dependency-version: 7.0.2 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/services/mcp-public-gateway/typescript-7.0.2
branch
from
August 1, 2026 20:32
a746088 to
8e6b090
Compare
letuhao
added a commit
that referenced
this pull request
Aug 11, 2026
The listing is exact -- 10 runs against the database's own count of 10 -- and an unknown book gives the uniform deny. The finding is a contrast worth generalising. This tool declares its bound in the schema (limit: minimum 1, maximum 100), so out-of-range values are rejected before the handler runs, with a message that names the field and echoes the value: "you sent ...". That is exactly the affordance #148 had to add by hand for malformed uuids, and here it costs nothing but declaring the constraint. Compare #158's arc_template_list, whose description says "1..100" in prose while declaring no minimum or maximum: there limit=0 is silently clamped to 1 and the caller is never told. Same parameter, same service, two outcomes, and the whole difference is whether the bound is in the schema or only in a sentence. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
letuhao
added a commit
that referenced
this pull request
Aug 11, 2026
composition_authoring_run_review with unit_index=-1 against its declared minimum:0 answered "Input should be greater than or equal to 0 (you sent a int)". "a int" is a fact the caller already had; the one it needed was -1. loreweave_mcp's validation_directive rendered type(input).__name__ for every non-missing error -- even though its own docstring keeps that clause precisely because "input really is the offending value". It had the value and printed its type. Fixed in the kit with _render_input: show repr(value), falling back to a type-and- length summary past 80 chars so a refusal never pastes a document back at the model. This is the affordance #148 hand-rolled inside composition-service for uuids, except here it lives in the one place every Python MCP service reads. Two existing kit tests pinned the old "you sent a str" wording. They encoded the right intent -- a non-missing error keeps a value clause -- so they assert the value now rather than being deleted. The earlier missing-field guard still holds: a "missing" error must never describe a value it did not receive, and a test pins that the sharper rendering did not resurrect that bug. The tool itself is sound: all four ops delegate with their legacy messages intact, and accept_unit on a closed run names the whole legal state SET rather than one state. Live: "you sent -1". Kit suite 1028 green, composition 3625 green. Stated because it is easy to over-claim: the kit fix reaches jobs-, knowledge- and translation-service too, but only composition-service was rebuilt here, so only its improvement is measured. The others carry the old rendering until redeployed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
letuhao
added a commit
that referenced
this pull request
Aug 11, 2026
…ight op=update_spec must tell "field omitted" (leave alone) apart from "field explicitly null" (clear), and both were measured: after setting pov_anchor and canon_rule, updating taxonomy alone left both intact, and passing pov_anchor:null cleared that field while canon_rule survived. That is the hard case with pydantic, it is what exclude_unset exists for, and it is exactly what arc_template_edit collapsed before #155. The safety guards hold on both destructive ops: archive and restore against the canonical Work are each refused with NOT_A_DERIVATIVE naming the op, rather than one generic sentence. Restoring the derivative #161 deliberately left archived brought it back. Small note: pov_anchor is declared a plain string but must be an entity UUID. Sending a name answered "pov_anchor must be a UUID -- received 'Nguyet'" -- #148's helper doing its job, so the caller self-corrects in one round trip. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
letuhao
added a commit
that referenced
this pull request
Aug 11, 2026
Measured against scope=mine: no q gives 20 rows, q="zzznomatch" gives 20 rows in a different order, kind="situation" gives 7. So kind subtracts and q does not. I nearly filed this as #141's dead-filter defect. It is the opposite. _rank_by_query documents a deliberate change -- "a WHERE clause can only ever SUBTRACT ... searching `witness contradicts testimony` returned 0 rows while `mystery.witness_who_lies` sat right there ... move q from FILTER to RANK" -- with a literal hit outranking a semantic one so the change is purely additive. Reading the query before writing the finding is what turned an invented defect into a real one. The real defect was the sentence: the description listed q among the filters. The two readings lead to opposite conclusions from the same response -- believing q filters, twenty unrelated-looking rows read as a bug, or the caller trusts everything returned matches. Corrected to say which arguments subtract, that q ranks, that a non-matching query still returns rows, and that an exact name or code hit sorts first. Also recorded: calling the tool with no arguments is refused even though every parameter is optional -- the flat-args wrapper artefact from #148, affecting every args-model tool in this service rather than this one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Bumps typescript from 5.9.3 to 7.0.2.
Release notes
Sourced from typescript's releases.
Commits
Maintainer changes
This version was pushed to npm by microsoft1es, a new releaser for typescript since your current version.