chore: finish the code-facing Loong rebrand outside the docs lane#1108
chore: finish the code-facing Loong rebrand outside the docs lane#1108chumyin merged 10 commits intoeastreams:devfrom
Conversation
|
Important Review skippedToo many files! This PR contains 299 files, which is 149 over the limit of 150. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (299)
You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
b5b1963 to
57b8816
Compare
57b8816 to
6597aff
Compare
|
LoongClaw AI scientist review for Summary
Validation
These checks passed, but they do not cover the release-archive compatibility contract or the legacy-home default-entry path. Findings
Reviewer Focus
The PR is also currently conflicting with |
|
LoongClaw AI scientist update: pushed Resolved in branch:
Verification run on the pushed branch:
Remaining blocker:
|
7332cfa to
56a7f44
Compare
… hardening the Feishu webhook stack path The tracked April architecture drift report is regenerated so governance compares against current repository output again, and the file-event Feishu webhook test now runs through the large-stack harness already used by the other deep callback scenarios. I also relaxed the reply-body assertion to check stable provider-content markers instead of one brittle serialized escape sequence. Constraint: GitHub Actions governance rejects stale tracked architecture drift reports byte-for-byte after normalization Constraint: The failing Feishu webhook test aborts CI with stack overflow on Linux and Windows without the large-stack helper Rejected: Leave the report stale and retry CI | governance would keep failing deterministically Rejected: Assert the exact escaped markdown payload string | too brittle to survive harmless serialization/layout differences Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep new deep Feishu webhook scenarios on the large-stack helper unless the underlying stack usage is reduced enough to remove the need safely Tested: cargo fmt --all -- --check Tested: LOONG_ARCH_REPORT_MONTH=2026-04 bash scripts/check_architecture_drift_freshness.sh docs/releases/support/architecture-drift-2026-04.md Tested: cargo test -p loong-app feishu_webhook_file_event_reaches_provider_as_structured_text_and_replies --lib Tested: git diff --check Not-tested: full workspace test matrix rerun locally Not-tested: GitHub Actions rerun after push
4e26311 to
841e8f0
Compare
…e and runtime-facing Loong rebrand The branch now migrates CODEOWNERS from the archived loongclaw-ai teams to live eastreams teams, after creating the matching teams in eastreams and binding them to eastreams/loong. It also pushes the remaining runtime-facing surfaces toward Loong by promoting _loong internal tool context, x-loong provider headers, loong transcript exports, Loong-first installer env vars, and refreshed onboarding/tool copy, while keeping explicit legacy read paths where active compatibility still matters. Constraint: eastreams had no teams, so CODEOWNERS could not move safely until matching teams existed in the target org Constraint: legacy _loongclaw and loongclaw metadata aliases still need compatibility reads for in-flight runtime/tool payloads Rejected: Leave CODEOWNERS on loongclaw-ai | breaks governance alignment on the target org and leaves reviewers unresolved Rejected: Remove every loongclaw alias in one pass | too risky for active runtime compatibility and test baselines Confidence: medium Scope-risk: broad Reversibility: messy Directive: Treat @eastreams/* teams, _loong tool context, and x-loong runtime headers as the primary surfaces; only preserve loongclaw aliases when a compatibility read path is intentional Tested: cargo check -p loong-app -p loong --all-targets Tested: cargo clippy -p loong-app -p loong --all-targets -- -D warnings Tested: cargo test -p loong-app default_export_path_uses_loong_exports_directory --lib Tested: cargo test -p loong-app augment_tool_payload_injects_visible_tool_ids_for_tool_search --lib Tested: cargo test -p loong-app append_prompt_cache_headers_inserts_runtime_request_metadata --lib Tested: cargo test -p loong-app execute_bash_tool_with_config_allows_trusted_internal_context_field --lib Tested: cargo test -p loong --test integration gateway_acp_ Tested: bash scripts/test_install_sh.sh Tested: bash scripts/test_check_architecture_drift_freshness.sh Tested: git diff --check Not-tested: cargo fmt --all -- --check still reports pre-existing formatting drift in unrelated files outside this change set Not-tested: full workspace cargo test --workspace --all-features
… hardening the Feishu webhook stack path The tracked April architecture drift report is regenerated so governance compares against current repository output again, and the file-event Feishu webhook test now runs through the large-stack harness already used by the other deep callback scenarios. I also relaxed the reply-body assertion to check stable provider-content markers instead of one brittle serialized escape sequence. Constraint: GitHub Actions governance rejects stale tracked architecture drift reports byte-for-byte after normalization Constraint: The failing Feishu webhook test aborts CI with stack overflow on Linux and Windows without the large-stack helper Rejected: Leave the report stale and retry CI | governance would keep failing deterministically Rejected: Assert the exact escaped markdown payload string | too brittle to survive harmless serialization/layout differences Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep new deep Feishu webhook scenarios on the large-stack helper unless the underlying stack usage is reduced enough to remove the need safely Tested: cargo fmt --all -- --check Tested: LOONG_ARCH_REPORT_MONTH=2026-04 bash scripts/check_architecture_drift_freshness.sh docs/releases/support/architecture-drift-2026-04.md Tested: cargo test -p loong-app feishu_webhook_file_event_reaches_provider_as_structured_text_and_replies --lib Tested: git diff --check Not-tested: full workspace test matrix rerun locally Not-tested: GitHub Actions rerun after push
|
Pushed This follow-up does three things:
Fresh local verification on this rebased head:
GitHub now reports the PR as mergeable again and the new check suite is queued on |
…e and runtime-facing Loong rebrand The branch now migrates CODEOWNERS from the archived loongclaw-ai teams to live eastreams teams, after creating the matching teams in eastreams and binding them to eastreams/loong. It also pushes the remaining runtime-facing surfaces toward Loong by promoting _loong internal tool context, x-loong provider headers, loong transcript exports, Loong-first installer env vars, and refreshed onboarding/tool copy, while keeping explicit legacy read paths where active compatibility still matters. Constraint: eastreams had no teams, so CODEOWNERS could not move safely until matching teams existed in the target org Constraint: legacy _loongclaw and loongclaw metadata aliases still need compatibility reads for in-flight runtime/tool payloads Rejected: Leave CODEOWNERS on loongclaw-ai | breaks governance alignment on the target org and leaves reviewers unresolved Rejected: Remove every loongclaw alias in one pass | too risky for active runtime compatibility and test baselines Confidence: medium Scope-risk: broad Reversibility: messy Directive: Treat @eastreams/* teams, _loong tool context, and x-loong runtime headers as the primary surfaces; only preserve loongclaw aliases when a compatibility read path is intentional Tested: cargo check -p loong-app -p loong --all-targets Tested: cargo clippy -p loong-app -p loong --all-targets -- -D warnings Tested: cargo test -p loong-app default_export_path_uses_loong_exports_directory --lib Tested: cargo test -p loong-app augment_tool_payload_injects_visible_tool_ids_for_tool_search --lib Tested: cargo test -p loong-app append_prompt_cache_headers_inserts_runtime_request_metadata --lib Tested: cargo test -p loong-app execute_bash_tool_with_config_allows_trusted_internal_context_field --lib Tested: cargo test -p loong --test integration gateway_acp_ Tested: bash scripts/test_install_sh.sh Tested: bash scripts/test_check_architecture_drift_freshness.sh Tested: git diff --check Not-tested: cargo fmt --all -- --check still reports pre-existing formatting drift in unrelated files outside this change set Not-tested: full workspace cargo test --workspace --all-features
… hardening the Feishu webhook stack path The tracked April architecture drift report is regenerated so governance compares against current repository output again, and the file-event Feishu webhook test now runs through the large-stack harness already used by the other deep callback scenarios. I also relaxed the reply-body assertion to check stable provider-content markers instead of one brittle serialized escape sequence. Constraint: GitHub Actions governance rejects stale tracked architecture drift reports byte-for-byte after normalization Constraint: The failing Feishu webhook test aborts CI with stack overflow on Linux and Windows without the large-stack helper Rejected: Leave the report stale and retry CI | governance would keep failing deterministically Rejected: Assert the exact escaped markdown payload string | too brittle to survive harmless serialization/layout differences Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep new deep Feishu webhook scenarios on the large-stack helper unless the underlying stack usage is reduced enough to remove the need safely Tested: cargo fmt --all -- --check Tested: LOONG_ARCH_REPORT_MONTH=2026-04 bash scripts/check_architecture_drift_freshness.sh docs/releases/support/architecture-drift-2026-04.md Tested: cargo test -p loong-app feishu_webhook_file_event_reaches_provider_as_structured_text_and_replies --lib Tested: git diff --check Not-tested: full workspace test matrix rerun locally Not-tested: GitHub Actions rerun after push
841e8f0 to
5d59c22
Compare
|
Pushed What this push adds beyond the previous rebrand/governance pass:
Fresh local verification on the rebased head:
GitHub currently reports the PR as mergeable again ( |
Instead of repeatedly rebasing the old PR history onto a rapidly moving dev branch, this checkpoint starts a fresh rebuild on top of the latest dev head and reapplies the low-conflict/high-value rebrand slices first. It restores the CODEOWNERS migration to real eastreams teams, keeps the installer and transcript/export/Tlon/onboarding/status surfaces aligned with Loong-first naming, and ports the first runtime/tool compatibility layer (_loong internal context, x-loong provider headers, browser scope compatibility, and the ACP timeout probe fix) while preserving enough compatibility for the current dev test matrix to compile. Constraint: latest dev is absorbing overlapping chat/provider/tools/runtime work fast enough that replaying the original PR commit stack causes large recurring conflicts Constraint: current daemon/app integration tests still compile against legacy crate/binary import names, so the rebuild uses package-name migration plus compatibility dependency keys/lib entrypoints where needed Rejected: Keep restacking the original 7-commit PR history onto every new dev head | too conflict-heavy and unstable to close the branch efficiently Rejected: Drop the legacy compile-time entrypoints immediately on the rebuild branch | would break the current latest-dev test matrix before the rest of the rebrand is restabilized Confidence: medium Scope-risk: moderate Reversibility: clean Directive: Continue the rebuild by porting the remaining high-conflict runtime/provider/chat surfaces in small, verified layers instead of reviving the old large conflict set wholesale Tested: cargo fmt --all -- --check Tested: cargo check -p loong-app -p loong --all-targets Tested: cargo clippy -p loong-app -p loong --all-targets -- -D warnings Tested: bash scripts/test_install_sh.sh Tested: cargo test -p loong-app default_export_path_uses_loong_exports_directory --lib Tested: cargo test -p loong-app augment_tool_payload_injects_visible_tool_ids_for_tool_search --lib Tested: cargo test -p loong-app append_prompt_cache_headers_inserts_runtime_request_metadata --lib Tested: cargo test -p loong --test integration gateway_acp_ Not-tested: full workspace test matrix on the rebuild branch Not-tested: GitHub Actions on a replacement PR head yet
f2af199 to
3c0d9fd
Compare
|
Pushed What this continuation adds:
Safety / branch-management notes:
Local verification run for this continuation:
Known local-only verification gap:
Also rechecked the org-side setup while continuing this lane: the |
|
Follow-up push sequence completed on top of the latest-dev rebuild lane:
Result on current PR head
The visible blocker is no longer CI failure or merge dirt; GitHub now shows the branch as blocked by review ( Remote safety note: the previous pre-rebuild PR head was preserved as |
…t surfaces The PR's Loong-first package and runtime rename was directionally correct, but it left three real breakpoints behind: renamed library crates no longer matched existing imports/tests, installer compatibility seams were removed while the repo still advertised them, and newer Loong env/context keys were introduced without end-to-end entrypoint coverage. This patch keeps the Loong-facing package/runtime progression while restoring the compatibility guarantees that current users and the repo contract still assume. It also updates the affected tests to assert the new Loong branding without regressing the guarded behavior they were meant to protect. Constraint: PR eastreams#1108 already renames package identities and runtime-facing names, so the fix had to preserve that direction instead of rolling the rebrand back Rejected: Remove legacy installer/env/bin seams now | breaks documented and exercised compatibility surfaces during the migration window Rejected: Rename every remaining test/import to new crate names only | larger churn than necessary and drops useful compatibility aliases Confidence: high Scope-risk: moderate Reversibility: clean Directive: Keep dual-read and dual-entry compatibility in place until release/install/docs contracts no longer advertise the legacy seams Tested: bash scripts/test_install_sh.sh Tested: bash scripts/check_dep_graph.sh Tested: ./scripts/check_architecture_boundaries.sh Tested: cargo clippy --workspace --all-targets --all-features --target aarch64-apple-darwin -- -D warnings Tested: cargo test --workspace --all-features --target aarch64-apple-darwin Not-tested: GitHub Actions after the new commit
Instead of repeatedly rebasing the old PR history onto a rapidly moving dev branch, this checkpoint starts a fresh rebuild on top of the latest dev head and reapplies the low-conflict/high-value rebrand slices first. It restores the CODEOWNERS migration to real eastreams teams, keeps the installer and transcript/export/Tlon/onboarding/status surfaces aligned with Loong-first naming, and ports the first runtime/tool compatibility layer (_loong internal context, x-loong provider headers, browser scope compatibility, and the ACP timeout probe fix) while preserving enough compatibility for the current dev test matrix to compile. Constraint: latest dev is absorbing overlapping chat/provider/tools/runtime work fast enough that replaying the original PR commit stack causes large recurring conflicts Constraint: current daemon/app integration tests still compile against legacy crate/binary import names, so the rebuild uses package-name migration plus compatibility dependency keys/lib entrypoints where needed Rejected: Keep restacking the original 7-commit PR history onto every new dev head | too conflict-heavy and unstable to close the branch efficiently Rejected: Drop the legacy compile-time entrypoints immediately on the rebuild branch | would break the current latest-dev test matrix before the rest of the rebrand is restabilized Confidence: medium Scope-risk: moderate Reversibility: clean Directive: Continue the rebuild by porting the remaining high-conflict runtime/provider/chat surfaces in small, verified layers instead of reviving the old large conflict set wholesale Tested: cargo fmt --all -- --check Tested: cargo check -p loong-app -p loong --all-targets Tested: cargo clippy -p loong-app -p loong --all-targets -- -D warnings Tested: bash scripts/test_install_sh.sh Tested: cargo test -p loong-app default_export_path_uses_loong_exports_directory --lib Tested: cargo test -p loong-app augment_tool_payload_injects_visible_tool_ids_for_tool_search --lib Tested: cargo test -p loong-app append_prompt_cache_headers_inserts_runtime_request_metadata --lib Tested: cargo test -p loong --test integration gateway_acp_ Not-tested: full workspace test matrix on the rebuild branch Not-tested: GitHub Actions on a replacement PR head yet
…elease-support surfaces This checkpoint ports the remaining low-conflict workflow and release-governance slices onto the fresh latest-dev rebuild branch. It keeps CI/release/task surfaces aligned with the current Loong-first environment variable names and package names where safe, refreshes the tracked April drift reports, and fixes the drift-report generator/freshness scripts so support reports keep stable relative links even when comparison output is emitted outside the repo tree. Constraint: latest dev still uses older release-doc/link-generation assumptions, so the rebuild must refresh the tracked reports and script logic together to keep strict doc governance green Constraint: the latest-dev rebuild branch must avoid reintroducing the old large conflict set, so this checkpoint only carries the low-conflict governance/workflow/doc-support layer Rejected: Leave the root April drift report untracked and only refresh the support copy | strict doc governance still scans the root docs/releases report and would keep failing on stale dead links Rejected: Defer workflow/env-surface cleanup until after the high-conflict runtime rebuild | leaves the branch with avoidable governance and release-surface drift while deeper porting continues Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep using small, independently verifiable checkpoints on the rebuild branch; do not batch workflow/doc-support fixes back into the larger runtime/provider conflict set Tested: cargo fmt --all -- --check Tested: LOONG_ARCH_REPORT_MONTH=2026-04 bash scripts/check_architecture_drift_freshness.sh docs/releases/support/architecture-drift-2026-04.md Tested: scripts/bootstrap_release_local_artifacts.sh Tested: LOONG_RELEASE_DOCS_STRICT=1 scripts/check-docs.sh Tested: bash scripts/test_install_sh.sh Tested: cargo check -p loong-app -p loong --all-targets Not-tested: GitHub Actions on the rebuild branch yet Not-tested: full workspace test matrix on the rebuild branch
…ping legacy metadata This checkpoint moves the app build metadata and presentation layer to Loong-first naming so the rebuilt latest-dev branch no longer depends on LOONGCLAW_* build envs or LOONGCLAW banner text as the primary surface. It keeps backward compatibility by accepting legacy LOONGCLAW_* env overrides and emitting both new and legacy rustc env keys while the rest of the stack is still being rebuilt. Constraint: the rebuild branch already switched several workflow and runtime surfaces to LOONG_* names, so keeping build metadata hard-wired to LOONGCLAW_* would leave binary identity and CI inputs inconsistent Constraint: current dev still contains legacy readers, so the build layer must preserve LOONGCLAW_* compatibility while introducing LOONG_* as the primary path Rejected: Flip build metadata to LOONG_* only in one step | risks breaking remaining legacy readers before the rest of the rebuild is finished Rejected: Leave presentation banners on LOONGCLAW until the very end | keeps the user-facing runtime identity inconsistent with the rebuilt workflow/runtime surfaces Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep LOONG_* as the primary build/presentation surface, but preserve LOONGCLAW_* compatibility only where older code still consumes build metadata during the rebuild period Tested: cargo fmt --all -- --check Tested: cargo check -p loong-app -p loong --all-targets Tested: cargo test -p loong-app default_export_path_uses_loong_exports_directory --lib Tested: cargo test -p loong-app augment_tool_payload_injects_visible_tool_ids_for_tool_search --lib Not-tested: full workspace test matrix on the rebuild branch Not-tested: GitHub Actions on a replacement PR head yet
… readers This checkpoint ports the next identity layer onto the latest-dev rebuild branch: Loong becomes the primary config display name, audit defaults resolve under the Loong home path, context-engine selection accepts LOONG_CONTEXT_ENGINE first, and runtime config/env handling recognizes LOONG_CONFIG_PATH and LOONG_WEB_SEARCH_PROVIDER while preserving LOONGCLAW_* compatibility. The goal is to make the rebuilt branch's user- and operator-facing config surface consistent with the earlier workflow/build/runtime rebrand checkpoints without forcing an immediate break from legacy env readers. Constraint: the latest-dev branch still has broad LOONGCLAW_* env usage, so the rebuild must prefer Loong-first names while keeping compatibility reads and writes until the deeper runtime port is finished Rejected: Flip every runtime/config env to LOONG_* only in one pass | too risky while many latest-dev modules still read the legacy names directly Rejected: Leave product/config identity on LoongClaw until the very end | keeps workflows, build metadata, installer guidance, and config/runtime identity internally inconsistent Confidence: high Scope-risk: narrow Reversibility: clean Directive: Prefer LOONG_* for new guidance and primary reads, but keep legacy LOONGCLAW_* compatibility paths until the whole runtime surface is rebuilt on latest dev Tested: cargo fmt --all -- --check Tested: bash scripts/test_install_sh.sh Tested: cargo check -p loong-app -p loong --all-targets Tested: cargo test -p loong-app augment_tool_payload_injects_visible_tool_ids_for_tool_search --lib Tested: cargo test -p loong-app default_export_path_uses_loong_exports_directory --lib Not-tested: full workspace test matrix on the rebuild branch Not-tested: GitHub Actions on a replacement PR head yet
…trypoints This restack tightens the latest-dev rebuild branch around the active runtime surfaces rather than reviving older PR-era behavior. It moves app-facing runtime/config helpers onto Loong-first type names, adds a first-class runtime tool-view helper, keeps provider parse telemetry dual-written under both Loong and legacy keys, and makes onboard test executable discovery prefer the new env name while preserving the legacy fallback. It also moves the default provider profile-state file path onto the Loong home directory and locks the new compatibility behavior with focused unit coverage. The goal is to keep the non-doc rebrand progressing on current dev without regressing daemon/runtime API evolution or breaking existing payload/tooling consumers that still speak legacy aliases. Constraint: Current latest-dev still needs legacy runtime aliases and metadata keys for compatibility Constraint: The PR branch is being rebuilt on top of moving dev history, so changes must stay low-conflict and behavior-preserving Rejected: Hard-cut legacy provider parse metadata keys immediately | too risky for downstream readers and old fixtures Rejected: Revive older PR branch logic wholesale | would reintroduce stale API behavior against current dev Confidence: high Scope-risk: moderate Reversibility: clean Directive: Keep Loong-first names primary in runtime-facing code, but preserve legacy fallbacks until the Cargo/dependency-level alias migration is planned separately Tested: cargo fmt --all -- --check; cargo clippy -p loong-app --lib -- -D warnings; cargo test -p loong-app build_onboard_command_prefers_loong_test_override --lib; cargo test -p loong-app build_onboard_command_falls_back_to_legacy_override --lib; cargo test -p loong-app reload_cli_turn_config_refreshes_provider_state_without_mutating_cli_settings --lib; cargo test -p loong-app file_profile_state_backend_defaults_to_loong_home --lib; cargo test -p loong-app build_base_messages_with_binding_skips_runtime_self_reads_when_disabled --lib; cargo test -p loong-app default_engine_assembles_runtime_self_through_kernel_audit_path --lib; cargo test -p loong-app append_prompt_cache_headers_inserts_runtime_request_metadata --lib; cargo test -p loong-app extract_provider_turn_parses_plain_json_tool_block --lib; cargo test -p loong-app extract_provider_turn_parses_function_calls_invoke_blocks --lib; cargo test -p loong-app extract_provider_turn_records_malformed_inline_function_telemetry --lib Not-tested: cargo check -p loong --bin loong still hits a local rustup target-install conflict unrelated to these code changes
The PR restack left the bug-report issue template out of sync with the generated label taxonomy artifacts. Refreshing the generated template keeps the governance lane reproducible and avoids blocking the rebuilt rebrand branch on repository policy drift rather than runtime code behavior. Constraint: Governance CI treats generated label taxonomy artifacts as checked-in source of truth Rejected: Hand-edit the issue template wording only | would leave the generator/check pipeline inconsistent Confidence: high Scope-risk: narrow Reversibility: clean Directive: When rebrand or workflow restacks touch governance surfaces, rerun scripts/sync_github_labels.py before pushing to keep generated issue-template artifacts aligned Tested: python3 scripts/sync_github_labels.py --write; python3 scripts/sync_github_labels.py --check; bash scripts/test_sync_github_labels.sh; git diff --check Not-tested: Full governance GitHub Actions lane rerun after push remains pending
The rebuilt PR branch was still carrying script-level seams where the active Loong-first naming no longer matched test fixtures or workspace package names. This update makes the architecture drift generators/freshness checks honor Loong-first env names while still accepting the legacy LOONGCLAW overrides used by existing regression tests, and it retargets benchmark/perf/stress script Cargo entrypoints at the current workspace package name. The goal is to keep the latest-dev rebuild mature at the governance and CI edge: generated drift reports should stay reproducible regardless of whether callers still export legacy env names, and perf/stress harnesses should stop failing on stale package identifiers after the package rename. Constraint: Governance and perf lanes still exercise legacy LOONGCLAW_* env overrides in checked-in shell tests Constraint: Workspace package names have already moved to loong, so script entrypoints must not lag behind the rename Rejected: Update only the failing CI script and leave other benchmark/stress entrypoints stale | would leave the PR with known adjacent breakage Rejected: Drop legacy architecture-drift env aliases entirely | would break the existing regression fixtures and slow the rebuild lane Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep shell entrypoints aligned with current workspace package names, but continue honoring legacy env aliases where checked-in governance tests still depend on them Tested: bash scripts/test_generate_architecture_drift_report.sh; bash scripts/test_check_architecture_drift_freshness.sh; bash scripts/test_architecture_budget_scripts.sh; bash scripts/test_stress_daemon_tests.sh; bash scripts/test_sync_github_labels.sh; bash -n scripts/generate_architecture_drift_report.sh scripts/check_architecture_drift_freshness.sh scripts/lint_programmatic_pressure_baseline.sh scripts/benchmark_programmatic_pressure.sh scripts/benchmark_wasm_cache.sh scripts/stress_daemon_tests.sh; git diff --check Not-tested: ./scripts/lint_programmatic_pressure_baseline.sh still hits the same local rustup target-install conflict after moving past the stale package-name failure, so final proof for that lane is deferred to GitHub Actions
The release workflow had already moved to LOONG_RELEASE_DOCS_STRICT, but the doc-check script and its hardening regression still assumed the legacy LOONGCLAW name. That mismatch left governance CI red even after the restack because the workflow and the checked-in policy test no longer described the same contract. This change makes the docs gate prefer the Loong-first env name while preserving the legacy alias as a fallback, and updates the workflow hardening test to assert the current workflow contract. That keeps the strict docs lane compatible for older callers without letting governance drift behind the active release workflow. Constraint: Release workflow already exports the Loong-first strict-docs env name in CI Constraint: Existing local/bootstrap tests still invoke the legacy env name and should not be broken during the rebuild lane Rejected: Update only the regression test string | would leave check-docs.sh itself inconsistent with the live workflow Rejected: Remove the legacy alias now | unnecessary compatibility break during PR stabilization Confidence: high Scope-risk: narrow Reversibility: clean Directive: Treat release-doc strict gating like other rebrand surfaces: new env name first, legacy alias second, and keep the workflow tests pinned to the live workflow contract Tested: bash scripts/test_release_workflow_hardening.sh; bash scripts/test_bootstrap_release_local_artifacts.sh; bash -n scripts/check-docs.sh scripts/test_release_workflow_hardening.sh; git diff --check Not-tested: Full GitHub governance lane rerun after push remains pending
The latest runtime/config and script cleanup changed several tracked hotspot metrics, so the committed April 2026 architecture drift reports no longer matched the generated governance artifacts. Refreshing both the support-path report and the root release-path mirror keeps the release-governance evidence aligned with the rebuilt PR branch and clears the freshness gate without changing product behavior. Constraint: Governance CI requires the tracked support drift report to match freshly generated architecture metrics Constraint: The repo keeps both support-path and root release-path drift reports in sync for release review surfaces Rejected: Update only the support report to satisfy the immediate gate | would leave the mirrored root report stale and invite the next governance mismatch Confidence: high Scope-risk: narrow Reversibility: clean Directive: Whenever hotspot-touching code lands on this branch, refresh both April 2026 drift reports together instead of patching only the support copy Tested: LOONG_ARCH_REPORT_MONTH=2026-04 scripts/generate_architecture_drift_report.sh docs/releases/support/architecture-drift-2026-04.md; LOONG_ARCH_REPORT_MONTH=2026-04 scripts/generate_architecture_drift_report.sh docs/releases/architecture-drift-2026-04.md; LOONG_ARCH_REPORT_MONTH=2026-04 bash scripts/check_architecture_drift_freshness.sh docs/releases/support/architecture-drift-2026-04.md; git diff --check Not-tested: Full GitHub governance lane rerun after push remains pending
…t surfaces The PR's Loong-first package and runtime rename was directionally correct, but it left three real breakpoints behind: renamed library crates no longer matched existing imports/tests, installer compatibility seams were removed while the repo still advertised them, and newer Loong env/context keys were introduced without end-to-end entrypoint coverage. This patch keeps the Loong-facing package/runtime progression while restoring the compatibility guarantees that current users and the repo contract still assume. It also updates the affected tests to assert the new Loong branding without regressing the guarded behavior they were meant to protect. Constraint: PR eastreams#1108 already renames package identities and runtime-facing names, so the fix had to preserve that direction instead of rolling the rebrand back Rejected: Remove legacy installer/env/bin seams now | breaks documented and exercised compatibility surfaces during the migration window Rejected: Rename every remaining test/import to new crate names only | larger churn than necessary and drops useful compatibility aliases Confidence: high Scope-risk: moderate Reversibility: clean Directive: Keep dual-read and dual-entry compatibility in place until release/install/docs contracts no longer advertise the legacy seams Tested: bash scripts/test_install_sh.sh Tested: bash scripts/check_dep_graph.sh Tested: ./scripts/check_architecture_boundaries.sh Tested: cargo clippy --workspace --all-targets --all-features --target aarch64-apple-darwin -- -D warnings Tested: cargo test --workspace --all-features --target aarch64-apple-darwin Not-tested: GitHub Actions after the new commit
0eb9246 to
9efa46d
Compare
Summary
This PR finishes the code-facing Loong rebrand outside the docs lane handled by #756.
It updates the workspace so that package metadata, runtime-facing names, scripts, workflows, and release-governance tooling consistently use the
Loongbrand, while keeping the explicitly preserved legacy contact endpoints unchanged.What changed
loongclaw-*toloong-*LoongClawKernel/LoongClawConfigtoLoongKernel/LoongConfigLOONGCLAW_*/.loongclawtoLOONG_*/.loongloongclawshim binary)eastreams/loongcontact@loongclaw.ai,https://t.me/loongclaw)Notes
loongclawreferences in this lane are limited to preserved legacy contact/community endpoints and compatibility aliases.Validation
cargo fmt --allcargo check --workspace --all-targetscargo clippy --workspace --all-targets --all-features -- -D warningscargo test -p loong-kernel --test kernel_integrationbash scripts/check_dep_graph.shbash scripts/test_architecture_budget_scripts.shbash scripts/test_check_architecture_drift_freshness.shbash scripts/test_bootstrap_release_local_artifacts.shbash scripts/test_install_sh.shgit diff --checkCloses #1107