Merge remote-tracking branch 'origin/main' into musa/cli

docs/source/_ext/provider_models.py

@@ -19,7 +19,7 @@ def _on_build_finished(app: Sphinx, exception: Exception | None) -> None:
         return
 
     # Source path: provider_models.yaml is copied into the Docker image at /docs/provider_models.yaml
-    # This follows the pattern used for config templates like envoy.template.yaml and arch_config_schema.yaml
+    # This follows the pattern used for config templates like envoy.template.yaml and plano_config_schema.yaml
     docs_root = Path(app.srcdir).parent  # Goes from source/ to docs/
     source_path = docs_root / "provider_models.yaml"
 

docs/source/build_with_plano/includes/agent/function-calling-agent.yaml

@@ -48,7 +48,7 @@ prompt_targets:
           description: Time range in days for which to gather device statistics. Defaults to 7.
           default: 7
 
-# Arch creates a round-robin load balancing between different endpoints, managed via the cluster subsystem.
+# Plano creates a round-robin load balancing between different endpoints, managed via the cluster subsystem.
 endpoints:
   app_server:
     # value could be ip address or a hostname with port

docs/source/concepts/includes/plano_config.yaml

@@ -18,7 +18,7 @@ prompt_targets:
     endpoint:
       name: app_server
       path: /agent/summary
-    # Arch uses the default LLM and treats the response from the endpoint as the prompt to send to the LLM
+    # Plano uses the default LLM and treats the response from the endpoint as the prompt to send to the LLM
     auto_llm_dispatch_on_response: true
     # override system prompt for this prompt target
     system_prompt: You are a helpful information extraction assistant. Use the information that is provided to you.
@@ -39,7 +39,7 @@ prompt_targets:
         default: false
         enum: [true, false]
 
-# Arch creates a round-robin load balancing between different endpoints, managed via the cluster subsystem.
+# Plano creates a round-robin load balancing between different endpoints, managed via the cluster subsystem.
 endpoints:
   app_server:
     # value could be ip address or a hostname with port

docs/source/concepts/llm_providers/client_libraries.rst

@@ -54,7 +54,7 @@ The OpenAI SDK works with any provider through Plano's OpenAI-compatible endpoin
         base_url="http://127.0.0.1:12000/v1"
     )
 
-    # Use any model configured in your arch_config.yaml
+    # Use any model configured in your plano_config.yaml
     completion = client.chat.completions.create(
         model="gpt-4o-mini",  # Or use :ref:`model aliases <model_aliases>` like "fast-model"
         max_tokens=50,
@@ -231,7 +231,7 @@ The Anthropic SDK works with any provider through Plano's Anthropic-compatible e
         base_url="http://127.0.0.1:12000"
     )
 
-    # Use any model configured in your arch_config.yaml
+    # Use any model configured in your plano_config.yaml
     message = client.messages.create(
         model="claude-3-5-sonnet-20241022",
         max_tokens=50,

docs/source/concepts/prompt_target.rst

@@ -114,7 +114,7 @@ Example 1: Adjusting Retrieval
 
     User: What are the benefits of renewable energy?
     **[Plano]**: Check if there is an available <prompt_target> that can handle this user query.
-    **[Plano]**: Found "get_info_for_energy_source" prompt_target in arch_config.yaml. Forward prompt to the endpoint configured in "get_info_for_energy_source"
+    **[Plano]**: Found "get_info_for_energy_source" prompt_target in plano_config.yaml. Forward prompt to the endpoint configured in "get_info_for_energy_source"
     ...
     Assistant: Renewable energy reduces greenhouse gas emissions, lowers air pollution, and provides sustainable power sources like solar and wind.
 
@@ -130,13 +130,13 @@ Example 2: Switching Intent
 
     User: What are the symptoms of diabetes?
     **[Plano]**: Check if there is an available <prompt_target> that can handle this user query.
-    **[Plano]**: Found "diseases_symptoms" prompt_target in arch_config.yaml. Forward disease=diabeteres to "diseases_symptoms" prompt target
+    **[Plano]**: Found "diseases_symptoms" prompt_target in plano_config.yaml. Forward disease=diabeteres to "diseases_symptoms" prompt target
     ...
     Assistant: Common symptoms include frequent urination, excessive thirst, fatigue, and blurry vision.
 
     User: How is it diagnosed?
     **[Plano]**: New intent detected.
-    **[Plano]**: Found "disease_diagnoses" prompt_target in arch_config.yaml. Forward disease=diabeteres to "disease_diagnoses" prompt target
+    **[Plano]**: Found "disease_diagnoses" prompt_target in plano_config.yaml. Forward disease=diabeteres to "disease_diagnoses" prompt target
     ...
     Assistant: Diabetes is diagnosed through blood tests like fasting blood sugar, A1C, or an oral glucose tolerance test.
 
@@ -172,7 +172,7 @@ Once the prompt targets are configured as above, handle parameters across multi-
 Demo App
 --------
 
-For your convenience, we've built a `demo app <https://github.com/katanemo/archgw/tree/main/demos/samples_python/multi_turn_rag_agent>`_
+For your convenience, we've built a `demo app <https://github.com/katanemo/plano/tree/main/demos/advanced/multi_turn_rag>`_
 that you can test and modify locally for multi-turn RAG scenarios.
 
 .. figure:: ../build_with_plano/includes/multi_turn/mutli-turn-example.png

docs/source/conf.py

@@ -17,7 +17,7 @@ from sphinxawesome_theme.postprocess import Icons
 project = "Plano Docs"
 copyright = "2025, Katanemo Labs, Inc"
 author = "Katanemo Labs, Inc"
-release = " v0.4.6"
+release = " v0.4.7"
 
 # -- General configuration ---------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#general-configuration

docs/source/get_started/quickstart.rst

@@ -37,7 +37,7 @@ Plano's CLI allows you to manage and interact with the Plano efficiently. To ins
 
 .. code-block:: console
 
-   $ uv tool install planoai==0.4.6
+   $ uv tool install planoai==0.4.7
 
 **Option 2: Install with pip (Traditional)**
 
@@ -45,7 +45,7 @@ Plano's CLI allows you to manage and interact with the Plano efficiently. To ins
 
    $ python -m venv venv
    $ source venv/bin/activate   # On Windows, use: venv\Scripts\activate
-   $ pip install planoai==0.4.6
+   $ pip install planoai==0.4.7
 
 
 .. _llm_routing_quickstart:
@@ -90,7 +90,7 @@ Start Plano:
 
    $ planoai up plano_config.yaml
    # Or if installed with uv tool: uvx planoai up plano_config.yaml
-   2024-12-05 11:24:51,288 - planoai.main - INFO - Starting plano cli version: 0.4.6
+   2024-12-05 11:24:51,288 - planoai.main - INFO - Starting plano cli version: 0.4.7
    2024-12-05 11:24:51,825 - planoai.utils - INFO - Schema validation successful!
    2024-12-05 11:24:51,825 - planoai.main - INFO - Starting plano
    ...

docs/source/guides/includes/config.yaml

@@ -24,7 +24,7 @@ prompt_targets:
       name: app_server
       path: /agent/summary
       http_method: POST
-    # Arch uses the default LLM and treats the response from the endpoint as the prompt to send to the LLM
+    # Plano uses the default LLM and treats the response from the endpoint as the prompt to send to the LLM
     auto_llm_dispatch_on_response: true
     # override system prompt for this prompt target
     system_prompt: You are a helpful information extraction assistant. Use the information that is provided to you.
@@ -46,7 +46,7 @@ prompt_targets:
         default: false
         enum: [true, false]
 
-# Arch creates a round-robin load balancing between different endpoints, managed via the cluster subsystem.
+# Plano creates a round-robin load balancing between different endpoints, managed via the cluster subsystem.
 endpoints:
   app_server:
     # value could be ip address or a hostname with port

docs/source/guides/observability/access_logging.rst

@@ -1,4 +1,4 @@
-.. _arch_access_logging:
+.. _plano_access_logging:
 
 Access Logging
 ==============

docs/source/guides/observability/tracing.rst

@@ -1,4 +1,4 @@
-.. _arch_overview_tracing:
+.. _plano_overview_tracing:
 
 Tracing
 =======

docs/source/guides/orchestration.rst

@@ -342,7 +342,7 @@ Next Steps
 * Explore :ref:`filter chains <filter_chain>` for adding guardrails and context enrichment
 * See :ref:`observability <observability>` for monitoring multi-agent workflows
 * Review the :ref:`LLM Providers <llm_providers>` guide for model routing within agents
-* Check out the complete `Travel Booking demo <https://github.com/katanemo/plano/tree/main/demos/use_cases/travel_booking>`_ on GitHub
+* Check out the complete `Travel Booking demo <https://github.com/katanemo/plano/tree/main/demos/agent_orchestration/travel_agents>`_ on GitHub
 
 .. note::
     To observe traffic to and from agents, please read more about :ref:`observability <observability>` in Plano.

docs/source/guides/state.rst

@@ -57,7 +57,7 @@ Configuration Overview
 
 State storage is configured in the ``state_storage`` section of your ``plano_config.yaml``:
 
-.. literalinclude:: ../resources/includes/arch_config_state_storage_example.yaml
+.. literalinclude:: ../resources/includes/plano_config_state_storage_example.yaml
     :language: yaml
     :lines: 21-30
     :linenos:

docs/source/resources/configuration_reference.rst

@@ -4,10 +4,10 @@ Configuration Reference
 =======================
 
 The following is a complete reference of the ``plano_config.yml`` that controls the behavior of a single instance of
-the Arch gateway. This where you enable capabilities like routing to upstream LLm providers, defining prompt_targets
+the Plano gateway. This where you enable capabilities like routing to upstream LLm providers, defining prompt_targets
 where prompts get routed to, apply guardrails, and enable critical agent observability features.
 
-.. literalinclude:: includes/arch_config_full_reference.yaml
+.. literalinclude:: includes/plano_config_full_reference.yaml
     :language: yaml
     :linenos:
-    :caption: :download:`Plano Configuration - Full Reference <includes/arch_config_full_reference.yaml>`
+    :caption: :download:`Plano Configuration - Full Reference <includes/plano_config_full_reference.yaml>`

docs/source/resources/deployment.rst

@@ -25,7 +25,7 @@ Create a ``docker-compose.yml`` file with the following configuration:
    # docker-compose.yml
    services:
      plano:
-       image: katanemo/plano:0.4.6
+       image: katanemo/plano:0.4.7
        container_name: plano
        ports:
          - "10000:10000" # ingress (client -> plano)

docs/source/resources/includes/plano_config_agents_filters.yaml

@@ -30,7 +30,7 @@ listeners:
   - type: agent
     name: agent_1
     port: 8001
-    router: arch_agent_router
+    router: plano_agent_router
     agents:
       - id: rag_agent
         description: virtual assistant for retrieval augmented generation tasks

docs/source/resources/includes/plano_config_full_reference.yaml

@@ -1,4 +1,4 @@
-# Arch Gateway configuration version
+# Plano Gateway configuration version
 version: v0.3.0
 
 # External HTTP agents - API type is controlled by request path (/v1/responses, /v1/messages, /v1/chat/completions)

docs/source/resources/tech_overview/request_lifecycle.rst

@@ -41,7 +41,7 @@ The request processing path in Plano has three main parts:
 
 These two subsystems are bridged with either the HTTP router filter, and the cluster manager subsystems of Envoy.
 
-Also, Plano utilizes `Envoy event-based thread model <https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310>`_. A main thread is responsible for the server lifecycle, configuration processing, stats, etc. and some number of :ref:`worker threads <arch_overview_threading>` process requests. All threads operate around an event loop (`libevent <https://libevent.org/>`_) and any given downstream TCP connection will be handled by exactly one worker thread for its lifetime. Each worker thread maintains its own pool of TCP connections to upstream endpoints.
+Also, Plano utilizes `Envoy event-based thread model <https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310>`_. A main thread is responsible for the server lifecycle, configuration processing, stats, etc. and some number of :ref:`worker threads <plano_overview_threading>` process requests. All threads operate around an event loop (`libevent <https://libevent.org/>`_) and any given downstream TCP connection will be handled by exactly one worker thread for its lifetime. Each worker thread maintains its own pool of TCP connections to upstream endpoints.
 
 Worker threads rarely share state and operate in a trivially parallel fashion. This threading model
 enables scaling to very high core count CPUs.
@@ -130,8 +130,8 @@ Once a request completes, the stream is destroyed. The following also takes plac
 * The post-request :ref:`monitoring <monitoring>` are updated (e.g. timing, active requests, upgrades, health checks).
   Some statistics are updated earlier however, during request processing. Stats are batched and written by the main
   thread periodically.
-* :ref:`Access logs <arch_access_logging>` are written to the access log
-* :ref:`Trace <arch_overview_tracing>` spans are finalized. If our example request was traced, a
+* :ref:`Access logs <plano_access_logging>` are written to the access log
+* :ref:`Trace <plano_overview_tracing>` spans are finalized. If our example request was traced, a
   trace span, describing the duration and details of the request would be created by the HCM when
   processing request headers and then finalized by the HCM during post-request processing.
 

docs/source/resources/tech_overview/threading_model.rst

@@ -1,4 +1,4 @@
-.. _arch_overview_threading:
+.. _plano_overview_threading:
 
 Threading Model
 ===============