feat(gstack2): consolidated runtime — execution-result contract, profiles, capability readiness, hardening#10
Merged
Conversation
Reconcile the four integrated v2 runtime implementations (unified execution result contract, execution profiles, capability readiness, GitHub security) with main's browser-provider hardening. Conflict resolutions: - runtimeContract() generator: keep new execution-result + doctor-capability paragraphs, adopt main's `[matching browser flags]` fallback wording; regenerate the six RUNTIME.md. - package.json: keep the strict isolated test:gstack2 runner and marked 18.0.6 security bump; adopt main's playwright-core alias. - bun.lock: regenerated via bun install. - release-hardening.test.ts: adopt main's browser-provider assertions (resolveServerLaunchTarget, --browser managed smoke loop). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
New advisories landed after the integration work: fast-uri (High) and hono (3x Medium) picked up fixed releases, and a Medium surfaced on @hono/node-server. Bump the fast-uri and hono override pins to their fixed patch releases (3.1.3, 4.12.27), clearing four findings. The remaining @hono/node-server advisory is reachable only through the unused @modelcontextprotocol/sdk transitive (no source imports it, no Hono server is started); its only fix is a major bump the SDK pins against. Record that assessment in .osv-scanner.toml so the scheduled scan stays honest instead of alarming on an unreachable path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
27 issues found across 68 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="skills/ship/references/support/execution-result-contract.json">
<violation number="1" location="skills/ship/references/support/execution-result-contract.json:34">
P2: Schema consumers can accept whitespace-only `summary` or `evidence` that the runtime rejects as malformed, so the advertised shared contract disagrees with `validateExecutionResult`. Consider requiring a non-whitespace character (for example, `"pattern": "\\S"`) in both string schemas and updating `EXECUTION_RESULT_SCHEMA`, from which this file is generated.</violation>
</file>
<file name="skills/debug/references/EXECUTION-PROFILES.md">
<violation number="1" location="skills/debug/references/EXECUTION-PROFILES.md:6">
P3: The heading presents `smoke` as a profile name even though the required `Depth` field and `ExecutionProfile` contract only accept `readiness`. Naming this section `Readiness` would avoid emitting an unsupported `Depth: smoke` value.</violation>
<violation number="2" location="skills/debug/references/EXECUTION-PROFILES.md:12">
P3: Readiness runs outside `/review` are required to describe themselves as an incomplete “review,” which mislabels debug investigations and other specialist workflows. A dispatcher-neutral phrase such as “not a complete specialist workflow” would preserve the disclaimer without reporting the wrong activity.</violation>
</file>
<file name="skills/review/references/EXECUTION-PROFILES.md">
<violation number="1" location="skills/review/references/EXECUTION-PROFILES.md:8">
P2: Production or approved/landed operational work can match both Smoke/readiness and Deep, leaving the agent free to choose the weaker profile despite the canonical inference logic routing these states to Deep. The Smoke/readiness condition should explicitly exclude production, approved-PR, landed, and consequential/external-mutation states.</violation>
<violation number="2" location="skills/review/references/EXECUTION-PROFILES.md:10">
P1: A readiness run can report `ready` after required evidence is unavailable because that condition is categorized as a legal skip rather than a blocker. Unavailable required evidence should force `not-ready`; only demonstrably inapplicable source-conditional work should be skippable.</violation>
</file>
<file name="scripts/gstack2/test-suite.ts">
<violation number="1" location="scripts/gstack2/test-suite.ts:7">
P2: GStack 2 tests added with another supported test extension (`.tsx`, `.js`, `.mjs`, etc.) will silently be skipped by this suite. Matching the canonical free-test extensions here would keep `test:gstack2` aligned with `collectFreeTestFiles()`.</violation>
</file>
<file name="README.md">
<violation number="1" location="README.md:614">
P2: This troubleshooting command fails when pasted: the shell interprets each `|` as a pipeline, and canonical skill-only installs do not provide the `gstack` executable. Retaining the optional-runtime qualifier and showing one concrete capability with substitutions would make the instruction runnable.</violation>
</file>
<file name="skills/review/SKILL.md">
<violation number="1" location="skills/review/SKILL.md:30">
P2: The execution header can report `Depth` before the dispatcher reads the contract used to infer it, so routing may advertise an invalid profile or apply the profile only after dispatch. Consider moving the profile read and inference explicitly before the step-2 header emission.</violation>
</file>
<file name="lib/diagram-render/package.json">
<violation number="1" location="lib/diagram-render/package.json:10">
P3: The third-party inventory now misidentifies all three upgraded packages, so distributed license/provenance documentation no longer matches the bundle. Update `THIRD-PARTY-LICENSES.md` with these versions and re-verify their licenses as its update instructions require.</violation>
<violation number="2" location="lib/diagram-render/package.json:16">
P2: Override-only security bumps can leave the committed offline bundle stale while the normal drift checks pass, because `BUILD_INFO` and its tier-1 test track only direct dependencies. Include `pkg.overrides` in the build metadata/fingerprint and drift assertion so these pins enforce a rebuild too.</violation>
</file>
<file name=".github/workflows/scorecard.yml">
<violation number="1" location=".github/workflows/scorecard.yml:19">
P3: A stalled checkout, Scorecard scan, or upload can hold this scheduled runner until the platform limit because `analysis` has no job timeout. A bounded `timeout-minutes` would align this external-action workflow with the repository's other direct CI jobs.</violation>
<violation number="2" location=".github/workflows/scorecard.yml:42">
P2: A code-scanning upload failure also discards the downloadable `results.sarif` artifact because the later artifact step only runs after prior success. Adding an explicit failure-safe condition preserves the raw Scorecard output for diagnosis.</violation>
</file>
<file name="scripts/gstack2/execution-profiles.ts">
<violation number="1" location="scripts/gstack2/execution-profiles.ts:53">
P1: Production canary/monitoring routes can be downgraded to `readiness` because `highRisk` ignores the router's `deployed` and `release_stage: 'monitoring'` production signals. Treating those equivalent production representations as deep preserves the profile contract that production deployment requires stronger evidence.</violation>
</file>
<file name="runtime/doctor.js">
<violation number="1" location="runtime/doctor.js:254">
P2: A macOS iOS failure caused by missing CoreDevice tooling is routed to runtime reinstallation, which cannot fix `xcrun`. Distinguish repairable bundle failures from external prerequisite failures before requiring preview/install consent and choosing the next action.</violation>
</file>
<file name="skills/plan/references/RUNTIME.md">
<violation number="1" location="skills/plan/references/RUNTIME.md:28">
P2: Copying this readiness command invokes a shell pipeline instead of selecting one capability, typically ending with `command not found`. Showing one valid invocation and listing the alternative argument values separately keeps the documented command executable.</violation>
</file>
<file name=".github/workflows/ci-image.yml">
<violation number="1" location=".github/workflows/ci-image.yml:21">
P2: Queued image builds can still be silently canceled when three pushes/manual rebuilds overlap: `cancel-in-progress: false` protects the running build, but GitHub replaces the single pending run by default. Adding `queue: max` preserves the intended serialized builds and their per-SHA image tags.</violation>
</file>
<file name="skills/qa/references/RUNTIME.md">
<violation number="1" location="skills/qa/references/RUNTIME.md:28">
P2: The two `degraded` statuses have different semantics: capability readiness passed (`ok: true`), but its execution-result envelope remains non-success and exits 1. Qualifying the latter as “degraded readiness” and documenting the envelope mapping would prevent agents from treating all degraded tool results as usable success—or rejecting a usable capability outright.</violation>
</file>
<file name="skills/design/references/RUNTIME.md">
<violation number="1" location="skills/design/references/RUNTIME.md:28">
P2: Capability doctor can mutate managed-runtime state while reporting readiness: `runDoctor()` performs pending-upgrade recovery, which may rewrite the version pointer. Describing this command as non-mutating can cause callers to run recovery without informed expectations; either make doctor read-only or disclose this recovery side effect.</violation>
</file>
<file name="skills/debug/references/RUNTIME.md">
<violation number="1" location="skills/debug/references/RUNTIME.md:28">
P2: Capability doctor can mutate runtime state despite being documented as non-mutating: a pending upgrade causes `recoverPendingUpgrade()` to rewrite the active version pointer. Either make this path inspection-only or disclose the recovery mutation so callers do not rely on a read-only diagnostic.</violation>
</file>
<file name="scripts/gstack2/host-adversarial.ts">
<violation number="1" location="scripts/gstack2/host-adversarial.ts:628">
P2: New runs will still identify as harness v3 even though v3 previously accepted `quick` and this validator now rejects it, making `harness_version` insufficient to identify evaluation semantics. Bumping `HARNESS_VERSION` to 4 would preserve the retained-run provenance.</violation>
</file>
<file name="runtime/execution-result.js">
<violation number="1" location="runtime/execution-result.js:61">
P1: JSON rendering is not guaranteed for results accepted by the validator because `data` may contain `undefined`, `BigInt`, `NaN`, circular references, or other non-JSON values. Validate `data` recursively as a JSON value before accepting this host-neutral result so `--json` cannot omit, alter, or fail to serialize it.</violation>
<violation number="2" location="runtime/execution-result.js:65">
P2: Malformed factory input bypasses the execution-result error contract: null or omitted input throws a raw `TypeError` with no stable code. Guarding the input before dereferencing it preserves `EXECUTION_MALFORMED` for this public API path.</violation>
</file>
<file name="scripts/gstack2/types.ts">
<violation number="1" location="scripts/gstack2/types.ts:5">
P1: Readiness-routed workflows cannot persist their selected profile in durable runtime state because `WORKFLOW_DEPTHS` still accepts `quick` and rejects `readiness`. The runtime schema/help/tests should be aligned with `ExecutionProfile`, including migration compatibility for existing `quick` state.</violation>
</file>
<file name="package.json">
<violation number="1" location="package.json:73">
P2: Node 18 users still satisfy this package's engine contract, but the upgraded Anthropic SDK officially supports Node 20 LTS or later. Raising `engines.node` to `>=20.0.0` (or retaining a Node-18-compatible dependency set) would keep the published runtime contract accurate.</violation>
</file>
<file name="runtime/cli.js">
<violation number="1" location="runtime/cli.js:451">
P2: Re-running an effect completed by an older runtime or via `reconcile-applied` now fails with `EXECUTION_MALFORMED`, because those durable results are not execution-result envelopes. Wrapping legacy completed records in a success envelope preserves state compatibility and the at-most-once response.</violation>
<violation number="2" location="runtime/cli.js:497">
P3: Non-ASCII command output can be corrupted when a stream chunk ends in the middle of a UTF-8 code point, because each chunk is decoded independently. Accumulating Buffers or using a per-stream `StringDecoder` would preserve characters across chunk boundaries.</violation>
<violation number="3" location="runtime/cli.js:537">
P1: Successful effects now retain arbitrary command output—including possible credentials or private content—in durable project state, while repeated effects can make `state.json` grow without a run-level bound. Store only bounded, redacted metadata or an explicitly managed artifact reference rather than raw stdout/stderr.</violation>
</file>
Tip: instead of fixing issues one by one fix them all with cubic
Re-trigger cubic
|
|
||
| - Infer when: A narrow, reversible, pre-deployment or operational readiness decision needs bounded evidence; the requested claim is readiness, not completeness. | ||
| - Mandatory modules: Every selected specialist module remains mandatory. Run its entry gates and the smallest source-authorized evidence path that can answer the readiness question. | ||
| - Legal skips: Only source-declared conditional work whose condition is demonstrably false, or evidence unavailable after a named attempt. Never skip a STOP gate, approval boundary, reproduction/root-cause gate, or required physical-device/production evidence. |
There was a problem hiding this comment.
P1: A readiness run can report ready after required evidence is unavailable because that condition is categorized as a legal skip rather than a blocker. Unavailable required evidence should force not-ready; only demonstrably inapplicable source-conditional work should be skippable.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At skills/review/references/EXECUTION-PROFILES.md, line 10:
<comment>A readiness run can report `ready` after required evidence is unavailable because that condition is categorized as a legal skip rather than a blocker. Unavailable required evidence should force `not-ready`; only demonstrably inapplicable source-conditional work should be skippable.</comment>
<file context>
@@ -0,0 +1,28 @@
+
+- Infer when: A narrow, reversible, pre-deployment or operational readiness decision needs bounded evidence; the requested claim is readiness, not completeness.
+- Mandatory modules: Every selected specialist module remains mandatory. Run its entry gates and the smallest source-authorized evidence path that can answer the readiness question.
+- Legal skips: Only source-declared conditional work whose condition is demonstrably false, or evidence unavailable after a named attempt. Never skip a STOP gate, approval boundary, reproduction/root-cause gate, or required physical-device/production evidence.
+- Artifacts: A readiness record naming the exact scope, probes run, evidence and freshness, failures, skipped work with reasons, and the next standard/deep step.
+- Claims: Only ready/not-ready for the named bounded decision. Must say “Readiness profile — not a complete review.” Never claim comprehensive, fully verified, production-safe, or no issues found outside the inspected scope.
</file context>
Suggested change
| - Legal skips: Only source-declared conditional work whose condition is demonstrably false, or evidence unavailable after a named attempt. Never skip a STOP gate, approval boundary, reproduction/root-cause gate, or required physical-device/production evidence. | |
| - Legal skips: Only source-declared conditional work whose condition is demonstrably false. Evidence unavailable after a named attempt blocks a `ready` claim rather than becoming a successful skip. Never skip a STOP gate, approval boundary, reproduction/root-cause gate, or required physical-device/production evidence. |
| } else if (typeof value.code !== "string" || !/^[A-Z][A-Z0-9_]{2,63}$/.test(value.code)) { | ||
| return invalid("Non-success execution requires a stable error code"); | ||
| } | ||
| return Object.freeze({ ...value, evidence: Object.freeze([...value.evidence]) }); |
There was a problem hiding this comment.
P1: JSON rendering is not guaranteed for results accepted by the validator because data may contain undefined, BigInt, NaN, circular references, or other non-JSON values. Validate data recursively as a JSON value before accepting this host-neutral result so --json cannot omit, alter, or fail to serialize it.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At runtime/execution-result.js, line 61:
<comment>JSON rendering is not guaranteed for results accepted by the validator because `data` may contain `undefined`, `BigInt`, `NaN`, circular references, or other non-JSON values. Validate `data` recursively as a JSON value before accepting this host-neutral result so `--json` cannot omit, alter, or fail to serialize it.</comment>
<file context>
@@ -0,0 +1,92 @@
+ } else if (typeof value.code !== "string" || !/^[A-Z][A-Z0-9_]{2,63}$/.test(value.code)) {
+ return invalid("Non-success execution requires a stable error code");
+ }
+ return Object.freeze({ ...value, evidence: Object.freeze([...value.evidence]) });
+}
+
</file context>
|
|
||
| export const TREE_NAMES = ['plan', 'design', 'qa', 'debug', 'review', 'ship'] as const; | ||
| export type TreeName = (typeof TREE_NAMES)[number]; | ||
| export type ExecutionProfile = 'readiness' | 'standard' | 'deep'; |
There was a problem hiding this comment.
P1: Readiness-routed workflows cannot persist their selected profile in durable runtime state because WORKFLOW_DEPTHS still accepts quick and rejects readiness. The runtime schema/help/tests should be aligned with ExecutionProfile, including migration compatibility for existing quick state.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At scripts/gstack2/types.ts, line 5:
<comment>Readiness-routed workflows cannot persist their selected profile in durable runtime state because `WORKFLOW_DEPTHS` still accepts `quick` and rejects `readiness`. The runtime schema/help/tests should be aligned with `ExecutionProfile`, including migration compatibility for existing `quick` state.</comment>
<file context>
@@ -2,6 +2,7 @@ export const GSTACK2_BASE_SHA = 'bb57306d98c97011b0919c6132705a15b1579781';
export const TREE_NAMES = ['plan', 'design', 'qa', 'debug', 'review', 'ship'] as const;
export type TreeName = (typeof TREE_NAMES)[number];
+export type ExecutionProfile = 'readiness' | 'standard' | 'deep';
export type ModuleVisibility = 'primary' | 'internal';
</file context>
| @@ -27,7 +27,12 @@ import { | |||
| runExternalEffect, | |||
There was a problem hiding this comment.
P1: Successful effects now retain arbitrary command output—including possible credentials or private content—in durable project state, while repeated effects can make state.json grow without a run-level bound. Store only bounded, redacted metadata or an explicitly managed artifact reference rather than raw stdout/stderr.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At runtime/cli.js, line 537:
<comment>Successful effects now retain arbitrary command output—including possible credentials or private content—in durable project state, while repeated effects can make `state.json` grow without a run-level bound. Store only bounded, redacted metadata or an explicitly managed artifact reference rather than raw stdout/stderr.</comment>
<file context>
@@ -431,23 +489,81 @@ async function runExternalCommand(command, { cwd, env, stdout, stderr }) {
+ data: {
+ exitCode: 0,
+ executable: name,
+ stdout: captured.stdout,
+ stderr: captured.stderr,
+ },
</file context>
| || signals.failure_impact === 'critical' | ||
| || signals.mutation_scope === 'consequential' | ||
| || signals.external_mutation_authorized === true | ||
| || signals.deployment_state === 'production' |
There was a problem hiding this comment.
P1: Production canary/monitoring routes can be downgraded to readiness because highRisk ignores the router's deployed and release_stage: 'monitoring' production signals. Treating those equivalent production representations as deep preserves the profile contract that production deployment requires stronger evidence.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At scripts/gstack2/execution-profiles.ts, line 53:
<comment>Production canary/monitoring routes can be downgraded to `readiness` because `highRisk` ignores the router's `deployed` and `release_stage: 'monitoring'` production signals. Treating those equivalent production representations as deep preserves the profile contract that production deployment requires stronger evidence.</comment>
<file context>
@@ -0,0 +1,77 @@
+ || signals.failure_impact === 'critical'
+ || signals.mutation_scope === 'consequential'
+ || signals.external_mutation_authorized === true
+ || signals.deployment_state === 'production'
+ || signals.release_stage === 'approved-pr'
+ || signals.release_stage === 'landed';
</file context>
|
|
||
| Choose a profile from product stage, mutation authority, risk/evidence needs, and deployment state. Prompt keywords and a request to “be quick” are not routing evidence. A profile narrows or strengthens evidence; it never overrides a specialist’s binding question order, pressure, gates, mutation boundary, or exit behavior. | ||
|
|
||
| ## Smoke/readiness |
There was a problem hiding this comment.
P3: The heading presents smoke as a profile name even though the required Depth field and ExecutionProfile contract only accept readiness. Naming this section Readiness would avoid emitting an unsupported Depth: smoke value.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At skills/debug/references/EXECUTION-PROFILES.md, line 6:
<comment>The heading presents `smoke` as a profile name even though the required `Depth` field and `ExecutionProfile` contract only accept `readiness`. Naming this section `Readiness` would avoid emitting an unsupported `Depth: smoke` value.</comment>
<file context>
@@ -0,0 +1,28 @@
+
+Choose a profile from product stage, mutation authority, risk/evidence needs, and deployment state. Prompt keywords and a request to “be quick” are not routing evidence. A profile narrows or strengthens evidence; it never overrides a specialist’s binding question order, pressure, gates, mutation boundary, or exit behavior.
+
+## Smoke/readiness
+
+- Infer when: A narrow, reversible, pre-deployment or operational readiness decision needs bounded evidence; the requested claim is readiness, not completeness.
</file context>
| - Mandatory modules: Every selected specialist module remains mandatory. Run its entry gates and the smallest source-authorized evidence path that can answer the readiness question. | ||
| - Legal skips: Only source-declared conditional work whose condition is demonstrably false, or evidence unavailable after a named attempt. Never skip a STOP gate, approval boundary, reproduction/root-cause gate, or required physical-device/production evidence. | ||
| - Artifacts: A readiness record naming the exact scope, probes run, evidence and freshness, failures, skipped work with reasons, and the next standard/deep step. | ||
| - Claims: Only ready/not-ready for the named bounded decision. Must say “Readiness profile — not a complete review.” Never claim comprehensive, fully verified, production-safe, or no issues found outside the inspected scope. |
There was a problem hiding this comment.
P3: Readiness runs outside /review are required to describe themselves as an incomplete “review,” which mislabels debug investigations and other specialist workflows. A dispatcher-neutral phrase such as “not a complete specialist workflow” would preserve the disclaimer without reporting the wrong activity.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At skills/debug/references/EXECUTION-PROFILES.md, line 12:
<comment>Readiness runs outside `/review` are required to describe themselves as an incomplete “review,” which mislabels debug investigations and other specialist workflows. A dispatcher-neutral phrase such as “not a complete specialist workflow” would preserve the disclaimer without reporting the wrong activity.</comment>
<file context>
@@ -0,0 +1,28 @@
+- Mandatory modules: Every selected specialist module remains mandatory. Run its entry gates and the smallest source-authorized evidence path that can answer the readiness question.
+- Legal skips: Only source-declared conditional work whose condition is demonstrably false, or evidence unavailable after a named attempt. Never skip a STOP gate, approval boundary, reproduction/root-cause gate, or required physical-device/production evidence.
+- Artifacts: A readiness record naming the exact scope, probes run, evidence and freshness, failures, skipped work with reasons, and the next standard/deep step.
+- Claims: Only ready/not-ready for the named bounded decision. Must say “Readiness profile — not a complete review.” Never claim comprehensive, fully verified, production-safe, or no issues found outside the inspected scope.
+
+## Standard
</file context>
| "@excalidraw/excalidraw": "0.18.0", | ||
| "@excalidraw/mermaid-to-excalidraw": "1.1.2", | ||
| "mermaid": "11.12.2", | ||
| "@excalidraw/excalidraw": "0.18.1", |
There was a problem hiding this comment.
P3: The third-party inventory now misidentifies all three upgraded packages, so distributed license/provenance documentation no longer matches the bundle. Update THIRD-PARTY-LICENSES.md with these versions and re-verify their licenses as its update instructions require.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At lib/diagram-render/package.json, line 10:
<comment>The third-party inventory now misidentifies all three upgraded packages, so distributed license/provenance documentation no longer matches the bundle. Update `THIRD-PARTY-LICENSES.md` with these versions and re-verify their licenses as its update instructions require.</comment>
<file context>
@@ -7,10 +7,15 @@
- "@excalidraw/excalidraw": "0.18.0",
- "@excalidraw/mermaid-to-excalidraw": "1.1.2",
- "mermaid": "11.12.2",
+ "@excalidraw/excalidraw": "0.18.1",
+ "@excalidraw/mermaid-to-excalidraw": "2.2.2",
+ "mermaid": "11.16.0",
</file context>
|
|
||
| jobs: | ||
| analysis: | ||
| runs-on: ubuntu-24.04 |
There was a problem hiding this comment.
P3: A stalled checkout, Scorecard scan, or upload can hold this scheduled runner until the platform limit because analysis has no job timeout. A bounded timeout-minutes would align this external-action workflow with the repository's other direct CI jobs.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/scorecard.yml, line 19:
<comment>A stalled checkout, Scorecard scan, or upload can hold this scheduled runner until the platform limit because `analysis` has no job timeout. A bounded `timeout-minutes` would align this external-action workflow with the repository's other direct CI jobs.</comment>
<file context>
@@ -0,0 +1,46 @@
+
+jobs:
+ analysis:
+ runs-on: ubuntu-24.04
+ permissions:
+ contents: read
</file context>
Suggested change
| runs-on: ubuntu-24.04 | |
| runs-on: ubuntu-24.04 | |
| timeout-minutes: 30 |
| const remaining = maxCapturedBytes - captured.bytes; | ||
| if (remaining <= 0) { captured.truncated = true; return; } | ||
| const buffer = Buffer.from(chunk); | ||
| captured[key] += buffer.subarray(0, remaining).toString(); |
There was a problem hiding this comment.
P3: Non-ASCII command output can be corrupted when a stream chunk ends in the middle of a UTF-8 code point, because each chunk is decoded independently. Accumulating Buffers or using a per-stream StringDecoder would preserve characters across chunk boundaries.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At runtime/cli.js, line 497:
<comment>Non-ASCII command output can be corrupted when a stream chunk ends in the middle of a UTF-8 code point, because each chunk is decoded independently. Accumulating Buffers or using a per-stream `StringDecoder` would preserve characters across chunk boundaries.</comment>
<file context>
@@ -431,23 +489,81 @@ async function runExternalCommand(command, { cwd, env, stdout, stderr }) {
+ const remaining = maxCapturedBytes - captured.bytes;
+ if (remaining <= 0) { captured.truncated = true; return; }
+ const buffer = Buffer.from(chunk);
+ captured[key] += buffer.subarray(0, remaining).toString();
+ captured.bytes += Math.min(buffer.length, remaining);
+ if (buffer.length > remaining) captured.truncated = true;
</file context>
…eadiness A capability whose binary launches while the managed runtime hard-fails (e.g. skill-API mismatch) was reported as `degraded`/ok:true/exit 0, diverging from plain `gstack doctor` (ok:false/exit 1) for the identical report. Split the branch so runtime `warn` stays `degraded` and runtime `fail` maps to `failed`, and add a regression test for the runtime-fail + capability-pass case. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jul 21, 2026
There was a problem hiding this comment.
1 issue found across 5 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".osv-scanner.toml">
<violation number="1" location=".osv-scanner.toml:15">
P3: The permanent security exception records the dependency relationship incorrectly: `@hono/node-server` is a regular MCP SDK dependency constrained by `^1.19.9`, not a pinned peer dependency. Keeping the rationale precise will make later advisory reassessment less error-prone.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
| # (^1.19.9); forcing it via override risks breaking the SDK at runtime for a | ||
| # vulnerability we do not expose. Re-evaluate if the MCP SDK becomes a direct, | ||
| # server-hosting dependency. | ||
| reason = "Unreachable transitive (unused @modelcontextprotocol/sdk); fix requires a risky major override on a pinned peer dep." |
There was a problem hiding this comment.
P3: The permanent security exception records the dependency relationship incorrectly: @hono/node-server is a regular MCP SDK dependency constrained by ^1.19.9, not a pinned peer dependency. Keeping the rationale precise will make later advisory reassessment less error-prone.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .osv-scanner.toml, line 15:
<comment>The permanent security exception records the dependency relationship incorrectly: `@hono/node-server` is a regular MCP SDK dependency constrained by `^1.19.9`, not a pinned peer dependency. Keeping the rationale precise will make later advisory reassessment less error-prone.</comment>
<file context>
@@ -0,0 +1,15 @@
+# (^1.19.9); forcing it via override risks breaking the SDK at runtime for a
+# vulnerability we do not expose. Re-evaluate if the MCP SDK becomes a direct,
+# server-hosting dependency.
+reason = "Unreachable transitive (unused @modelcontextprotocol/sdk); fix requires a risky major override on a pinned peer dep."
</file context>
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.
Consolidates the parallel-agent GStack 2 runtime work into one review surface.
Supersedes the individual feature branches and PR #9.
What's included (5 commits)
execution-result-contract.jsonacrossreview,ship, and runtime skills.EXECUTION-PROFILES.md+RUNTIME.mdreferences wired into skills.test/gstack2-capability-readiness.test.tsand runtime install checks.Test evidence
bun test test/gstack2-*.test.ts test/release-hardening.test.ts→ 244 pass, 0 fail (23 files, 2495 assertions), run on this branch (cb1792f).Supersedes
Add-unified-execution-result-2) — folded in heretime-attack/Add-capability-readiness-process-2— folded in heretime-attack/Add-inferred-execution-profiles-2— folded in here🤖 Generated with Claude Code
Summary by cubic
Unifies the GStack 2 runtime around a single execution‑result contract and inferred execution profiles, adds focused capability readiness checks, and hardens the runtime and CI/security posture.
New Features
EXECUTION-PROFILES.md.gstack doctor --capability browser|design|diagram|pdf|ios; keeps judgment, platform, preview/install consent, and runtime readiness separate. Treats runtime warn asdegradedand hard runtime fail asfailed(not ready); docs indocs/gstack-2/CAPABILITY-READINESS.md.Dependencies
@anthropic-ai/sdk→^0.112.4,marked→^18.0.6; diagram renderer to@excalidraw/excalidraw@0.18.1,@excalidraw/mermaid-to-excalidraw@2.2.2,mermaid@11.16.0.fast-uri@3.1.3,hono@4.12.27; recorded unreachable@hono/node-serverpath in.osv-scanner.toml. Kept safe overrides (e.g.,dompurify,lodash-es,nanoid).standardwebhooks,@stablelib/base64, andfast-sha256.Written for commit 52a6101. Summary will update on new commits.