Repository navigation
chore(deps): bump qs from 6.15.3 to 6.16.0 in /apps/web-console - #1714
Merged
sakibsadmanshajib merged 1 commit intoSep 2, 2026
Merged
Conversation
Bumps [qs](https://github.com/ljharb/qs) from 6.15.3 to 6.16.0. - [Changelog](https://github.com/ljharb/qs/blob/main/CHANGELOG.md) - [Commits](ljharb/qs@v6.15.3...v6.16.0) --- updated-dependencies: - dependency-name: qs dependency-version: 6.16.0 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
sakibsadmanshajib
added
internal
Owner
|
Triage recommendation: safe to merge, low risk, no rush. This is a lockfile only patch bump of qs inside apps/web-console with no package.json change and no runtime surface of ours touching it directly. Merge whenever the queue is quiet, or batch it with the other web-console dependency bumps after the demo. |
sakibsadmanshajib
deleted the
dependabot/npm_and_yarn/apps/web-console/qs-6.16.0
branch
September 2, 2026 19:26
sakibsadmanshajib
added a commit
that referenced
this pull request
Sep 2, 2026
#1727) Closes #1726 Implements the tracking discipline the owner asked for on 2026-09-02: pull requests, milestones, the Kanban board and the labels are not being maintained, so this writes the rule down and then wires it so it is enforced rather than aspirational. ## The rule `.claude/rules/tracking-discipline.md`, in the voice of its neighbours in that directory, terse and imperative with each reason given once: - **An issue exists before a fix does.** Every change starts from a GitHub issue, including a one line fix noticed while doing something else. A defect discovered mid task gets filed, not folded silently into an unrelated pull request. The body links its issue with `Closes #N`, or `Refs #N` when it delivers only part of it. Never `Closes` an issue whose acceptance criteria are not all met, because an issue closed early is how work is lost. - **Exactly one priority label**, using the four that already exist in the repository: `priority:critical` for a demo blocker or live outage, `priority:high` for needed before the demo, `priority:medium` for real work to schedule, `priority:low` for correct but not urgent. The retired `priority:P0` through `priority:P3` set does not satisfy it, and is rejected by name so it gets corrected rather than quietly counted. - **At least one area label** from `demo-surface`, `money-path`, `internal`. Their definitions live on the labels themselves and are deliberately not copied into the rule. - **A scheduled issue carries a milestone**, from the four open ones. No milestone means unscheduled, which is legitimate; a critical or high with no milestone is a tracking failure, because it claims urgency and names no release that carries it. - **Pull requests wear the labels of the issue they close**, so the board reads the same from either side. - **Priority is judged against the demo spine**: chat, embeddings, voice to text, knowledge work, Cowork, the coding agent. Breaking one of those on stage is critical regardless of diff size; an internal correctness issue is not critical however elegant the fix would be. - **The orchestrator re-triages every session**: unlabelled open issues, priorities that no longer match reality, and pull requests older than two weeks. A backlog that is not navigable by priority is the same as no backlog. ## The enforcement `scripts/check-pr-tracking.py` reads the pull request body and every issue it links, and fails when: 1. the body links no issue, using the documented verbs. A bare `#N` in prose is deliberately not a link, since bodies in this repository cite issue numbers in passing constantly and counting those would pass everything; 2. a linked issue carries no valid priority label, or carries two, or carries only a retired one; 3. a linked issue carries no area label; 4. a linked `priority:critical` or `priority:high` issue has no milestone; 5. the pull request does not carry the priority and area labels of an issue it closes; 6. a link points at a pull request rather than an issue, or the target cannot be read. An unreadable target fails rather than passing quietly. `.github/workflows/pr-tracking-gate.yml` runs it on every pull request. It is cheap by construction: checkout plus two python invocations, no toolchain, no network beyond the GitHub API. It listens for `edited`, `labeled` and `unlabeled` on top of the four types the merge gate requires, because every way to fix a failure of this gate is one of those three events, and a gate whose green state cannot be reached without an unrelated commit gets worked around rather than satisfied. It is deliberately not a step in `ci.yml` and not affected by that workflow's docs-only allow-list. That list decides whether the heavy suite runs; this gate has to run on a documentation-only pull request too, since a documentation change needs an issue exactly as much as a code change does. Folding it into `repo-policy-lints` would also mean giving that job `issues: read`, which the rest of it has no business holding. ## Can it be bypassed Two answers, both honest. **By branch protection, no, once the config is applied.** `PR is attached to a triaged issue` is added to `required_status_checks.contexts` in `.github/branch-protection-main.json`, and `.github/ci/lint-workflow-check-names.mjs` already verifies on every pull request that the context has exactly one producer, in an `if: always()` job, in a workflow with no trigger path filter that reacts to `ready_for_review`. It reports seven required contexts green on this branch. **That file is only the checked in copy.** Applying it to live branch protection still needs the documented call, which the orchestrator runs after merge: ```bash gh api -X PUT repos/sakibsadmanshajib/hive/branches/main/protection \ -H "Accept: application/vnd.github+json" \ --input .github/branch-protection-main.json ``` Until that runs, the gate is red on a non-compliant pull request but does not block the merge API. One operational note for when it does run: an already-open pull request will not publish the new context until some event fires on it, so nudge the open ones rather than assuming they are stuck. **By a determined author, yes, in one specific way.** The gate confirms that an issue is referenced and that the issue is triaged. It cannot confirm the link is honest: `Refs #N` pointing at any well labelled issue passes. That gap is unfixable by a linter, which is why the rule is addressed to the agent writing the pull request and the gate only catches the accident. This is stated in the rule file itself rather than left for someone to discover. The two carve-outs are narrow and printed in the run log rather than applied silently: Dependabot, which cannot file an issue and whose updates would otherwise stall until a human wrote one, and a pull request whose entire diff is `.wolf/buglog.jsonl`, which is the buglog-only pull request `.claude/rules/openwolf.md` mandates for a fix that already had its own issue. One extra file and the buglog carve-out is gone, so it cannot be used to attach an unrelated diff to an exempt path. ## Verification - `python3 scripts/test_check_pr_tracking.py` passes. Every assertion that matters is a negative one: an untracked body, an unlabelled issue, a retired `priority:P1`, two priorities at once, a missing area label, a critical with no milestone, a pull request missing its closed issue's labels, a link pointing at a pull request, an unreadable issue. It is registered in `make test-scripts`, so it runs inside the required `Repo policy lints (tenant + audit)` job and the comparator cannot silently stop being able to fail. - `node .github/ci/lint-workflow-check-names.mjs` reports `Merge-gate integrity OK: 36 check names across 15 pull-request workflows, 10 required contexts each published by exactly one always()-running job in a workflow with no trigger path filter that reacts to every pull_request type the merge gate needs.` - Run against three live pull requests, not fixtures. #1714 exits 0 as an exempt Dependabot update. #1712 and #1709 each exit 1 with the real finding that they close a labelled issue whose labels they do not carry, which is precisely the drift the owner named. ## Review follow ups Four findings from the CodeRabbit pass, all taken: - A full issue URL was matched for its number alone, so `Closes https://github.com/someone-else/repo/issues/7` passed whenever this repository had a triaged issue 7. `links()` now takes the repository it is validating and skips a URL pointing elsewhere; a bare `#N` is untouched, since a bare number is always local. A body linking only foreign issues now fails with that reason instead of the vaguer "links no issue". - The Dependabot carve out matched any author ending `[bot]` or starting `app/`, which handed the bypass to every other app installed on the repository. It is now an explicit list of the Dependabot identities GitHub reports. - `oauth-scope-gate.yml` said branch protection lists seven required contexts. It lists ten. - `CLAUDE.md` said an issue carries one area label. The rule and the validator both allow more than one, so it now says at least one. Regression cases for the first two: a foreign URL rejected beside the same URL shape pointed here and accepted, and six non-Dependabot bot and app authors that get no exemption. `python3 scripts/test_check_pr_tracking.py` passes. ## Billing gate evidence CodeRabbit asked for test evidence under the rule that changes touching billing need it. This diff contains no billing, credits, payments, auth or tenancy code: `git diff origin/main...HEAD --name-only` is eleven files, all of them workflows, documentation, `scripts/check-pr-tracking.py` and its test, and `tools/verify-spec-wiring.mjs`. What it does touch is *when* the `Refuse to bill a paid completion alias` step in the `live-integration` job executes, so that is what the evidence below is about. The condition did not change. It moved, verbatim, from the job's own `if:` to a `gate` step whose output every step then reads: ``` needs.changes.outputs.run == 'true' && (github.event_name == 'push' || github.event_name == 'schedule' || (github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository && contains(github.event.pull_request.labels.*.name, 'run-live-integration'))) ``` Disabled path, executed. Run 33675965786 on commit `f95b60b`, this pull request, which carries no `run-live-integration` label: `Live integration (SDK tests + smoke)` concluded success in 6 seconds with the guard step and every other real step skipped. Before this change the same pull request produced no check run for that context at all, which is the reason for the conversion. Enabled path, not executed here, and deliberately so: it spends a provider allowance and is opt in by label. Two pieces of evidence stand in for it. First, the same gate-step pattern in the same workflow and the same run did take the enabled branch for the two other converted jobs, `Agent console (type + unit + build)` in 35 seconds and `Web E2E (full stack)` in 6 minutes 20, both of which run their steps only when their gate output is `true`. Second, the push to `main` that merging this creates is itself an enabled-path run, since `github.event_name == 'push'` satisfies the first arm, and it fails loudly if the guard stopped running. The guard's own coverage is unchanged and still enforced from the Go side by `TestNoCISurfaceCallsAPaidCompletionModel` in `apps/control-plane/internal/routing/ci_paid_model_guard_integration_test.go`, which runs in `Go tests (control-plane)` and passed on this branch. ## Also in this diff `.github/MERGE-POLICY.md` lists all ten required contexts, nine from `ci.yml` and the tracking gate, and its note that `ci.yml` is the only workflow allowed to publish a required check is corrected. The stale count in `oauth-scope-gate.yml` becomes ten. `CLAUDE.md` gains a two sentence pointer beside the orchestrator contract and duplicates none of the rule. No `.wolf/` file is touched. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added pull request tracking validation requiring links to triaged issues with appropriate priority and area labels. - Added automatic checks for required milestones on urgent issues and matching pull request labels. - Added limited exemptions for automated pull requests and bug-log-only changes. - **CI & Workflow Improvements** - Added the tracking validation as a required status check. - Required additional console, integration, and end-to-end checks for the main branch. - Updated checks to report clear results even when changes do not affect their areas. - **Tests** - Added coverage for tracking validation and exemption scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Fable 5.1 <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 qs from 6.15.3 to 6.16.0.
Changelog
Sourced from qs's changelog.
Commits
bb9379ev6.16.062fd254[Fix] stringify: serialize Date values when a filter is provided8859c37[Fix]parse: enforcearrayLimiton comma groups under[]=when `throwOn...8079adc[Tests]parse: remove a test that pinned[]=comma groups escaping `array...d56f48c[Fix]parse: flatten a collection appended to an overflowed arraye83d321[Fix]utils:isBuffer: do not invoke a non-callableconstructor.isBuffer7e87a07[Dev Deps] update@ljharb/eslint-config,eslint9a76af2[Dev Deps] updateeslint,evalmd3a890d4[Dev Deps] updateeslint,evalmdb433a9b[Fix]stringify: do not letallowEmptyArraysskip cycle detection (or dro...Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.