From 6718272c92371390c3ee33f3d477d39e3a3d96ac Mon Sep 17 00:00:00 2001 From: Dominique Devereaux <90852374+ibloud@users.noreply.github.com> Date: Sun, 18 Oct 2026 12:50:02 -0500 Subject: [PATCH 1/3] Connect training purpose to the confirmed multimedia studio pilot --- README.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/README.md b/README.md index a97293f..896604e 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,14 @@ Financial support is optional and sustains infrastructure, maintenance, accessib An accessibility-first guide for turning work and creative goals into a technology, training, funding-research, and documentation plan. +## Why this training exists — confirmed 18 October 2026 + +Loptr Lab’s ecosystem is the testing ground for an open-source multimedia training studio. PIXIE is its contributor companion, helping people join, learn, coordinate work and return with context intact. Contributor testing is the immediate goal; a finished commercial app is not required before testing begins. Pilot evidence should inform a concrete project pitch and a sustainable revenue model consistent with the existing mission, open participation and project licenses. + +The [canonical studio direction](https://github.com/ibloud/ibloud.github.io/blob/main/docs/ECOSYSTEM_ARCHITECTURE.md#studio-viability-pilot--owner-confirmed-direction-18-october-2026) records the pilot questions and continuity rules. Test whether contributors can start useful work, learn through real artifacts, resume with less repeated explanation and help identify viable studio offers. Record observed results and failures; do not treat proposals as validated demand or completed features. Maintainers and AI assistants should read that direction before changing scope. + +[Use PIXIE to contribute and resume](./docs/pixie-contributors.html). + ## Start here The [guide homepage](./docs/index.html) is the canonical orientation page. It asks what you need to do next and routes you through one user journey. From 2a3fb18f49f31a432df2cddd2621cf192153c7b4 Mon Sep 17 00:00:00 2001 From: Dominique Devereaux <90852374+ibloud@users.noreply.github.com> Date: Sun, 18 Oct 2026 12:50:06 -0500 Subject: [PATCH 2/3] Explain PIXIE testing as part of studio viability, not app-launch readiness --- docs/pixie-contributors.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/pixie-contributors.md b/docs/pixie-contributors.md index e3f8cc6..3978fe9 100644 --- a/docs/pixie-contributors.md +++ b/docs/pixie-contributors.md @@ -4,6 +4,12 @@ Updated 18 October 2026. One workflow across the existing ecosystem; GitHub hold [Open PIXIE](https://pixie-project-companion.ibloud-ivxx.chatgpt.site) · [Ecosystem](https://ecosystem.loptrlab.com) · [Training](https://loptr-lab.github.io/training/) +## Why we are testing PIXIE + +Loptr Lab’s ecosystem is the testing ground for an open-source multimedia training studio. PIXIE is its contributor companion, helping people join, learn, coordinate work and return with context intact. Contributor testing is the immediate goal; a finished commercial app is not required before testing begins. Pilot evidence should inform a concrete project pitch and a sustainable revenue model consistent with the existing mission, open participation and project licenses. + +Read the [owner-confirmed studio direction](https://github.com/ibloud/ibloud.github.io/blob/main/docs/ECOSYSTEM_ARCHITECTURE.md#studio-viability-pilot--owner-confirmed-direction-18-october-2026). This workflow is a pilot of contributor coordination, not evidence that public plugin distribution, studio viability or commercial readiness is complete. Record concrete contributions, learning outcomes, handoffs, repeated explanations and defects. Build the pitch from those findings, with business-model assumptions labeled as hypotheses. + ## Contributor steps 1. **Start.** Open the existing PIXIE companion, choose a project and read its repository’s contribution instructions. Training is the default starting point. From 85ad919b022394658071cc98244323a3069868d7 Mon Sep 17 00:00:00 2001 From: Dominique Devereaux <90852374+ibloud@users.noreply.github.com> Date: Sun, 18 Oct 2026 12:50:10 -0500 Subject: [PATCH 3/3] Show studio pilot purpose on the styled PIXIE contributor page --- docs/pixie-contributors.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pixie-contributors.html b/docs/pixie-contributors.html index 3deba70..e11ccce 100644 --- a/docs/pixie-contributors.html +++ b/docs/pixie-contributors.html @@ -1 +1 @@ -PIXIE: join, contribute and resume — Loptr Lab
LOPTR LAB / CONTRIBUTOR COORDINATION

PIXIE stays with the work.

Join a project, keep a shared checkpoint in GitHub, and resume without reconstructing the briefing.

Your contributor journey

  1. Start. Open the existing PIXIE companion, choose a project and read its repository’s contribution instructions. Training is the default starting point.
  2. Choose a task. Use “How can I help?” for a bounded suggestion. Then choose “Join & coordinate” and describe the proposed task, progress, blocker and next action.
  3. Review and submit. Review the checkpoint draft and its public visibility. “Review & submit on GitHub” opens a prefilled issue in that project. You submit it using GitHub; PIXIE does not post automatically or enroll you.
  4. Agree scope. Record maintainer agreement, time, credit and exit arrangements in the issue. A suggestion or issue does not itself assign a task or grant access.
  5. Keep coordinated. Add progress comments with evidence, blockers and the next action. Keep the issue URL. GitHub holds the shared history.
  6. Resume. In a later session, choose the same project, select “Resume my checkpoint” and paste the issue URL. PIXIE reads the current public issue and latest comment page. Open the full GitHub discussion for older comments.

Remember your place on this device

Optionally choose “Remember this checkpoint on this device” in PIXIE. It stores only the public issue URL and project in this browser. “Forget saved link” removes that pointer; the GitHub issue remains. This does not synchronize across devices or sites.

What persists

Submitted GitHub issues and comments persist across sessions. Drafts are not saved until submitted. Keep the issue URL: PIXIE does not automatically remember it or read private chat history.

No email intake, automatic posting, formal membership or repository access is added. Keep private information out of public issues. Current open contribution is voluntary and unpaid.

Build and public-release steps

  1. Edit the existing companion source; preserve its Site and App identities. Keep runtime code and browser instructions aligned.
  2. Run the companion tests, TypeScript checks and production build. Verify a checkpoint draft does not post, another session can read a submitted issue, and wrong-project URLs are rejected.
  3. Commit/push exact source, save and deploy that source through the existing Site, then verify public HTTP/API behavior. Record source commit, saved version and deployment result. GitHub source review and Sites deployment are distinct operations.
  4. Keep ecosystem and training links pointing to this same companion. A domain change is not required. Do not create another map or replacement service.
  5. To distribute the ChatGPT plugin publicly, verify the supported submission path for the existing Sites App. Prepare the verified publisher identity, website/support/privacy/terms URLs, actual icons, five positive and three negative review cases, a real demo recording, country targeting, commerce declaration and release notes.
  6. Prepare the public submission separately from the private original. Author uploads omit private App bindings and use verified MCP configuration; preserve canonical App ownership and Portal-generated bindings. Do not create a duplicate private plugin.
  7. Configure and test the exact saved submission. The verified publisher completes legal attestations and required scans. Submit for review, publish the approved version, and verify installation and tools with a separate permitted account. A private update, public website or uploaded draft is not a public plugin release.

Current boundaries

The companion website is public. ChatGPT plugin distribution remains private until its public release process completes. GitHub/AT Protocol membership signup and private participant storage are not implemented by this checkpoint workflow. Reported issue content is not accepted canon or verified completion.

Keep the existing hosting identities

The ecosystem is the hub, training is the contributor manual, and the existing companion runs the workflow. No new domain purchase or hosting migration is required. Custom domains do not publish plugins. Do not repoint the ecosystem hostname or migrate MCP/OAuth addresses without testing.

Reconcile deployed source with the GitHub contribution source before editing; do not assume automatic synchronization. Reuse the canonical architecture and PIXIE interface track.

Read the source Markdown
\ No newline at end of file +PIXIE: join, contribute and resume — Loptr Lab
LOPTR LAB / CONTRIBUTOR COORDINATION

PIXIE stays with the work.

Join a project, keep a shared checkpoint in GitHub, and resume without reconstructing the briefing.

Why we are testing PIXIE

Loptr Lab’s ecosystem is the testing ground for an open-source multimedia training studio. PIXIE is its contributor companion, helping people join, learn, coordinate work and return with context intact. Contributor testing is the immediate goal; a finished commercial app is not required before testing begins. Pilot evidence should inform a concrete project pitch and a sustainable revenue model consistent with the existing mission, open participation and project licenses.

Read the owner-confirmed studio direction. Record concrete contributions, learning outcomes, handoffs, repeated explanations and defects. Build the pitch from these findings; studio viability, public plugin distribution and commercial readiness remain separate questions.

Your contributor journey

  1. Start. Open the existing PIXIE companion, choose a project and read its repository’s contribution instructions. Training is the default starting point.
  2. Choose a task. Use “How can I help?” for a bounded suggestion. Then choose “Join & coordinate” and describe the proposed task, progress, blocker and next action.
  3. Review and submit. Review the checkpoint draft and its public visibility. “Review & submit on GitHub” opens a prefilled issue in that project. You submit it using GitHub; PIXIE does not post automatically or enroll you.
  4. Agree scope. Record maintainer agreement, time, credit and exit arrangements in the issue. A suggestion or issue does not itself assign a task or grant access.
  5. Keep coordinated. Add progress comments with evidence, blockers and the next action. Keep the issue URL. GitHub holds the shared history.
  6. Resume. In a later session, choose the same project, select “Resume my checkpoint” and paste the issue URL. PIXIE reads the current public issue and latest comment page. Open the full GitHub discussion for older comments.

Remember your place on this device

Optionally choose “Remember this checkpoint on this device” in PIXIE. It stores only the public issue URL and project in this browser. “Forget saved link” removes that pointer; the GitHub issue remains. This does not synchronize across devices or sites.

What persists

Submitted GitHub issues and comments persist across sessions. Drafts are not saved until submitted. Keep the issue URL: PIXIE does not automatically remember it or read private chat history.

No email intake, automatic posting, formal membership or repository access is added. Keep private information out of public issues. Current open contribution is voluntary and unpaid.

Build and public-release steps

  1. Edit the existing companion source; preserve its Site and App identities. Keep runtime code and browser instructions aligned.
  2. Run the companion tests, TypeScript checks and production build. Verify a checkpoint draft does not post, another session can read a submitted issue, and wrong-project URLs are rejected.
  3. Commit/push exact source, save and deploy that source through the existing Site, then verify public HTTP/API behavior. Record source commit, saved version and deployment result. GitHub source review and Sites deployment are distinct operations.
  4. Keep ecosystem and training links pointing to this same companion. A domain change is not required. Do not create another map or replacement service.
  5. To distribute the ChatGPT plugin publicly, verify the supported submission path for the existing Sites App. Prepare the verified publisher identity, website/support/privacy/terms URLs, actual icons, five positive and three negative review cases, a real demo recording, country targeting, commerce declaration and release notes.
  6. Prepare the public submission separately from the private original. Author uploads omit private App bindings and use verified MCP configuration; preserve canonical App ownership and Portal-generated bindings. Do not create a duplicate private plugin.
  7. Configure and test the exact saved submission. The verified publisher completes legal attestations and required scans. Submit for review, publish the approved version, and verify installation and tools with a separate permitted account. A private update, public website or uploaded draft is not a public plugin release.

Current boundaries

The companion website is public. ChatGPT plugin distribution remains private until its public release process completes. GitHub/AT Protocol membership signup and private participant storage are not implemented by this checkpoint workflow. Reported issue content is not accepted canon or verified completion.

Keep the existing hosting identities

The ecosystem is the hub, training is the contributor manual, and the existing companion runs the workflow. No new domain purchase or hosting migration is required. Custom domains do not publish plugins. Do not repoint the ecosystem hostname or migrate MCP/OAuth addresses without testing.

Reconcile deployed source with the GitHub contribution source before editing; do not assume automatic synchronization. Reuse the canonical architecture and PIXIE interface track.

Read the source Markdown
\ No newline at end of file