Skip to content

release: reconcile Office and npm versions before next stable registry publication #118

Open

Description

@seonghobae

Stable-release operational acceptance

This issue is the canonical release-acceptance boundary for the next stable Inkspan publication. It intentionally does not embed a protected-main SHA, PR head SHA, workflow run ID, review count, release inventory count, or registry version as current truth. Those values are mutable and must be refetched immediately before every lifecycle decision.

Protected main is the only shipped-source authority. Source metadata is not registry-publication evidence, a branch ref is not a release identity, and predecessor or synthetic-merge workflow evidence never transfers to a new protected tip.

Mandatory live refetch

Before merge-to-release, tag, GitHub Release, npm/PyPI publication, issue closure, or any claim that the stable train is ready, independently refetch:

  • the exact protected main tip, verification, and ancestry;
  • the then-authoritative root and Office version metadata plus CHANGELOG.md;
  • the exact protected .github/workflows/release.yml and every asset/provenance rule it currently declares;
  • all open Inkspan PRs/issues that own release-blocking source, workflow, accessibility, dependency, package, or review work;
  • exact candidate heads and independently resolved live bases;
  • formal reviews and unresolved review threads;
  • all required CI/security/SAST/dependency/coverage/browser/Office/fidelity/accessibility/package/SBOM/provenance/reproducibility/rollback/operational workflows;
  • each required workflow job's actual checkout SHA and repository identity;
  • live repository/organization rulesets and protection;
  • any open organization-level merge-admission/ruleset-bypass incident that affects the protected lineage, including its audit-log / Rule Insights disposition and remediation status;
  • tags and GitHub releases;
  • public npm/PyPI state and, after publication, exact artifact digests/provenance.

Pending, queued, skipped, cancelled, absent, neutral, failed, stale, predecessor, status-only, model-only, wrong-checkout, synthetic-merge-only, or vacuous evidence is non-passing. An aggregate green status is insufficient when an underlying required path was skipped or consumed the wrong revision.

Existing owner lanes to refetch, not duplicate

Known release-related owner paths include Inkspan accessibility/product repair, the release-workflow stack, exact-head stacked-PR workflow evidence, and central review/security/merge-admission control-plane repairs. Historically these have included Inkspan PRs/issues such as #362, #285, #298/#299 and central .github owner paths #771, #814, #810/#897, and #1222/#941. Their current state, head, base, ownership, and continued applicability must be refetched; this list is routing context, not a status snapshot.

Do not create a competing Inkspan source writer when one of those live paths already owns the causal boundary. If a central/foreign defect still owns the first causal failure and no correct Inkspan-local remedy exists, advance that existing owner path with the exact affected source SHA, run/job, reproduction, falsifiable RCA, RED acceptance, smallest remedy, GREEN proof, and Inkspan-side revalidation.

Required dependency discipline

  1. Resolve protected-product correctness/accessibility blockers through their existing source owners.
  2. Resolve exact-head workflow/security/review-control defects at the actual owning boundary; false-green central evidence is non-passing.
  3. Treat an unexplained protected-main admission that lacks then-required formal review/gate evidence as a release blocker, even if the resulting protected commit is technically green. Do not make the later tag/publication path retroactively legitimize the admission. The actual merge/authentication path and ruleset decision must be reconstructed through the existing governance owner, the fail-closed admission contract repaired, and the resulting protected lineage revalidated under ordinary non-bypass governance before release acceptance.
  4. Integrate source stacks dependency-first under then-live governance, regenerating exact-current-head evidence for every descendant rather than transferring parent/predecessor runs.
  5. Integrate the release-workflow owner only after its dependencies are ready; after integration, refetch protected release.yml and treat only that exact protected workflow as the authoritative release asset, timeout, SBOM, provenance, browser, and publication contract.
  6. On one unchanged protected tip, regenerate every applicable required gate.
  7. Create the stable tag/GitHub Release only through supported release authority at that exact protected tip. Never emulate release identity by moving or naming a branch ref.
  8. Publish npm/PyPI only through the then-accepted registry mechanism and policy; do not weaken provenance, reuse ambiguous bytes, or use skip-existing to conceal partial publication.
  9. Verify public registry digests against the exact accepted release artifacts. On partial publication or mismatch, record an incident and do not rebuild different bytes under the same immutable version.
  10. Close this issue only after public artifact, digest, provenance, rollback, and operational acceptance are proven.

Stable release acceptance criteria

Close only when one exact protected lineage proves all then-applicable requirements, including:

  • root/Office/tag/release metadata agree;
  • deterministic JavaScript and Office builds from immutable dependencies;
  • repository-required test, exact coverage, and public-doc/docstring thresholds;
  • packed-package consumer verification;
  • dependency-locked real Chromium/Firefox/WebKit evidence where applicable;
  • accessibility and deterministic Office/fidelity evidence;
  • security, SAST, dependency, package, SBOM, provenance, reproducibility, rollback, and operational gates;
  • qualifying formal independent reviews under live governance;
  • no unresolved merge-admission/ruleset-bypass incident capable of undermining the protected lineage used for release;
  • release artifacts built from and attributable to the exact protected source;
  • public registry digests matching those exact artifacts;
  • no unresolved contradiction between source, release metadata, registry state, governance evidence, and canonical documentation.

Branch CI, active-PR metadata, queued review dispatch, model verdicts, local-only tests, predecessor runs, or unmerged repairs do not satisfy acceptance.

Authority/tool boundary

If the currently available mutation surface does not expose safe Git-tag or GitHub-Release creation, classify only that exact release mutation as unavailable and continue every other safe repository action. Do not evade that boundary with lower-level branch-ref mutation or fabricate a release identity.

The canonical product/technical maintenance baseline is docs/product-technical-gap-baseline.md; it must likewise avoid treating mutable GitHub lifecycle snapshots as protected static truth.

Activity

  1. seonghobae commented on Aug 20, 2026

    @seonghobae
    ContributorAuthor

    Exact-current release-boundary supersession for the dynamic snapshot in the issue body (2026-08-20 UTC). This does not change the dependency order or authorize merge/tag/publication.

    • Protected Inkspan shipped truth remains main@3b38ead2d00f44eb578d0689087b9293b3dabe1e.
    • Ready release blocker fix(a11y): repair editor contrast and keyboard focus #362 remains exact head 11d5cfecdcc0949ec98e6ca110d482124bff00c4, base main@3b38ead2..., open/not merged and mechanically mergeable; mergeability is not authorization.
    • Native exact-head CI 32344528267 has advanced from the issue body's stale in progress snapshot to completed / success. Its build/test, dependency-locked Chromium/Firefox/WebKit and Office Python 3.11–3.14 jobs are terminal success.
    • Required Security Scan 32344528097 and SAST Semgrep 32344528210 remain queued / non-passing on the same exact head. Their scanner jobs remain unassigned/no-step beyond the central 900-second queue SLO; exact-current reproduction and RCA/RED/GREEN acceptance were advanced on the existing foreign control-plane owner ContextualWisdomLab/.github#712 in comment 5353146449. Do not retry/cancel or patch Inkspan source around the sole current-head scanner evidence.
    • Formal same-head OpenCode verdict remains absent, qualifying independent approval remains 0, and unresolved inline review threads remain 0. The predecessor OpenCode request 5352555668 remains stale and must not be promoted or duplicated.
    • Protected central review/control-plane truth has advanced from the issue body's stale .github/main@2cce96f8671bfde7e354effef931c14a5928c23b snapshot to signed protected .github/main@aa8503f4383e8328d89104796bc3e9f7da810376 (#1149). Existing .github#814 remains the review-routing/receipt/dispatch owner; the new central commit does not convert queued Inkspan scanner evidence into success.

    Therefore dependency step 2 is still not satisfied, but specifically because Security Scan/SAST remain queued; native CI/browser/Office is now terminal-success. Only after every repository exact-head gate is terminal-success should one new current-head OpenCode request be submitted, followed by durable receipt/exact checkout/coverage-docstring/formal-verdict evidence and then-live independent review/governance. v0.6.0 remains blocked and no predecessor/model/status evidence transfers.

  2. seonghobae commented on Aug 21, 2026

    @seonghobae
    ContributorAuthor

    Fresh release-boundary correction against live protected authority; this comment supersedes only the stale central-control-plane SHA sentence in the issue body and does not alter the release freeze or create a new review request.

    Protected Inkspan truth is unchanged at main@3b38ead2d00f44eb578d0689087b9293b3dabe1e. Canonical release blocker #362 is unchanged at exact head 11d5cfecdcc0949ec98e6ca110d482124bff00c4; its exact-head CI 32344528267, Security Scan 32344528097, and SAST 32344528210 remain terminal success, unresolved threads remain 0, and qualifying independent approval remains 0. The one current-head OpenCode request remains issue-comment 5353399090; a fresh direct reaction read is still empty and there is still no formal same-head OpenCode verdict.

    The issue body currently names central .github/main@dd58a88391e44a32fb399f7407f508d8e73cc1c7 as protected truth. Live protected central truth has advanced to signed .github/main@0156282022134484ea9d7541d5ba0730ba14fd96; compare_commits(dd58a883..., 015628202...) reports ahead by 3, so #1174 remains in ancestry and the newer protected #946 substantive-review publication repair is also now authoritative. Post-#946 revalidation still shows no durable receipt/formal review for #362's immutable request, so the review gate remains absent/non-passing and .github#814 remains the owning foreign path.

    A second independent Inkspan canary, Ready #373 at exact head c2db417df2c8f041d31ac5880c4898f00692c04e, likewise has terminal-success repository CI/Security/SAST and one current-head request 5366926051 whose fresh reaction read is empty. This reinforces that the current release hold is not resolved by repository-local green evidence or by simply advancing central protected source.

    Separate central .github#1161 documents absence of PR_REVIEW_MERGE_TOKEN for the hourly commercial-readiness coordinator. Do not promote that into the Inkspan release RCA without exact router-run evidence: protected agent-mention-router.yml can obtain sibling-sweep authority from PR_REVIEW_MERGE_TOKEN, OPENCODE_APPROVE_TOKEN, or the OpenCode App OIDC exchange.

    Release decision remains unchanged: no #362 merge, tag, GitHub Release, npm/PyPI publication, or gate weakening until the exact same-head review/approval requirements and the release-workflow dependency chain are satisfied under live governance.

  3. added
    area: authAuthentication, authorization, identity, or tenant isolation
    area: ci-cdCI, GitHub Actions, checks, release, or supply chain
    area: securitySecurity boundary, hardening, or vulnerability prevention
    status: blockedBlocked by conflict, dependency, or required prerequisite
    type: featureNew or expanded product capability
    on Aug 22, 2026
  4. seonghobae commented on Aug 23, 2026

    @seonghobae
    ContributorAuthor

    Canonical release-control dependency refresh; this supersedes only the stale central .github snapshot/owner ordering in the issue body. It does not authorize merge, tag, release, or publication.

    • Protected Inkspan truth remains main@3b38ead2d00f44eb578d0689087b9293b3dabe1e.
    • Ready Inkspan CI owner fix(ci): run exact-head gates on stacked pull requests #299 remains exact head 1efbd632719b0e54c5a33e3a95224a4bd2f869d3 against that base. Its repository-local CI is green, but central Security run 32635939483 / dependency-review job 97185600223 and central SAST run 32635939469 / job 97185600190 are non-passing evidence because they checked out synthetic merge 12668622e38473c14dbb7d22bb9e3e0c05f1ea8a instead of the submitted Inkspan head; dependency-review additionally received HTTP 403 and skipped the pinned action.
    • Independently resolved protected central truth is now .github/main@9f8f84074d8a8bc142eafea12c5b9e1c8570ccd6.
    • .github#897@d9b395cd01999a6ec946d3c7a013f22225143782 remains the dependency-review fail-closed/exact-head owner. Its required Strix run 32633538138, job 97191695465, failed under protected source 885f2cd251999f21cf562cab3e2d9cc3cc3ec737: primary NVIDIA NIM exhausted with HTTP 429 and the configured openai-direct/gpt-5.6-luna fallback reached LiteLLM without a valid provider (LLM Provider NOT provided). Thus #897 cannot yet provide protected consumer evidence.
    • The current canonical central causal repair for that provider/fallback boundary is .github#1263@7be1e60146575a5943c132f82d38ddf742f010a6, Ready/mergeable against live central base 9f8f84074d8a8bc142eafea12c5b9e1c8570ccd6. Its exact-head SBOM, exact-artifact SBOM quality, Secret, commercial-readiness quality, Scorecard, Rust coverage, SAST, OSV, Security, Python Security, CodeQL and Strix changed-path workflows are terminal success, but it has no formal APPROVE and three current Devin threads remain unresolved. It is therefore unintegrated/non-passing for downstream release purposes.
    • .github#941@5b07547a01137989ae1324cd472bb15229d5e0d2 remains the central Semgrep exact-submitted-revision owner and is likewise unintegrated. Neither #897 nor #941 predecessor/status evidence may be grandfathered onto fix(ci): run exact-head gates on stacked pull requests #299.

    Current dependency order for the central evidence lane is therefore: normal-governance integration of #1263 -> fresh unchanged-or-descendant #897/#941 evidence under the then-protected central source -> fresh unchanged-or-descendant #299 Security/SAST generations proving exact Inkspan source checkout and actual dependency-review execution -> normal Inkspan governance/merge consideration. The v0.6.0 release hold remains in force.

  5. seonghobae commented on Aug 26, 2026

    @seonghobae
    ContributorAuthor

    Fresh release-acceptance state against protected authority (2026-08-26 UTC); this is dynamic decision evidence only and does not authorize merge/tag/publication.

    • Protected Inkspan truth is main@128a239f8b71ca16add4b9e15e21752d1ad63ff0.
    • The current release-metadata owner is Ready PR release: consolidate 0.6.0 changelog for v0.6.0 tagging #389, exact head 80160413b87f462e811c7e48161e7ea0f01a230d, directly based on that protected tip and mechanically mergeable. Its current review threads are all resolved.
    • Same-head repository/central technical evidence is terminal rather than queued: native CI 32917948383, SAST 32917948336, and Security 32917948414 completed successfully; the exact-head check-run inventory contains 31 completed checks, including coverage-evidence and opencode-review, with no failed/queued/in-progress/skipped check-run in the current generation. This remains technical evidence only and is not a formal approval.
    • Fresh Reviews API state for release: consolidate 0.6.0 changelog for v0.6.0 tagging #389 contains only COMMENTED Devin submissions and 0 APPROVED reviews. The live organization ruleset requires one approving review and resolved review threads. Therefore the first current release-metadata admission blocker is now the missing qualifying independent formal approval, not a queued repository check.
    • Public GitHub Release state still exposes only immutable v0.3.1; there is no v0.6.0 GitHub Release. Do not synthesize release identity from release/v0.6.0 or infer registry publication from source version metadata.

    Decision: keep #389 and the v0.6.0 publication path blocked until a qualifying same-head approval exists and the exact protected post-merge head is revalidated through the full release/package/SBOM/provenance/reproducibility/registry-digest contract. No predecessor/model/status evidence transfers.

  6. seonghobae commented on Aug 26, 2026

    @seonghobae
    ContributorAuthor

    Release-acceptance correction for the current #389 generation: the aggregate Security Scan success is not complete dependency-review evidence and must not be treated as a gate-clean technical state.

    Fresh immutable identities remain unchanged:

    • protected Inkspan main@128a239f8b71ca16add4b9e15e21752d1ad63ff0;
    • Ready release-metadata owner #389@80160413b87f462e811c7e48161e7ea0f01a230d, directly based on that tip;
    • Security Scan run 32917948414, exact head 80160413...;
    • dependency-review job 98025502696.

    The decisive job-level evidence is RED under the release contract: Check dependency review support completed, the pinned Dependency review step was skipped, and the job/workflow nevertheless concluded GitHub success. The current protected central security-scan.yml explicitly maps dependency-review API 403/404 to supported=false + successful skip. Existing organization owner .github#810 classifies that behavior as false-green supply-chain evidence; OSV/Trivy success is complementary and does not substitute for the missing dependency-review result.

    This supersedes the earlier dynamic #118 comment that described the current technical generation as fully terminal-clean and made the missing formal approval the sole admission blocker. There are now at least two independent non-passing release-admission gates on unchanged #389: (1) zero qualifying APPROVED reviews under ruleset 18156473, owned by .github#772; and (2) fail-open/skipped Dependency Review evidence, owned by .github#810 / canonical repair PR .github#897.

    The central repair owner has materially advanced: .github#897 is currently Ready at exact head ccea53c3acb746168a0b476fbdfb8af1500b871a against .github/main@5972c9ca08befa60501004d9650316a85b83db5c. Its Security run 32936897291 / dependency-review job 98079730545 executes exact-head checkout verification, the support probe, and the pinned Dependency Review action successfully; its relevant same-head repository quality/security workflows are terminal-success. It still lacks qualifying current-head formal approval, and its current required OpenCode review check is queued, so it is not mergeable by policy yet and no predecessor evidence transfers.

    Release decision remains fail-closed: do not merge #389, create v0.6.0, or publish npm/PyPI artifacts until #897 integrates normally, #389 is revalidated on the then-live protected base with the repaired Dependency Review path, a qualifying same-head approval exists, and all remaining package/SBOM/provenance/reproducibility/rollback/registry-digest acceptance is exact-head/protected-head clean.

  7. seonghobae commented on Aug 26, 2026

    @seonghobae
    ContributorAuthor

    Exact-current release-evidence correction against protected inkspan/main@128a239f8b71ca16add4b9e15e21752d1ad63ff0; this supersedes older lifecycle snapshots only. It does not authorize merge, tag, GitHub Release, npm/PyPI publication, or gate weakening.

    • Canonical release PR release: consolidate 0.6.0 changelog for v0.6.0 tagging #389 is still open/Ready/mergeable at immutable head 80160413b87f462e811c7e48161e7ea0f01a230d against live base main@128a239f8b71ca16add4b9e15e21752d1ad63ff0. All seven review threads are resolved, but formal reviews contain zero APPROVED verdicts.
    • Exact-head repository CI is terminal-success, but aggregate-green security status is not passing release evidence. In Security Scan run 32917948414, dependency-review job 98025502696 completed success, while its pinned Dependency review action itself is skipped after the support probe. Under the release contract, a skipped required evidence path is non-passing regardless of the enclosing job/run conclusion.
    • Exact-head SAST run 32917948336, Semgrep job 98025501935, is also not exact-source release evidence. The checkout log fetched +5734fb699b62ba2c50217374a67d286cfe18e27d:refs/remotes/pull/389/merge, checked out that synthetic merge, and reported runtime HEAD=5734fb699b62ba2c50217374a67d286cfe18e27d, rather than submitted PR head 80160413b87f462e811c7e48161e7ea0f01a230d. The Semgrep scan's zero findings therefore describe the synthetic merge tree, not the required exact submitted head.
    • These are foreign central control-plane defects, not Inkspan source defects. Existing owner paths remain .github#810/#897 for fail-closed Dependency Review and .github#1222/#941 for exact-submitted-revision Semgrep. Fresh owner state is .github#897@c869a825e99a492b89adbd3956ea95b45fb52180 and .github#941@0f7cabaad874a9555b02ebb3a22db9aef3a478ce, both synchronized against protected .github/main@60a34005e59efe2b622897e3c7b06882bdf63aee; neither may transfer predecessor evidence to release: consolidate 0.6.0 changelog for v0.6.0 tagging #389 before protected integration and downstream revalidation.
    • The protected Inkspan review-repair caller currently has queued, not passing, evidence; queued automation cannot substitute for a counted current-head approval.

    Release RED remains falsifiable and narrow: after the owning central repairs are normally integrated, an unchanged-or-descendant #389 generation must show the Dependency Review action actually executed and terminal-passed, and SAST runtime HEAD must equal the submitted Inkspan head (or an accepted versioned contract must explicitly authorize another identity). Only then, with all then-live required gates and a qualifying counted non-author approval terminal-passing on the same release identity, can #389 enter normal merge/release consideration.

  8. seonghobae commented on Aug 26, 2026

    @seonghobae
    ContributorAuthor

    Release-acceptance correction after fresh exact-step inspection:

    inkspan#389 remains open/Ready and mechanically mergeable at exact head 80160413b87f462e811c7e48161e7ea0f01a230d against protected main@128a239f8b71ca16add4b9e15e21752d1ad63ff0, with all seven inline review threads resolved. Formal reviews are still COMMENTED-only; qualifying APPROVED reviews: 0.

    The repository Security Scan aggregate for that exact head (32917948414) must not be treated as passing release evidence. Its dependency-review job 98025502696 concludes success while the underlying required Dependency review action step is skipped. This is the false-green class explicitly prohibited by this issue's acceptance contract.

    The causal owner remains the existing organization path .github#810 / PR .github#897; no Inkspan-local workflow exception or duplicate writer is appropriate. Fresh owner revalidation shows #897 exact head ac76db5c5dc83ac0d0d0b25e1e41602394df61a9 has owner-side Security Scan 33000315856 GREEN with dependency-review job 98280122496 and the actual Dependency review step completed success. However, protected central main advanced from #897's recorded base 874f47b3856ca6bdb6bc71d48173b8f34ba7b9ca to 5f3188b78e0eef1eb6ac2765f444ce0422cff91e, and GitHub now reports #897 not mechanically mergeable. The owner repair therefore requires non-destructive current-main reconciliation, fresh exact-head gates, and qualifying counted non-author approval before normal integration.

    Inkspan-side GREEN acceptance remains: after the central owner repair is actually protected/integrated, rerun #389 on its then-current unchanged exact head/live base and require the Dependency Review action itself to execute successfully. If the service/capability is unavailable, Security Scan must fail closed rather than report skipped-success. Until then, no #389 merge, v0.6.0 tag/GitHub Release, npm/PyPI publication, or release-ready claim is authorized.

  9. seonghobae commented on Aug 27, 2026

    @seonghobae
    ContributorAuthor

    Fresh release-acceptance correction against live authority; this supersedes only older dynamic lifecycle snapshots and does not authorize merge/tag/publication.

    • Protected Inkspan truth remains main@128a239f8b71ca16add4b9e15e21752d1ad63ff0.
    • Canonical release-metadata PR remains #389@80160413b87f462e811c7e48161e7ea0f01a230d, open/Ready/mechanically mergeable against that exact base. Its seven inline review threads are resolved, but formal review inventory still has zero qualifying APPROVED reviews.
    • Current #389 Security Scan 32917948414 remains non-passing release evidence because dependency-review job 98025502696 concluded success while the actual pinned Dependency review step was skipped.
    • Current #389 SAST 32917948336 / Semgrep job 98025501935 remains non-passing exact-source evidence because it scanned GitHub synthetic merge 5734fb699b62ba2c50217374a67d286cfe18e27d, not contributor head 80160413....

    The two foreign causal owners have both advanced without an Inkspan-local workaround:

    1. Dependency-review owner .github#810/#897: protected .github/main@548a97560070d31b03d14bee0ac98a990bd88482; canonical #897@a2524ad68efd254dae4f0442f05c98a09b441ec3, open/Ready/mergeable. Owner-side Security Scan 33017758291 proves exact base/head binding, HTTP 200 support, and actual pinned Dependency Review action execution. The earlier same-head Strix provider failure was retried successfully (33017656014, latest job 98433128661), and current same-head hosted quality/security workflows are terminal-success. Formal review state is still non-passing: no qualifying APPROVED review, and the latest OpenCode CHANGES_REQUESTED submissions refer to predecessor failed Strix attempts. The required opencode-review check job now succeeds only as the read-only bootstrap; its own log states formal review must come from the authenticated repository-dispatch workflow, and there is no repository-dispatch run bound to current head a2524ad... in the live run inventory.

    2. Exact-source SAST owner .github#1222/#941: canonical #941@a6d4632a5d5aa36d4f2a9cea55cc39b21755590d against the same protected central base, open/Ready/mergeable. Exact-head owner workflows are terminal-success across SAST, Security, CodeQL, Python Security, OSV, Scorecard, Secret Scan, SBOM and dedicated quality suites, but formal reviews still contain no qualifying current-head APPROVED verdict; historical OpenCode CHANGES_REQUESTED entries target predecessor heads.

    Release RED/GREEN remains unchanged: do not grandfather the current Inkspan aggregate greens. After both central repairs integrate normally under then-live governance, regenerate #389 on its then-current exact head/live base. GREEN requires the Dependency Review action itself to execute successfully (or fail visibly when support cannot be established), SAST runtime HEAD == pull_request.head.sha, and a qualifying counted non-author approval plus all remaining package/SBOM/provenance/reproducibility/rollback/registry-digest gates on one exact protected release identity.

  10. seonghobae commented on Aug 28, 2026

    @seonghobae
    ContributorAuthor

    Fresh current-generation release-boundary update (2026-08-28 UTC), superseding older mutable snapshots only:

    • Protected Inkspan main remains 128a239.
    • Release-metadata PR release: consolidate 0.6.0 changelog for v0.6.0 tagging #389 is current head 82f4de6 against that base, still Draft with no qualifying independent approval.
    • Its Dependency Review job 98474171945 checked out pull/389/merge, received HTTP 403, and skipped the required action under a successful enclosing job.
    • Its Semgrep job 98474141000 checked out synthetic merge 70eedfc rather than submitted head 82f4de6.
    • These are non-passing release evidence and central control-plane owner lanes; no Inkspan-local workaround, merge, tag, GitHub Release, or npm/PyPI publication is authorized.
  11. seonghobae commented on Aug 29, 2026

    @seonghobae
    ContributorAuthor

    Exact release-boundary transition after central #897 integration

    Fresh release acceptance is now blocked at a different causal boundary; this does not authorize merge/tag/publication.

    • protected Inkspan truth: main@128a239f8b71ca16add4b9e15e21752d1ad63ff0;
    • release PR: #389, unchanged exact head 4b02834fd56a676589afd6b57516da44f8f984be, Ready/open/mergeable;
    • central dependency-review false-green repair ContextualWisdomLab/.github#897 is integrated, merge commit b18ee32057c991428973e99a6ce84702123771cb;
    • post-repair Inkspan Security Scan run 33170544304 now checks out the exact submitted head and fails closed instead of skipping green. Latest dependency-review job 99109491845 records visibility=public, exact base/head, http_status=403, curl_exit=0, then exits failure before the pinned action;
    • therefore the former central false-green defect is repaired for this consumer, but the remaining HTTP 403 is still non-passing dependency evidence. The first unresolved boundary is repository dependency-graph/security configuration, entitlement/permission, or GitHub service behavior; there is no correct Inkspan source/scanner suppression.
    • live Inkspan ruleset 18156473 still requires one approving review and thread resolution plus the central workflow set. release: consolidate 0.6.0 changelog for v0.6.0 tagging #389 has zero qualifying APPROVED submissions; all fetched review threads are resolved.
    • a fresh request for the established independent-reviewers team was rejected HTTP 422 because that team is still not an Inkspan repository collaborator, so .github#772 remains the independent-review provisioning owner.
    • separately, .github#897 itself reached protected central main without retrievable exact-final-head approval while its first exact-final-head Security generation was still non-passing; this has been advanced on existing governance owner .github#1340 for audit-log/Rule-Insights reconstruction. Under this issue's own release contract, that unexplained control-plane admission remains a release-lineage blocker until dispositioned.

    No merge, admin bypass, tag, GitHub Release, npm/PyPI publication, self-approval, or gate weakening is permitted from this state. GREEN requires (1) genuine dependency-review evidence or a correctly governed explicit applicability decision at the repository/service boundary, (2) qualifying non-author approval of the unchanged current head, and (3) resolution/revalidation of the central merge-admission incident before one exact protected release lineage is accepted.

  12. seonghobae commented on Aug 29, 2026

    @seonghobae
    ContributorAuthor

    Fresh stable-release acceptance update after the central Dependency Review repair reached protected .github.

    Release candidate remains unchanged: inkspan#389@4b02834fd56a676589afd6b57516da44f8f984be over protected main@128a239f8b71ca16add4b9e15e21752d1ad63ff0, Ready/open/mergeable with all inline review threads resolved but no qualifying APPROVED review.

    The post-integration Security canary now proves the former false-green class is fixed but the dependency evidence itself is unavailable: run 33170544304, job 99109491845 verifies exact submitted-head checkout, then the exact public-repository base/head comparison returns HTTP 403 with curl exit 0; the required job terminates failure instead of skipping Dependency Review and going green. This is correct fail-closed behavior, but still non-passing release evidence.

    The required OpenCode gate is independently non-passing on the same exact head: run 33170543483, latest job 99107756541 fails because the Reviews API contains no current-head APPROVED or CHANGES_REQUESTED verdict from opencode-agent. Bootstrap and coverage evidence are success, so this is the shared authenticated dispatch/provider/review-publication boundary, not an Inkspan source/test failure.

    Release decision: do not merge #389, tag v0.6.0, create a GitHub Release, or publish npm/PyPI until (1) the public Dependency Graph comparison reaches HTTP 200 and the pinned Dependency Review action actually executes, (2) a genuine exact-head OpenCode formal verdict exists and its verifier is terminal-success, and (3) the live counted non-author approval requirement is satisfied. No bypass or substitute evidence is accepted.

  13. seonghobae commented on Sep 1, 2026

    @seonghobae
    ContributorAuthor

    Naruon consumer-path handoff from fresh 2026-09-01 evidence; this is read-only dependency coordination and does not authorize an Inkspan merge/release. Protected Inkspan main is now 128a239f8b71ca16add4b9e15e21752d1ad63ff0. The writing-diagnostics root #248 is live at a7ed6cb9f9797809399d2b914241975cd0e1939a and is exactly ahead of that protected tip (behind_by=0), although its PR body still names an older head. #249 is live at 23223569910dbee36fb6e285b9a6e8b4c2da88ac and is exactly stacked on the current #248 head. The package owner #282 remains Draft at 03e626e57c9b85d5f6cc9b616249b09bdf1669e2; assurance #285 remains Draft at c9685a7d1f75ab2dfbed373facca9b8505a6bcd4. Latest immutable release is still v0.3.1; it has no attached assets and does not expose the writing-diagnostics subpath, so Naruon must continue to refuse mutable-branch consumption.

    Naruon's immutable consumer admission requires the eventual released Inkspan artifact to expose the framework-neutral writing-diagnostics public subpath (the #282 contract), with Focus/Apply/Ignore/Dismiss/Explain behavior and revision/stale/undo/accessibility guarantees covered by the released source lineage and #285-class browser/package assurance. Before Naruon runtime adoption it also needs exact released version, source commit, distributable/package source, integrity digest/hash-lock and provenance that can be checked without resolving an unmerged branch. Please preserve these as explicit acceptance criteria on the existing #118 release path; no Naruon-side editor fork or mutable Git dependency will be used to bypass the release dependency.

  14. seonghobae commented on Sep 2, 2026

    @seonghobae
    ContributorAuthor

    Fresh Naruon consumer handoff for the writing-diagnostics release path (read-only dependency; no Inkspan source mutation from Naruon):

    Naruon-side acceptance for this owner path is an immutable released package that includes the public writing-diagnostics subpath and binds exact package version, registry/tarball integrity digest, source commit provenance, packed-package ESM/CommonJS/SSR/TypeScript consumer evidence, and the revision-bound Focus/Apply/Ignore/Dismiss/Explain + stale-rejection contract. Once such a release exists, Naruon will independently hash-lock and verify the exact artifact before replacing its reply textarea. Please keep this requirement attached to the existing #118 release train rather than creating a Naruon-specific Inkspan branch.

  15. added
    bugSomething isn't working
    type: bugDefect or incorrect behavior
    on Sep 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: authAuthentication, authorization, identity, or tenant isolationarea: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: dependenciesDependency or lockfile maintenancearea: securitySecurity boundary, hardening, or vulnerability preventionbugSomething isn't workingpriority: highstatus: blockedBlocked by conflict, dependency, or required prerequisitetype: bugDefect or incorrect behaviortype: featureNew or expanded product capability

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions