updating plano docs, README and CLI

docs/source/guides/observability/access_logging.rst

@@ -3,14 +3,14 @@
 Access Logging
 ==============
 
-Access logging in Arch refers to the logging of detailed information about each request and response that flows through Arch.
-It provides visibility into the traffic passing through Arch, which is crucial for monitoring, debugging, and analyzing the
+Access logging in Plano refers to the logging of detailed information about each request and response that flows through Plano.
+It provides visibility into the traffic passing through Plano, which is crucial for monitoring, debugging, and analyzing the
 behavior of AI applications and their interactions.
 
 Key Features
 ^^^^^^^^^^^^
 * **Per-Request Logging**:
-  Each request that passes through Arch is logged. This includes important metadata such as HTTP method,
+  Each request that passes through Plano is logged. This includes important metadata such as HTTP method,
   path, response status code, request duration, upstream host, and more.
 * **Integration with Monitoring Tools**:
   Access logs can be exported to centralized logging systems (e.g., ELK stack or Fluentd) or used to feed monitoring and alerting systems.
@@ -19,7 +19,7 @@ Key Features
 How It Works
 ^^^^^^^^^^^^
 
-Arch gateway exposes access logs for every call it manages on your behalf. By default these access logs can be found under ``~/archgw_logs``. For example:
+Plano exposes access logs for every call it manages on your behalf. By default these access logs can be found under ``~/archgw_logs``. For example:
 
 .. code-block:: console
 

docs/source/guides/observability/monitoring.rst

@@ -8,11 +8,11 @@ and instrumentation for generating, collecting, processing, and exporting teleme
 metrics, and logs. Its flexible design supports a wide range of backends and seamlessly integrates with
 modern application tools.
 
-Arch acts a *source* for several monitoring metrics related to **prompts** and **LLMs** natively integrated
+Plano acts a *source* for several monitoring metrics related to **agents** and **LLMs** natively integrated
 via `OpenTelemetry <https://opentelemetry.io/>`_ to help you understand three critical aspects of your application:
 latency, token usage, and error rates by an upstream LLM provider. Latency measures the speed at which your application
 is responding to users, which includes metrics like time to first token (TFT), time per output token (TOT) metrics, and
-the total latency as perceived by users. Below are some screenshots how Arch integrates natively with tools like
+the total latency as perceived by users. Below are some screenshots how Plano integrates natively with tools like
 `Grafana <https://grafana.com/grafana/dashboards/>`_ via `Promethus <https://prometheus.io/>`_
 
 
@@ -32,7 +32,7 @@ Metrics Dashboard (via Grafana)
 
 Configure Monitoring
 ~~~~~~~~~~~~~~~~~~~~
-Arch gateway publishes stats endpoint at http://localhost:19901/stats. As noted above, Arch is a source for metrics. To view and manipulate dashbaords, you will
+Plano publishes stats endpoint at http://localhost:19901/stats. As noted above, Plano is a source for metrics. To view and manipulate dashbaords, you will
 need to configiure `Promethus <https://prometheus.io/>`_ (as a metrics store) and `Grafana <https://grafana.com/grafana/dashboards/>`_ for dashboards. Below
 are some sample configuration files for both, respectively.
 

docs/source/guides/observability/tracing.rst

@@ -41,7 +41,7 @@ Benefits of Using ``Traceparent`` Headers
 How to Initiate A Trace
 -----------------------
 
-1. **Enable Tracing Configuration**: Simply add the ``random_sampling`` in ``tracing`` section to 100`` flag to in the :ref:`listener <arch_overview_listeners>` config
+1. **Enable Tracing Configuration**: Simply add the ``random_sampling`` in ``tracing`` section to 100`` flag to in the :ref:`listener <plano_overview_listeners>` config
 
 2. **Trace Context Propagation**: Arch automatically propagates the ``traceparent`` header. When a request is received, Arch will: