feat(labs): add AgentStream code

[Dawson (LHXXHB)]

Summary

Add AgentStream code and documentation under labs/AgentStream.

This change also documents its separate Apache-2.0 license scope and updates the changelog.

Validation

• Pre-commit checks passed for all files changed by this PR.
• Python syntax validation passed for the AgentStream source files.

Notes for reviewers

This change does not modify Sico's backend, core, frontend, deployment, or generated API files.

[Dawson (LHXXHB)]

@microsoft-github-policy-service agree company="Microsoft"

[jason (jasonchen922)]

[The nested workflows will not run]

These workflow files are under labs/AgentStream/exgentic/.github/workflows/, so GitHub Actions will not discover them. GitHub only loads workflows from the repository-level workflows directory.

The green checks on this PR only show that Sico’s existing CI passed; they do not show that AgentStream’s tests, Ruff, detect-secrets, SPDX checks, or other project-specific checks were executed.

Please either move the checks we want to keep into a root-level workflow, scoped with paths: labs/AgentStream/** and working-directory: labs/AgentStream/exgentic, or remove these files if they are only leftovers from the upstream repository and are not intended to run in Sico. Keeping inactive workflow files here is misleading.

[jason (jasonchen922)]

[The release and versioning setup has not been adapted to the monorepo]

This still appears to use the release model from when exgentic was a standalone repository, and it has not yet been adapted to the Sico monorepo.

In addition to publish-pypi.yml being in a nested directory and therefore never triggering, the current hatch-vcs configuration matches every v* tag. Sico already uses tags such as v0.1.0, v0.2.0, and v0.3.0, so Sico and exgentic would share the same release tag namespace. The release documentation also still configures the PyPI Trusted Publisher for Exgentic/exgentic rather than microsoft/Sico.

We should first decide whether exgentic is intended to be published independently from this repository. If it is, please use a separate tag format such as exgentic-v*, add a root-level publishing workflow with the correct working directory, and update the Trusted Publisher configuration. If it is not published from Sico, these publishing files and instructions should be removed or updated accordingly.

[jason (jasonchen922)]

[Standalone-repository links and governance files remain]

Could we document whether labs/AgentStream/exgentic is a vendored upstream snapshot or a Sico-maintained fork? The current files mix both models: AgentStream installs it from Sico, while Exgentic’s development, support, and release documentation still points to the upstream repository. Clarifying this ownership boundary would help avoid future maintenance confusion.

[Dawson (LHXXHB)]

Thanks for the detailed review, jason (@jasonchen922). I addressed the comments in 61470f0:

• removed the inactive nested workflows and standalone publishing configuration;
• replaced VCS-based versioning with a static version;
• clarified the status of the bundled Exgentic copy and aligned its contribution, support, and governance references with Sico;
• updated the root repository layout and changelog.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.

[Dawson (LHXXHB)]

Thanks, jason (@jasonchen922). These checks are intentionally manual for the bundled snapshot. I updated the configuration and DEVELOPMENT.md with a working command from the Sico root and verified that it passes without modifying the working tree.

[jason (jasonchen922)]

Thanks, jason (jason (@jasonchen922)). These checks are intentionally manual for the bundled snapshot. I updated the configuration and DEVELOPMENT.md with a working command from the Sico root and verified that it passes without modifying the working tree.

Thanks for making the component checks runnable from the Sico root. I tested the documented command on macOS and found one remaining portability issue: the four local hooks use language: system with entry: python ..., while a standard macOS Python installation commonly exposes only python3. In that environment, all four hooks fail with Executable 'python' not found. After temporarily mapping python to python3, all non-network hooks passed. Could we use python3 consistently in the hook entries and documentation, or use a pre-commit-managed Python environment so the command works without relying on a system python alias?

[Dawson (LHXXHB)]

Thanks for testing this. I switched the four local hooks to a pre-commit-managed Python environment, so they no longer rely on a system python alias. All eight pre-commit checks pass without modifying the working tree.