feelyourprotocol · holgerd77 · Jun 15, 2026 · Jun 15, 2026
diff --git a/docs/.vitepress/config.ts b/docs/.vitepress/config.ts
@@ -1,5 +1,14 @@
+import { readFileSync } from 'node:fs'
+import { dirname, join } from 'node:path'
+import { fileURLToPath } from 'node:url'
+
 import { defineConfig } from 'vitepress'
 
+const __dirname = dirname(fileURLToPath(import.meta.url))
+const pkg = JSON.parse(readFileSync(join(__dirname, '../../package.json'), 'utf-8')) as {
+  version: string
+}
+
 export default defineConfig({
   title: 'Feel Your Protocol',
   description: 'Documentation for the Feel Your Protocol project',
@@ -8,6 +17,7 @@ export default defineConfig({
     nav: [
       { text: 'Guide', link: '/guide/getting-started' },
       { text: 'Contributing', link: '/contributing/how-to-contribute' },
+      { text: 'Changelog', link: '/changelog' },
       { text: 'Website', link: 'https://feelyourprotocol.org' },
     ],
     sidebar: [
@@ -16,6 +26,7 @@ export default defineConfig({
         items: [
           { text: 'Getting Started', link: '/guide/getting-started' },
           { text: 'Architecture', link: '/guide/architecture' },
+          { text: 'Changelog', link: '/changelog' },
         ],
       },
       {
@@ -34,14 +45,13 @@ export default defineConfig({
         ],
       },
     ],
-    socialLinks: [
-      { icon: 'github', link: 'https://github.com/feelyourprotocol/website' },
-    ],
+    socialLinks: [{ icon: 'github', link: 'https://github.com/feelyourprotocol/website' }],
     search: {
       provider: 'local',
     },
     footer: {
-      message: 'This project and its documentation are under active development.',
+      message: `Structural base v${pkg.version} — latest docs always apply. See changelog for history.`,
+      copyright: 'Feel Your Protocol',
     },
   },
 })
diff --git a/docs/changelog.md b/docs/changelog.md
@@ -0,0 +1,52 @@
+# Changelog
+
+Structural-base history for Feel Your Protocol. The version tracks [`package.json`](https://github.com/feelyourprotocol/website/blob/main/package.json) — it reflects changes to the **contribution model, E-Components, and project structure**, not individual explorations.
+
+**Latest docs always apply.** There is no version switching; this page is a trail so you can follow along when the base evolves.
+
+## When the version bumps
+
+| Bump                | When                                                                                 |
+| ------------------- | ------------------------------------------------------------------------------------ |
+| **Patch** (`0.1.x`) | E-Component APIs, contribution guides, architecture, or contributor workflow changed |
+| **Minor** (`0.2.0`) | Breaking change to structural conventions (rare while in beta)                       |
+
+New explorations are listed under **Explorations** for visibility but do not drive version bumps.
+
+---
+
+## [0.1.1] — 2026-06-08
+
+### Added
+
+- **Bytecode Stepper E-Component** (`bytecodeStepperEC`) — documented building block for opcode/bytecode explorations
+- **Docs changelog** (this page)
+- E-Component **extension model**: layout slots, provide/inject context, companion components in the exploration folder
+
+### Changed
+
+- [E-Components](/contributing/e-components) — integration contract, extension points, composition direction
+- [Available E-Components](/contributing/available-e-components) — equal-weight reference for all E-Components
+- [Adding an Exploration](/contributing/adding-an-exploration) — building-block choice, extension guidance, E-Component test notes
+- [Architecture](/guide/architecture) — E-Components described as a growing set, not precompile-only
+- [AI-Assisted Development](/contributing/ai-assisted-development) — check Available E-Components first; slot/inject pitfall
+- [UI Components](/contributing/ui-components) — placement rules aligned with exploration-folder companions
+
+### Explorations _(no version bump)_
+
+- [EIP-8024](https://feelyourprotocol.org/eip-8024-stack-opcodes-dupn-swapn-exchange) — DUPN/SWAPN/EXCHANGE bytecode stepper (reference for E-Component + companion panel pattern)
+
+---
+
+## [0.1.0] — 2026-05-01
+
+Initial documented structural base (beta).
+
+### Added
+
+- Folder-per-exploration content model with dynamic routing via `REGISTRY.ts`
+- Taxonomies: topics, timeline, tags
+- **Precompile Interface E-Component** (`precompileInterfaceEC`)
+- Shared UI components (`src/eComponents/ui/`)
+- VitePress documentation site
+- Contribution guides: adding explorations, styling, code conventions, third-party libraries
diff --git a/docs/contributing/adding-an-exploration.md b/docs/contributing/adding-an-exploration.md
diff --git a/docs/contributing/ai-assisted-development.md b/docs/contributing/ai-assisted-development.md
@@ -19,24 +19,28 @@ npm run dev
 
 Before writing any code, instruct your agent to read the project documentation. The docs are compact and self-contained — an agent can absorb them in one pass:
 
-> *Read all files under `docs/` to understand the project structure, contribution guidelines, and component APIs. Then follow the step-by-step guide in "Adding an Exploration" to create a new exploration for EIP-XXXX.*
+> _Read all files under `docs/` to understand the project structure, contribution guidelines, and component APIs. Then follow the step-by-step guide in "Adding an Exploration" to create a new exploration for EIP-XXXX._
 
 Key pages the agent should internalize:
 
-| Page | Why |
-|------|-----|
-| [Architecture](/guide/architecture) | Content model, taxonomies (topics, timeline, tags), design decisions |
-| [Adding an Exploration](/contributing/adding-an-exploration) | Step-by-step creation guide with field reference |
-| [Available E-Components](/contributing/available-e-components) | Reusable components that can save 80% of the work for precompile explorations |
-| [Styling & Design](/contributing/styling) | CSS variables, design system classes — avoid hardcoded colors |
-| [Code Conventions](/contributing/code-conventions) | Import order, naming, linting rules |
+| Page                                                           | Why                                                                  |
+| -------------------------------------------------------------- | -------------------------------------------------------------------- |
+| [Architecture](/guide/architecture)                            | Content model, taxonomies (topics, timeline, tags), design decisions |
+| [E-Components](/contributing/e-components)                     | Integration model, extension points, composition                     |
+| [Adding an Exploration](/contributing/adding-an-exploration)   | Step-by-step creation guide with field reference                     |
+| [Available E-Components](/contributing/available-e-components) | Ready-to-use building blocks — check here before building custom     |
+| [Styling & Design](/contributing/styling)                      | CSS variables, design system classes — avoid hardcoded colors        |
+| [Code Conventions](/contributing/code-conventions)             | Import order, naming, linting rules                                  |
 
 ### 3. Pick the Right Starting Point
 
-Not all explorations require the same effort. Help the agent choose:
+Not all explorations require the same effort. Help the agent choose in this order:
 
-- **Precompile exploration?** → Use the Precompile Interface E-Component. The agent only needs to define a config, examples, and a result slot. This can be done in under 50 lines of widget code.
-- **Custom widget?** → The agent builds from scratch using shared UI components. More freedom, more code, but the `ExplorationC` wrapper still handles the chrome (title, intro, links).
+1. **Check [Available E-Components](/contributing/available-e-components) first.** If one matches, wire config, examples, and execution — often under 30 lines in `MyC.vue`.
+2. **Need more than the core E-Component provides?** Add exploration-local UI via slots or companion components. See [Extending When the Core E-Component Is Not Enough](/contributing/adding-an-exploration#extending-when-the-core-e-component-is-not-enough).
+3. **Nothing fits?** Build a custom widget with shared UI components and `ExplorationC`. More freedom, more code.
+
+For reference explorations by pattern: [EIP-7951](https://github.com/feelyourprotocol/website/blob/main/src/explorations/eip-7951/MyC.vue) (precompile), [EIP-8024](https://github.com/feelyourprotocol/website/blob/main/src/explorations/eip-8024/MyC.vue) (bytecode stepper with companion panel).
 
 ### 4. Iterate with the Dev Server Running
 
@@ -58,37 +62,36 @@ npx vitest run       # unit tests
 
 Give the agent the EIP number, a link to the spec, and a one-sentence summary of what the exploration should let users do. The more concrete the goal, the better the output:
 
-> *Create an exploration for EIP-7883 (ModExp gas cost increase). The widget should let users enter ModExp inputs (base, exponent, modulus) and compare gas costs before and after the change.*
+> _Create an exploration for EIP-7883 (ModExp gas cost increase). The widget should let users enter ModExp inputs (base, exponent, modulus) and compare gas costs before and after the change._
 
 ### Reference Existing Explorations
 
-Existing explorations are the best examples. Point the agent at a similar one:
+Existing explorations are the best examples. Point the agent at one with a similar pattern:
 
-> *Look at `src/explorations/eip-7951/` as a reference — this new exploration follows the same precompile interface pattern.*
+> _Look at `src/explorations/eip-7951/` for a precompile exploration, or `src/explorations/eip-8024/` for a bytecode stepper with a companion panel._
 
 ### Let the Agent Read Real Source Files
 
-Documentation describes the intended patterns, but the source files show the actual implementation. If the agent is unsure about something, tell it to read the relevant source:
-
-> *Read `src/eComponents/precompileInterfaceEC/types.ts` to understand the PrecompileConfig interface.*
+Documentation describes the intended patterns, but the source files show the actual implementation. If the agent is unsure about something, tell it to read the relevant source — for example the config type in `src/eComponents/<name>EC/types.ts`, or an existing exploration's `MyC.vue` and `config.ts`.
 
 ### Ask for Incremental Steps
 
 Large prompts that ask for everything at once tend to produce lower-quality results. Break the work into stages:
 
 1. "Create `info.ts` with the metadata"
 2. "Create `examples.ts` with three example presets"
-3. "Create the widget in `MyC.vue`"
+3. "Create `config.ts` and wire `MyC.vue` (E-Component or custom widget)"
 4. "Register in `REGISTRY.ts` and verify it builds"
 5. "Add unit tests"
+6. "Add companion components or helpers if the E-Component core is not enough"
 
 ## Common Pitfalls
 
 ### Hardcoded Colors
 
 AI agents love to write `text-blue-600` or `bg-green-100`. The project uses a topic-aware color system via CSS variables — hardcoded colors will look wrong when the exploration's topic changes. Remind the agent:
 
-> *Use `e-text`, `e-result-box`, and the other `e-*` CSS classes instead of hardcoding Tailwind color utilities. Read the Styling & Design docs.*
+> _Use `e-text`, `e-result-box`, and the other `e-_` CSS classes instead of hardcoding Tailwind color utilities. Read the Styling & Design docs.\*
 
 ### Stale Patterns
 
@@ -98,7 +101,7 @@ If your agent's training data is older than the project, it may generate pattern
 
 Agents sometimes fabricate component names or props that don't exist. If the output references a component you haven't seen before, have the agent verify it exists:
 
-> *Search the codebase for `ComponentName` before using it. If it doesn't exist, use the documented alternatives.*
+> _Search the codebase for `ComponentName` before using it. If it doesn't exist, use the documented alternatives._
 
 ### Skipping the Registry
 
@@ -108,6 +111,10 @@ The agent may create all the exploration files but forget to add the import to `
 
 Agents may guess topic, timeline, or tag values. Remind them that topics and timeline entries are a fixed set — the agent should read `TOPICS.ts` and `TIMELINE.ts` to see the valid IDs. Tags come from the `Tag` enum in `TAGS.ts` and new ones can be proposed, but must follow the [tag rules](/guide/architecture#tags).
 
+### Extension UI Outside the Slot Tree
+
+When adding companion panels to an E-Component, agents often mount them as siblings next to the E-Component in `MyC.vue`. Provide/inject only works for **descendants** — extension UI must go inside an E-Component slot (e.g. `#below`, `#result`). See [E-Components — Extension Points](/contributing/e-components#extension-points).
+
 ## Cursor / IDE-Specific Tips
 
 If you are using [Cursor](https://cursor.com/) or a similar AI-native IDE: