docs: update README

README.md

@@ -1,18 +1,10 @@
 # Architect
 
 <p align="center">
-  <img src="https://img.shields.io/npm/v/@perdition/architect-core" />
+  <img src="https://img.shields.io/jsr/v/@perdition/architect-core" />
+  <img src="https://img.shields.io/github/actions/workflow/status/RealityAnomaly/architect/test.yml?label=tests" />
 </p>
 
-Architect is a framework for constructing very complex structured configuration trees in TypeScript.
+Architect is a TypeScript-based IaC tool powered by [Deno](https://deno.com), built to handle massive JSON trees such as the resources in a Kubernetes cluster, Nix module parameters, or the configuration for a router. It's designed to be more lightweight than existing frameworks such as Terraform and Pulumi, and makes use of intelligent caching to speed up build times for a faster development loop.
 
-## Philosophy
-- Fast development loop. Architect uses `ts-node` - no manual `tsc` step is required.
-- Plainly visible behaviour. No hidden magic. What you declare in TypeScript is what runs.
-
-## Concepts
-
-- **Component**: Think of a component like a singular application. It's a self-contained group of configuration or resources. Consists of a class with a function called `build()` that returns either an object or a list of objects to be merged into the global tree.
-- **Capability**: A service provided by one or more components, that can be declared on a component and made mandatory on other components.
-- **Fact**: Represents a unique source of data that can be requested by any individual component. Think of Facts as the input configuration for your Components.
-- **Target**: Holds state for a singular build. Components and facts are registered against a target, and a `resolve` function is called to return the final merged configuration tree.
+Architect is currently in the prototype (pre-Alpha) stage, and is still in an early phase of development. It's not yet production-ready, and the API surface is not stable, but contributions are appreciated! Currently, there is a plugin for Kubernetes that represents the first Architect plugin, present under the `packages` folder as `architect-k8s`.

packages/architect-core/README.md

@@ -1,7 +1,7 @@
 # Core module
 
 <p align="center">
-  <img src="https://img.shields.io/npm/v/@perdition/architect-core" />
+  <img src="https://img.shields.io/jsr/v/@perdition/architect-core" />
 </p>
 
 This is the core module for Architect. It contains generic supporting code for modules built on top of it.

packages/architect-k8s/README.md

@@ -1,61 +1,23 @@
 # Kubernetes module for Architect
 
 <p align="center">
-  <img src="https://img.shields.io/npm/v/@perdition/architect-k8s" />
+  <img src="https://img.shields.io/jsr/v/@perdition/architect-k8s" />
 </p>
 
 This is an extension to the [Architect framework](https://github.com/realityanomaly/architect) which allows you to define, validate, and deploy Kubernetes resources in TypeScript. It can scale to hundreds of thousand of resources and allows you to manage entire fleets of clusters in a DRY fashion.
 
-`architect-k8s` is currently in Alpha and the **API surface may change without warning** so usage in production is strongly advised against (unless you're crazy, like me).
-
 ## Example
 
-```typescript
-import { Architect } from '@perdition/architect';
-import { k8sCniCncfIo } from '@perdition/k8s-shared/crds';
-import * as k8s from '@perdition/architect-k8s';
-
-export interface KubevirtComponentOptions extends KubeComponentArgs {};
-
-interface KubevirtComponentResources {
-  networkAttachmentDefinition?: k8sCniCncfIo.v1.NetworkAttachmentDefinition;
-};
-
-@Architect.class('manifold.glassway.net/kubevirt')
-@Kubernetes.namespace('$features$')
-export class KubevirtComponent extends KubeComponent<KubevirtComponentResources, KubevirtComponentOptions> {
-  public override async build(resources: KubevirtComponentResources = {}) {
-    resources.networkAttachmentDefinition = new k8sCniCncfIo.v1.NetworkAttachmentDefinition({
-      metadata: {
-        name: 'host',
-        annotations: {
-          'k8s.v1.cni.cncf.io/resourceName': 'macvtap.network.kubevirt.io/bond0',
-        },
-      },
-      spec: {
-        config: JSON.stringify({
-          cniVersion: '0.3.1',
-          name: 'host',
-          type: 'macvtap',
-          mtu: 1500,
-        }, null, 2),
-      },
-    });
-
-    return super.build(resources);
-  };
-};
-
-```
+Please see `src/components/vendor` for a few initial examples.
 
 ## Current features
 
 - **GitOps support** (FluxCD implemented, ArgoCD planned)
-- **Typed CRDs for in-editor and compile-time validation** - never watch your CI fail again! (Thanks to Tommy Chen ([@tommy351](https://github.com/tommy351)) for their [Kubernetes models](https://github.com/tommy351/kubernetes-models-ts) library)
+- **Typed CRDs for in-editor and compile-time validation** - never watch your CI fail again! (Thanks to Tommy Chen ([@tommy351](https://github.com/tommy351)) for their excellent [Kubernetes models](https://github.com/tommy351/kubernetes-models-ts) library)
 - **Helm, Kustomize, and Jsonnet support**, including caching - a feature not found on other frameworks - which intelligently caches builds based on their input values, significantly reducing compile time
 - **Component system** - define your cluster resources in logical units
   - Declare relationships between resources as dependencies which are respected when applying via FluxCD
-  - Highly flexible lazy parameter system, reminiscent of Nix's structured configuration tree, allows components to be highly customisable, and reusable
+  - A lazy parameter system, reminiscent of Nix's structured configuration tree
 
 ## Planned features
 
@@ -67,14 +29,10 @@ export class KubevirtComponent extends KubeComponent<KubevirtComponentResources,
 
 Architect has a philosophy of delegating CRD generation to you, the developer. Why? We believe that creating our own CRD packages have the potential to become outdated or break as they change, and there are too many Kubernetes applications out there to maintain an up-to-date package for all of them. CRDs will be bundled with applications [we support](https://github.com/realityanomaly/architect/packages/architect-k8s-apps), but others are up to you to manage.
 
-CRDs can be generated in any Architect project you choose. All you need to do is set the `plugins.kubernetes.crds` property of the `architect.yaml` configuration file.
-
-Then you can run `architect plugin k8s sync-crds` to download and generate CRDs.
-
 ## FAQ
 
 - **Why TypeScript?** JavaScript/TypeScript is the home of JSON, the language that YAML extends from. It provided the best working experience as WYSIWYG.
-- **Aren't there other frameworks that do the same thing?** Architect was built specifically to address significant shortfalls in other JavaScript/TypeScript-based frameworks.
+- **Aren't there other frameworks that do the same thing?** Architect was built specifically to address the existing shortfalls in other JavaScript/TypeScript-based frameworks, such as a lengthy development loop and heavy levels of complexity.
 - **What was wrong with Fractal?**
   - Fractal was a decent attempt at a framework, but it unfortunately ran into pitfalls surrounding the interactions between Nix and Kubernetes types/Jsonnet. Nix was never really built to handle or validate Kubernetes' complex models.
   - Neither Nix nor Jsonnet were typed, so validation could only occur (slowly) either at compile time or when the manifests were applied to the cluster.