Copilot/loop action

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,31 @@
+## Summary
+
+<!-- What does this PR change and why? -->
+
+## Type of change
+
+- [ ] Bug fix
+- [ ] New provider / API surface
+- [ ] Refactor
+- [ ] Documentation
+- [ ] Tests / CI
+- [ ] Other
+
+## Checklist
+
+- [ ] Builds with the package’s supported Xcode/Swift versions
+- [ ] Tests added or updated when behavior changes
+- [ ] No secrets or API keys committed
+- [ ] Docs updated if products, targets, public API, or dependencies changed:
+  - [ ] `README.md`
+  - [ ] `docs/ARCHITECTURE.md` (graph / tables)
+  - [ ] `CHANGELOG.md` (`[Unreleased]`)
+- [ ] Layering respected (providers → `LargeLanguageModels` → `CoreMI`; avoid new provider→provider deps)
+
+## Test plan
+
+<!-- How did you verify? Unit tests, manual API calls, platforms… -->
+
+## Related issues
+
+<!-- Fixes #… -->

.github/dependabot.ymlv

@@ -0,0 +1,11 @@
+# To get started with Dependabot version updates, you'll need to specify which
+# package ecosystems to update and where the package manifests are located.
+# Please see the documentation for all configuration options:
+# https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
+
+version: 2
+updates:
+  - package-ecosystem: "" # See documentation for possible values
+    directory: "/" # Location of package manifests
+    schedule:
+      interval: "weekly"

.github/workflows/apisec-scan.yml

@@ -0,0 +1,71 @@
+# This workflow uses actions that are not certified by GitHub.
+# They are provided by a third-party and are governed by
+# separate terms of service, privacy policy, and support
+# documentation.
+
+# APIsec addresses the critical need to secure APIs before they reach production.
+# APIsec provides the industry’s only automated and continuous API testing platform that uncovers security vulnerabilities and logic flaws in APIs.
+# Clients rely on APIsec to evaluate every update and release, ensuring that no APIs go to production with vulnerabilities.
+
+# How to Get Started with APIsec.ai
+# 1. Schedule a demo at https://www.apisec.ai/request-a-demo .
+#
+# 2. Register your account at https://cloud.apisec.ai/#/signup .
+#
+# 3. Register your API . See the video (https://www.youtube.com/watch?v=MK3Xo9Dbvac) to get up and running with APIsec quickly.
+#
+# 4. Get GitHub Actions scan attributes from APIsec Project -> Configurations -> Integrations -> CI-CD -> GitHub Actions
+#
+# apisec-run-scan
+#
+# This action triggers the on-demand scans for projects registered in APIsec.
+# If your GitHub account allows code scanning alerts, you can then upload the sarif file generated by this action to show the scan findings.
+# Else you can view the scan results from the project home page in APIsec Platform.
+# The link to view the scan results is also displayed on the console on successful completion of action.
+
+# This is a starter workflow to help you get started with APIsec-Scan Actions
+
+name: APIsec
+
+# Controls when the workflow will run
+on:
+  # Triggers the workflow on push or pull request events but only for the "main" branch
+  # Customize trigger events based on your DevSecOps processes.
+  push:
+    branches: [ "main" ]
+  pull_request:
+    branches: [ "main" ]
+  schedule:
+    - cron: '27 1 * * 5'
+
+  # Allows you to run this workflow manually from the Actions tab
+  workflow_dispatch:
+
+
+permissions:
+  contents: read
+
+jobs:
+
+  Trigger_APIsec_scan:
+    permissions:
+      security-events: write # for github/codeql-action/upload-sarif to upload SARIF results
+      actions: read # only required for a private repository by github/codeql-action/upload-sarif to get the Action run status
+    runs-on: ubuntu-latest
+
+    steps:
+       - name: APIsec scan
+         uses: apisec-inc/apisec-run-scan@025432089674a28ba8fb55f8ab06c10215e772ea
+         with:
+          # The APIsec username with which the scans will be executed
+          apisec-username: ${{ secrets.apisec_username }}
+          # The Password of the APIsec user with which the scans will be executed
+          apisec-password: ${{ secrets.apisec_password}}
+          # The name of the project for security scan
+          apisec-project: "VAmPI"
+          # The name of the sarif format result file The file is written only if this property is provided.
+          sarif-result-file: "apisec-results.sarif"
+       - name: Import results
+         uses: github/codeql-action/upload-sarif@v3
+         with:
+          sarif_file: ./apisec-results.sarif

.github/workflows/codeql.yml

@@ -0,0 +1,99 @@
+# For most projects, this workflow file will not need changing; you simply need
+# to commit it to your repository.
+#
+# You may wish to alter this file to override the set of languages analyzed,
+# or to provide custom queries or build logic.
+#
+# ******** NOTE ********
+# We have attempted to detect the languages in your repository. Please check
+# the `language` matrix defined below to confirm you have the correct set of
+# supported CodeQL languages.
+#
+name: "CodeQL Advanced"
+
+on:
+  push:
+    branches: [ "main" ]
+  pull_request:
+    branches: [ "main" ]
+  schedule:
+    - cron: '15 21 * * 5'
+
+jobs:
+  analyze:
+    name: Analyze (${{ matrix.language }})
+    # Runner size impacts CodeQL analysis time. To learn more, please see:
+    #   - https://gh.io/recommended-hardware-resources-for-running-codeql
+    #   - https://gh.io/supported-runners-and-hardware-resources
+    #   - https://gh.io/using-larger-runners (GitHub.com only)
+    # Consider using larger runners or machines with greater resources for possible analysis time improvements.
+    runs-on: ${{ (matrix.language == 'swift' && 'macos-latest') || 'ubuntu-latest' }}
+    permissions:
+      # required for all workflows
+      security-events: write
+
+      # required to fetch internal or private CodeQL packs
+      packages: read
+
+      # only required for workflows in private repositories
+      actions: read
+      contents: read
+
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+        - language: swift
+          build-mode: autobuild
+        # CodeQL supports the following values keywords for 'language': 'actions', 'c-cpp', 'csharp', 'go', 'java-kotlin', 'javascript-typescript', 'python', 'ruby', 'rust', 'swift'
+        # Use `c-cpp` to analyze code written in C, C++ or both
+        # Use 'java-kotlin' to analyze code written in Java, Kotlin or both
+        # Use 'javascript-typescript' to analyze code written in JavaScript, TypeScript or both
+        # To learn more about changing the languages that are analyzed or customizing the build mode for your analysis,
+        # see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning.
+        # If you are analyzing a compiled language, you can modify the 'build-mode' for that language to customize how
+        # your codebase is analyzed, see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v7
+
+    # Add any setup steps before running the `github/codeql-action/init` action.
+    # This includes steps like installing compilers or runtimes (`actions/setup-node`
+    # or others). This is typically only required for manual builds.
+    # - name: Setup runtime (example)
+    #   uses: actions/setup-example@v1
+
+    # Initializes the CodeQL tools for scanning.
+    - name: Initialize CodeQL
+      uses: github/codeql-action/init@v4
+      with:
+        languages: ${{ matrix.language }}
+        build-mode: ${{ matrix.build-mode }}
+        # If you wish to specify custom queries, you can do so here or in a config file.
+        # By default, queries listed here will override any specified in a config file.
+        # Prefix the list here with "+" to use these queries and those in the config file.
+
+        # For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
+        # queries: security-extended,security-and-quality
+
+    # If the analyze step fails for one of the languages you are analyzing with
+    # "We were unable to automatically build your code", modify the matrix above
+    # to set the build mode to "manual" for that language. Then modify this step
+    # to build your code.
+    # ℹ️ Command-line programs to run using the OS shell.
+    # 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
+    - name: Run manual build steps
+      if: matrix.build-mode == 'manual'
+      shell: bash
+      run: |
+        echo 'If you are using a "manual" build mode for one or more of the' \
+          'languages you are analyzing, replace this with the commands to build' \
+          'your code, for example:'
+        echo '  make bootstrap'
+        echo '  make release'
+        exit 1
+
+    - name: Perform CodeQL Analysis
+      uses: github/codeql-action/analyze@v4
+      with:
+        category: "/language:${{matrix.language}}"

.github/workflows/swift.yml

@@ -0,0 +1,22 @@
+# This workflow will build a Swift project
+# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-swift
+
+name: Swift
+
+on:
+  push:
+    branches: [ "main" ]
+  pull_request:
+    branches: [ "main" ]
+
+jobs:
+  build:
+
+    runs-on: macos-latest
+
+    steps:
+    - uses: actions/checkout@v4
+    - name: Build
+      run: swift build -v
+    - name: Run tests
+      run: swift test -v

CHANGELOG.md

@@ -0,0 +1,12 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+## [Unreleased]
+
+### Added
+
+- Added architecture documentation in `docs/ARCHITECTURE.md`.
+- Added contribution guidelines in `CONTRIBUTING.md`.
+- Improved `README.md` with architecture, dependency graph, and documentation links.
+- Added repository research and agent workflow guidance to `CONTRIBUTING.md`.

CONTRIBUTING.md

@@ -0,0 +1,123 @@
+---
+layout: default
+---
+
+# Contributing to Open Source Guides
+
+Thanks for checking out the Open Source Guides! We're excited to hear and learn from you. Your experiences will benefit others who read and use these guides.
+
+We've put together the following guidelines to help you figure out where you can best be helpful.
+
+## Table of Contents
+
+0. [Types of contributions we're looking for](#types-of-contributions-were-looking-for)
+0. [Ground rules & expectations](#ground-rules--expectations)
+0. [How to contribute](#how-to-contribute)
+0. [Style guide](#style-guide)
+0. [Setting up your environment](#setting-up-your-environment)
+0. [Community](#community)
+
+## Types of contributions we're looking for
+
+There are many ways you can directly contribute to the guides (in descending order of need):
+
+* Fix editorial inconsistencies or inaccuracies
+* [Translate guides into other languages](docs/translations.md)
+
+Interested in contributing to this Open Source Guide? Read on!
+
+## Ground rules & expectations
+
+Before we get started, here are a few things we expect from you (and that you should expect from others):
+
+* Be kind and thoughtful in your conversations around this project. We all come from different backgrounds and projects, which means we likely have different perspectives on "how open source is done." Try to listen to others rather than convince them that your way is correct.
+* Open Source Guides are released with a [Contributor Code of Conduct](./CODE_OF_CONDUCT.md). By participating in this project, you agree to abide by its terms.
+* Please ensure that your contribution passes all tests if you open a pull request. If there are test failures, you will need to address them before we can merge your contribution.
+* When adding content, please consider if it is widely valuable. Please don't add references or links to things you or your employer have created, as others will do so if they appreciate it.
+
+## How to contribute
+
+If you'd like to contribute, start by searching through the [pull requests](https://github.com/github/opensource.guide/pulls) to see whether someone else has raised a similar idea or question.
+
+If you don't see your idea listed, and you think it fits into the goals of this guide, open a pull request.
+
+## 💡 Quick Tip for Beginners
+
+1. Always create a new branch for your changes.
+2. Write clear commit messages.
+3. Test your changes locally before submitting a PR.
+4. Follow the style guide.
+5. Be patient during reviews.
+
+## Style guide
+
+If you're writing content, see the [style guide](./docs/styleguide.md) to help your prose match the rest of the guides.
+
+## Setting up your environment
+
+This site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/) along with [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm).
+
+Once you have that set up:
+
+1. Grant execution permissions to the scripts:
+
+```bash
+chmod +x script/bootstrap
+chmod +x script/server
+```
+
+2. Execute the scripts:
+
+```bash
+./script/bootstrap
+./script/server
+```
+
+…and open <http://localhost:4000> in your web browser.
+
+## Repository Research Plan
+
+When working in this repository, start by identifying the layer and capability you are changing before touching code.
+
+1. Map the affected API surface:
+   - `Sources/CoreMI`
+   - `Sources/LargeLanguageModels`
+   - `Sources/AI`
+   - the specific provider target under `Sources/`
+2. Inventory shared abstractions and extension points involved in the change:
+   - request handling
+   - model identifiers
+   - chat/completions
+   - embeddings
+   - audio, file, structured output, and tool-calling support
+3. Compare provider parity for that capability to avoid introducing one-off patterns.
+4. Audit the relevant tests under `Tests/` by capability as well as by provider.
+5. Update docs when package products, imports, architecture, or behavior change.
+6. Run `swift test` for code changes and record any notable validation steps in the pull request.
+
+## Agent / Workflow Roles
+
+Use focused ownership when splitting work across contributors or automation:
+
+- **Architecture**: owns module boundaries, `Package.swift`, and `docs/ARCHITECTURE.md`.
+- **Core abstractions**: owns `CoreMI` and `LargeLanguageModels` protocols, shared request/response behavior, and compatibility across providers.
+- **Provider**: owns one provider target at a time and aligns provider-specific APIs with shared abstractions.
+- **Test**: expands coverage in `Tests/`, adds reusable fixtures/helpers, and verifies `swift test`.
+- **Docs**: keeps `README.md`, `CONTRIBUTING.md`, `docs/ARCHITECTURE.md`, and `CHANGELOG.md` aligned with code changes.
+- **Release / governance**: checks change scope, public API impact, dependency layering, and pull request hygiene.
+
+Recommended workflow:
+
+1. Scope work to one layer or one provider.
+2. Review architecture or shared abstraction impact first.
+3. Implement the provider or core change.
+4. Update tests for behavior changes.
+5. Update docs for API, product, or architecture changes.
+6. Run `swift test`.
+7. Review for consistency with neighboring providers before merging.
+
+## Reporting Issues
+
+Discussions about the Open Source Guides take place on this repository's [Pull Requests](https://github.com/github/opensource.guide/pulls) section. Anybody is welcome to join these conversations.
+
+Wherever possible, do not take these conversations to private channels, including contacting the maintainers directly. Keeping communication public means everybody can benefit and learn from the conversation.