docs: add WIP markers, alpha banner, and ecosystem pages

docs-website/docusaurus.config.js

@@ -47,6 +47,12 @@ const config = {
   themeConfig:
     /** @type {import('@docusaurus/preset-classic').ThemeConfig} */
     ({
+      announcementBar: {
+        id: 'alpha_notice',
+        content:
+          '🚧 <b>Early Alpha</b> · aflock has not had a stable release yet and is under active development. Some documented features are still work-in-progress. <a href="https://github.com/aflock-ai/aflock/issues">Open issues</a> · <a href="https://github.com/aflock-ai/aflock#contributing">Contributions welcome</a> · ⭐ <a href="https://github.com/aflock-ai/aflock">Star us on GitHub</a>',
+        isCloseable: false,
+      },
       image: 'img/aflock-og.png',
       navbar: {
         title: 'aflock',
@@ -116,6 +122,14 @@ const config = {
                 label: 'Witness',
                 href: 'https://witness.dev',
               },
+              {
+                label: 'TestifySec',
+                href: 'https://testifysec.com',
+              },
+              {
+                label: 'Discussions',
+                href: 'https://github.com/orgs/aflock-ai/discussions',
+              },
             ],
           },
           {
@@ -129,6 +143,10 @@ const config = {
                 label: 'Specification',
                 to: 'docs/docs/reference/policy-schema',
               },
+              {
+                label: 'Rookery',
+                href: 'https://github.com/aflock-ai/rookery',
+              },
             ],
           },
         ],

docs-website/sidebars.js

@@ -28,6 +28,11 @@ const sidebars = {
         },
       ],
     },
+    {
+      type: 'doc',
+      label: 'Plan-to-Policy',
+      id: 'docs/plan-to-policy',
+    },
     {
       type: 'category',
       label: 'Reference',
@@ -48,6 +53,16 @@ const sidebars = {
         },
       ],
     },
+    {
+      type: 'category',
+      label: 'Ecosystem',
+      items: [
+        {
+          type: 'autogenerated',
+          dirName: 'docs/ecosystem',
+        },
+      ],
+    },
   ],
 };
 

docs-website/src/components/HomepageFeatures/index.js

@@ -25,8 +25,8 @@ const FeatureList = [
     title: 'Verify',
     description: (
       <>
-        Verify constraint compliance after the fact with a 6-phase verification algorithm.
-        Cross-step Rego evaluation, merkle tree ordering proofs, and sublayout recursion.
+        Verify constraint compliance with a 6-phase verification algorithm.
+        Signature verification is implemented; identity, Rego, AI evaluation, and sublayout recursion are <a href="https://github.com/aflock-ai/aflock/issues/16">in active development</a>.
       </>
     ),
   },

docs-website/src/css/custom.css

@@ -70,3 +70,37 @@
   background: url("data:image/svg+xml;charset=utf-8,%3Csvg viewBox='0 0 24 24' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath fill='white' d='M12 .297c-6.63 0-12 5.373-12 12 0 5.303 3.438 9.8 8.205 11.385.6.113.82-.258.82-.577 0-.285-.01-1.04-.015-2.04-3.338.724-4.042-1.61-4.042-1.61C4.422 18.07 3.633 17.7 3.633 17.7c-1.087-.744.084-.729.084-.729 1.205.084 1.838 1.236 1.838 1.236 1.07 1.835 2.809 1.305 3.495.998.108-.776.417-1.305.76-1.605-2.665-.3-5.466-1.332-5.466-5.93 0-1.31.465-2.38 1.235-3.22-.135-.303-.54-1.523.105-3.176 0 0 1.005-.322 3.3 1.23.96-.267 1.98-.399 3-.405 1.02.006 2.04.138 3 .405 2.28-1.552 3.285-1.23 3.285-1.23.645 1.653.24 2.873.12 3.176.765.84 1.23 1.91 1.23 3.22 0 4.61-2.805 5.625-5.475 5.92.42.36.81 1.096.81 2.22 0 1.606-.015 2.896-.015 3.286 0 .315.21.69.825.57C20.565 22.092 24 17.592 24 12.297c0-6.627-5.373-12-12-12'/%3E%3C/svg%3E")
     no-repeat;
 }
+
+/* Alpha announcement banner */
+div[class*='announcementBar'] {
+  background: #f5f3ff !important;
+  color: #3b0764 !important;
+  font-size: 0.9rem;
+  font-weight: 500;
+  padding: 8px 0;
+  border-bottom: 1px solid #e9d5ff;
+}
+
+div[class*='announcementBar'] a {
+  color: #6366f1 !important;
+  text-decoration: underline;
+  font-weight: 600;
+}
+
+div[class*='announcementBar'] a:hover {
+  color: #4338ca !important;
+}
+
+[data-theme='dark'] div[class*='announcementBar'] {
+  background: #1e1b4b !important;
+  color: #e0e7ff !important;
+  border-bottom-color: #312e81;
+}
+
+[data-theme='dark'] div[class*='announcementBar'] a {
+  color: #a5b4fc !important;
+}
+
+[data-theme='dark'] div[class*='announcementBar'] a:hover {
+  color: #c7d2fe !important;
+}

docs/concepts/attestations.md

@@ -4,10 +4,16 @@ sidebar_position: 2
 
 # Attestations
 
+:::caution Active Development
+Attestation signing using DSSE envelopes is implemented. However, **JWT-based agent authorization** ([#19](https://github.com/aflock-ai/aflock/issues/19)) and the **JWT + Signing Key Separation** model described below are not yet implemented — the current implementation has the agent directly holding the signing key. **Attestation generation in hooks mode** is also WIP ([#17](https://github.com/aflock-ai/aflock/issues/17)). Session Merkle trees are designed but not yet implemented. **We're looking for contributors in these areas.**
+:::
+
 Every agent action produces a **cryptographically signed attestation** — an unforgeable record of what happened. aflock uses the [in-toto](https://in-toto.io/) attestation format wrapped in DSSE envelopes.
 
 ## JWT and Signing Key Separation
 
+> **Status: Not yet implemented** — Currently the agent directly holds the signing key. See [#19](https://github.com/aflock-ai/aflock/issues/19).
+
 A critical security property is the separation between **authorization** (what the agent is allowed to do) and **attestation** (proof of what the agent did):
 
 | Component | Held By | Purpose |
@@ -86,6 +92,8 @@ Attestations are wrapped in a Dead Simple Signing Envelope:
 
 ## Session Merkle Trees
 
+> **Status: Not yet implemented** — Merkle tree construction is designed but no code exists yet. See [#16](https://github.com/aflock-ai/aflock/issues/16).
+
 By constructing a merkle tree over the session JSONL, aflock can cryptographically prove:
 
 - **Order**: Turn *n* came after turns 0 through *n-1*

docs/concepts/data-flow.md

@@ -4,6 +4,10 @@ sidebar_position: 5
 
 # Data Flow Tracking
 
+:::info Implementation Status
+Data flow classification and flow rule enforcement are implemented in the hooks handler for direct file reads/writes. Note that Bash command analysis currently has a limited set of recognized file-reading commands — some commands (e.g., `grep`, `sed`, `awk`) may not trigger data flow checks. See [#25](https://github.com/aflock-ai/aflock/issues/25).
+:::
+
 aflock can classify data by sensitivity level and enforce rules preventing data from flowing between classifications.
 
 ## Why Data Flow Tracking?

docs/concepts/identity.md

@@ -4,12 +4,18 @@ sidebar_position: 1
 
 # Agent Identity
 
+:::caution Active Development
+The identity derivation model described here is the target design. The current implementation uses **process-tree heuristics** (`os.Getppid()` and `ps`) rather than kernel-level socket credentials (`SO_PEERCRED`/`LOCAL_PEERCRED`). The MCP server currently uses stdio transport, not Unix domain sockets. See [#24](https://github.com/aflock-ai/aflock/issues/24). The SPIFFE ID format in the implementation also differs from what's documented here. **We're looking for contributors in this area.**
+:::
+
 A core insight of aflock is that agent identity should be **derived from introspectable properties** rather than assigned. The agent cannot lie about its identity because the server independently verifies all components.
 
 ## Identity Derivation
 
 When an agent connects to the aflock server via MCP over a Unix domain socket, the server obtains the connecting process's PID through `SO_PEERCRED` (Linux) or `LOCAL_PEERCRED` (macOS).
 
+> **Current implementation note:** The server currently uses process-tree walking (`os.Getppid()`) over stdio transport rather than socket credentials. See [#24](https://github.com/aflock-ai/aflock/issues/24).
+
 From the PID, the server introspects:
 
 | Component | Source | Example |

docs/concepts/policies.md

@@ -4,6 +4,10 @@ sidebar_position: 0
 
 # Policies
 
+:::info What's Working
+Policy loading, signing (`aflock sign`), tool allowlists, file access rules, domain controls, and resource limit enforcement (spend, tokens, turns, time) are all fully implemented. Features marked below as WIP have types/schemas defined but the runtime enforcement code is not yet complete.
+:::
+
 An `.aflock` file is a **cryptographically signed policy** that constrains AI agent behavior. Like `package-lock.json` locks dependencies, `.aflock` locks what an agent can do.
 
 ## Why Policies?
@@ -122,6 +126,8 @@ Follow the principle of least privilege — all access denied unless explicitly
 
 ## Grants
 
+> **Status: Schema defined, runtime enforcement not yet implemented** — The `grants` policy is parsed but never evaluated at runtime. See [#22](https://github.com/aflock-ai/aflock/issues/22). **We're looking for contributors.**
+
 Explicit authorization for resource access:
 
 ```json
@@ -173,3 +179,5 @@ Define who can sign the policy:
 ```
 
 Supported types: `publickey`, `keyless` (Sigstore/OIDC), `x509`, `spiffe`.
+
+> **Note:** `publickey` and `x509` functionaries are implemented. `keyless` (Sigstore) signing is not yet implemented ([#20](https://github.com/aflock-ai/aflock/issues/20)). `spiffe` functionaries work for X509-SVIDs; JWT-SVID support is not yet available.

docs/concepts/sublayouts.md

@@ -4,6 +4,10 @@ sidebar_position: 4
 
 # Sublayouts
 
+:::caution Active Development
+The sublayout security model is partially implemented. **Numeric limit attenuation** (invariant 1) and **metric accumulation** (invariant 2) work. **Attestation namespacing** (invariant 3), **recursive verification** (invariant 4), the `inherit` field, and constraint enforcement during sub-agent execution are not yet implemented. See [#26](https://github.com/aflock-ai/aflock/issues/26). **We're looking for contributors in this area.**
+:::
+
 Inspired by [in-toto sublayouts](https://github.com/in-toto/specification), aflock supports **hierarchical sub-agent delegation** with mandatory constraint attenuation.
 
 ## The Problem

docs/concepts/verification.md

@@ -4,6 +4,10 @@ sidebar_position: 3
 
 # Verification
 
+:::caution Active Development
+The 6-phase verification pipeline is partially implemented. **Phase 1 (Signature Verification)** works in the `VerifySteps` path. **Phases 2–6** (Identity, Materials Binding, Rego Evaluation, AI Evaluation, Sublayout Recursion) are designed but not yet implemented in code. See [GitHub issue #16](https://github.com/aflock-ai/aflock/issues/16) for progress. **We're looking for contributors in this area.**
+:::
+
 aflock's verification algorithm checks that an agent session complied with its policy. Verification proceeds in **six phases** — all must pass for the session to be considered compliant.
 
 ## The 6-Phase Algorithm
@@ -57,22 +61,32 @@ Every attestation must be signed by a key authorized in the policy's `functionar
 
 ### Phase 2: Identity Verification
 
+> **Status: Not yet implemented** — [#16](https://github.com/aflock-ai/aflock/issues/16)
+
 The agent identity recorded in each attestation must match the policy's `identity` constraints (allowed models, environments, required tools).
 
 ### Phase 3: Materials Binding
 
+> **Status: Not yet implemented** — no Merkle tree code exists yet. [#16](https://github.com/aflock-ai/aflock/issues/16)
+
 If the policy specifies `materialsFrom.session.merkleTree`, the verifier recomputes the merkle root over the session JSONL and compares it to the root recorded in the final attestation. This proves execution ordering and completeness.
 
 ### Phase 4: Constraint Evaluation
 
+> **Status: Not yet implemented** — no OPA/Rego integration exists yet. [#16](https://github.com/aflock-ai/aflock/issues/16)
+
 Rego evaluators receive the full set of attestations and can compute cumulative metrics. This is where spend limits, token limits, and custom constraints are checked across all turns.
 
 ### Phase 5: AI Evaluation
 
+> **Status: Not yet implemented** — [#16](https://github.com/aflock-ai/aflock/issues/16)
+
 AI evaluators assess qualitative properties (code quality, test coverage, task completion) that are difficult to express in formal logic. These are probabilistic — critical constraints should use Rego.
 
 ### Phase 6: Sublayout Recursion
 
+> **Status: Not yet implemented** — [#16](https://github.com/aflock-ai/aflock/issues/16), [#26](https://github.com/aflock-ai/aflock/issues/26)
+
 For each sublayout (sub-agent delegation), verification recurses with the sub-agent's policy and its namespaced attestations.
 
 ## Running Verification
@@ -94,6 +108,8 @@ Exit code `0` = compliant. Non-zero = violations found with detailed error messa
 
 ### Rego Evaluators
 
+> **Status: Schema defined, runtime not yet implemented** — [#16](https://github.com/aflock-ai/aflock/issues/16)
+
 Deterministic, cross-step constraint verification:
 
 ```json
@@ -109,6 +125,8 @@ Deterministic, cross-step constraint verification:
 
 ### AI Evaluators
 
+> **Status: Schema defined, runtime not yet implemented** — [#16](https://github.com/aflock-ai/aflock/issues/16)
+
 Qualitative assessment:
 
 ```json
@@ -125,6 +143,8 @@ Qualitative assessment:
 
 ### gRPC Evaluators
 
+> **Status: Not yet implemented** — [#21](https://github.com/aflock-ai/aflock/issues/21)
+
 Custom evaluation logic:
 
 ```json

docs/ecosystem/rookery.md

@@ -0,0 +1,89 @@
+---
+sidebar_position: 0
+---
+
+# Rookery
+
+:::caution Active Development
+Rookery is under active development and has not had a stable release yet. The documentation site is being built out — more detailed docs will be added soon. If you have questions or want to contribute, join the [discussions](https://github.com/orgs/aflock-ai/discussions).
+:::
+
+[Rookery](https://github.com/aflock-ai/rookery) is a modular attestation framework that aflock builds on for cryptographic evidence generation and verification. It is a security-hardened fork of the [witness](https://witness.dev) project, maintained by [TestifySec](https://testifysec.com).
+
+## What Rookery Does
+
+Rookery generates **attestations** — cryptographic records that capture what happened during software supply chain activities:
+
+- **Build provenance**: What was built, by whom, when, and how
+- **Source metadata**: Git commit, branch, author information
+- **Environment capture**: CI/CD context (GitHub Actions, GitLab CI, AWS CodeBuild)
+- **Artifact tracking**: Input materials and output products with digests
+- **Security scanning**: Secret detection, SBOM generation
+
+These attestations are signed using DSSE envelopes and can be verified against policies to ensure supply chain integrity.
+
+## How aflock Uses Rookery
+
+aflock uses Rookery's attestation primitives to:
+
+1. **Sign attestations** in the in-toto format with DSSE envelopes
+2. **Verify signatures** against trusted functionaries (public keys, X.509 certificates, SPIFFE SVIDs)
+3. **Manage signing keys** including SPIRE-based workload identity
+
+The `attestation/`, `dsse/`, and `signer/` packages from Rookery provide aflock's cryptographic foundation.
+
+## Plugin Architecture
+
+Rookery uses a modular plugin system:
+
+### Attestors (30+)
+
+Plugins that generate attestation evidence:
+
+| Category | Attestors |
+|----------|-----------|
+| **CI/CD** | GitHub Actions, GitLab CI, AWS CodeBuild, Jenkins |
+| **Source** | Git metadata, commit info |
+| **Runtime** | Command execution, environment capture |
+| **Artifacts** | Material (inputs), Product (outputs) |
+| **Security** | Secret scanning (Gitleaks), SBOM |
+| **Container** | Docker image info, Kubernetes manifests |
+| **Compliance** | SLSA provenance |
+
+### Signers (8)
+
+Plugins for cryptographic signing:
+
+| Signer | Description |
+|--------|-------------|
+| **File** | Local key-based signing |
+| **Fulcio** | Sigstore keyless signing |
+| **SPIFFE** | Workload identity signing |
+| **Vault** | HashiCorp Vault signing |
+| **AWS KMS** | AWS Key Management Service |
+| **Azure KMS** | Azure Key Management |
+| **GCP KMS** | Google Cloud KMS |
+| **Vault Transit** | Vault Transit engine |
+
+## Security Hardening
+
+Rookery includes fixes for security issues found in the upstream witness project, including certificate chain validation, symlink path traversal prevention, timestamp authority verification, and KMS offline verification hardening.
+
+## Getting Started with Rookery
+
+```bash
+git clone https://github.com/aflock-ai/rookery.git
+cd rookery
+go work sync
+make build
+```
+
+Rookery uses Go workspaces with each plugin as an independent module, allowing you to compose only the attestors and signers you need.
+
+## Learn More
+
+- [Rookery on GitHub](https://github.com/aflock-ai/rookery)
+- [TestifySec](https://testifysec.com) — the company behind witness and rookery
+- [witness.dev](https://witness.dev) — the upstream project
+- [in-toto specification](https://in-toto.io/) — the attestation format standard
+- [SLSA](https://slsa.dev/) — Supply-chain Levels for Software Artifacts