From bd5591c3243ef83175736ddedb20b1bba8db8f28 Mon Sep 17 00:00:00 2001 From: Dominique Devereaux Date: Tue, 27 Oct 2026 09:38:51 +0000 Subject: [PATCH] docs: focus contributor guidance on existing Companion and Holdings assignment --- CONTRIBUTING.md | 8 +++++ docs/pixie-contributors.html | 2 +- docs/pixie-contributors.md | 61 ++++++++++++++++++++++++++++-------- 3 files changed, 57 insertions(+), 14 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c7a073d..80fd672 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -44,6 +44,14 @@ Skip the introductory steps if you know the workflow. Please contribute **verifi ## PIXIE — optional contributor guidance and maintenance +**Current focus: finish the existing Companion and support assigned work; scope +expansion is frozen.** Application source is +[`Loptr-Lab/pixie-ecosystem-guide`, `apps/companion`, PR #5](https://github.com/Loptr-Lab/pixie-ecosystem-guide/pull/5). +Use the [current contributor focus](docs/pixie-contributors.md#current-focus-and-assigned-work) +and [canonical release status](https://github.com/Loptr-Lab/pixie-ecosystem-guide/blob/main/COMPANION-HOSTING-STATUS.md) +for responsibility and blocker details. Check existing assignments before starting; +reuse the assigned issue and repository rather than opening a competing workflow. + [Join, contribute and resume with PIXIE](https://loptr-lab.github.io/training/pixie-contributors.html). The existing companion prepares reviewed GitHub checkpoint drafts and reads submitted issues to resume shared work. GitHub remains the coordination record; PIXIE does not post automatically, enroll members, or grant access. [Visit PIXIE at Break This Build](https://break.loptrlab.com/) for an optional guided introduction to projects and contribution ideas. PIXIE is **not required** for participation: contributors may use this repository's issues and pull requests directly, without providing an email address or creating another account. diff --git a/docs/pixie-contributors.html b/docs/pixie-contributors.html index e11ccce..f3f4ecc 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.

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 +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.

Current focus and assigned work

One Companion. Specialized projects. No duplicate workflows. Stabilize the existing Companion before expanding functionality. Its authoritative source is pixie-ecosystem-guide, apps/companion, PR #5. Use the canonical status for responsibilities, verified checks and release blockers. Training owns onboarding, not a second application or deployment checklist. Review Creator OS overlap before integration; keep the iCloud adapter separate. Do not archive the older Device Stewardship repository without dependency/history checks and approval.

Holdings issue #18 is assigned to sweetytweety2406-wq. The maintainer's agreement is a historical Drive archive-mapper schema and workflow with synthetic examples only. Do not duplicate this work, access private Drive data or expand its scope. The contributor's small draft PR belongs in Holdings, linked to issue #18. No corresponding draft was open at this update. Maintainers review against the agreement with concrete, file-specific feedback; scope changes require maintainer agreement.

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. Check existing assignments first; keep an agreed task in its existing issue. For unassigned work, 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. For an assigned issue, add progress there rather than opening a duplicate. For a new task, 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

For the public checkpoint workflow, submitted GitHub issues and comments persist across sessions; its drafts require submission. PR #5 also implements a separate private project workspace with documented local/server persistence, not cross-device synchronization or a replacement for the assigned issue. 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.

Source review and release boundary

Follow the existing contribution process. Companion changes belong in its authoritative source, not training or Holdings. Inspect the implementation, issue and instructions; identify the verified problem, reuse existing work, make the smallest necessary change, run relevant checks and report actual results and unverified claims. Passing checks do not authorize deployment or merging.

PR #5 remains unmerged. Railway is blocked by authenticated service access and verification of the existing service, volume and runtime URL. The canonical release status links prepared configuration, acceptance checks and rollback. Local restart tests and a static preview do not prove Railway persistence, hosted MCP acceptance or physical iPad support.

Preserve the guide, ChatGPT Site, installed plugin, domains and existing source. No new deployments, merges, Tangled synchronization, repository deletion/archival, domain changes or plugin replacement are authorized here. Public plugin release follow-through in training issue #42 is historical context, not the immediate assignment or an instruction to publish.

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.

Use the Companion README on its existing review branch for implementation instructions. Reconcile deployed source with that GitHub 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 diff --git a/docs/pixie-contributors.md b/docs/pixie-contributors.md index 3978fe9..e6d1987 100644 --- a/docs/pixie-contributors.md +++ b/docs/pixie-contributors.md @@ -1,6 +1,6 @@ # PIXIE: join, contribute and resume -Updated 18 October 2026. One workflow across the existing ecosystem; GitHub holds shared contribution records. +Updated 27 October 2026. One workflow across the existing ecosystem; GitHub holds shared contribution records. [Open PIXIE](https://pixie-project-companion.ibloud-ivxx.chatgpt.site) · [Ecosystem](https://ecosystem.loptrlab.com) · [Training](https://loptr-lab.github.io/training/) @@ -10,11 +10,33 @@ Loptr Lab’s ecosystem is the testing ground for an open-source multimedia trai 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. +## Current focus and assigned work + +**One Companion. Specialized projects. No duplicate workflows.** Stabilize the +existing Companion before expanding functionality. The authoritative source is +[`Loptr-Lab/pixie-ecosystem-guide`, `apps/companion`, PR #5](https://github.com/Loptr-Lab/pixie-ecosystem-guide/pull/5). +Use its [current status](https://github.com/Loptr-Lab/pixie-ecosystem-guide/blob/main/COMPANION-HOSTING-STATUS.md) +for project responsibilities, verified checks and release blockers; training owns +onboarding, not a second application or deployment checklist. Creator OS overlap +must be reviewed before integration. The iCloud adapter remains separate. The older +Device Stewardship repository must not be archived without dependency/history +verification and approval. + +[Holdings issue #18](https://github.com/ibloud/pixie-holdings/issues/18) is assigned +to **sweetytweety2406-wq**. Follow the +[maintainer's agreement](https://github.com/ibloud/pixie-holdings/issues/18#issuecomment-6436714216): +a historical Drive archive-mapper schema and workflow with synthetic examples only. +Do not duplicate the schema work, access private Drive data, or expand the task. +The contributor's small draft PR belongs in Holdings and should link issue #18; +maintainers review it against that agreement with concrete, file-specific feedback. +No corresponding draft was open at this update. Scope changes require maintainer +agreement, not another task or inferred permission. + ## 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. -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. +2. **Choose a task.** Check existing assignments first; keep an agreed task in its existing issue. For unassigned work, 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.** For an assigned issue, add progress there rather than opening a duplicate. For a new task, 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. @@ -25,17 +47,30 @@ Optionally choose “Remember this checkpoint on this device” in PIXIE. It sto ## What persists -Submitted GitHub issues and comments persist across sessions. Drafts are not saved until submitted. PIXIE does not read private chat history, automatically remember your issue URL, create formal membership, grant repository access or collect email addresses. Keep private material out of public issues. Current open contribution is voluntary and unpaid. +For the public checkpoint workflow, submitted GitHub issues and comments persist across sessions; its drafts require submission. PR #5 also implements a separate private project workspace with documented local/server persistence; that is not cross-device synchronization or a replacement for the assigned GitHub issue. PIXIE does not read private chat history, automatically remember your issue URL, create formal membership, grant repository access or collect email addresses. Keep private material out of public issues. Current open contribution is voluntary and unpaid. + +## Source review and release boundary + +Follow [CONTRIBUTING.md](../CONTRIBUTING.md) for the existing PR process. Companion +changes belong in its authoritative source, not training or Holdings. Inspect the +existing implementation, issue and instructions; state the verified problem, +reuse the implementation, make the smallest necessary change, run relevant checks +and report actual results and unverified claims. A passing check is not deployment +or merge authorization. -## Build and release protocol +PR #5 remains unmerged. The existing Railway deployment blocker is authenticated +service access and verification of its identity, volume and runtime URL. The +[canonical release status](https://github.com/Loptr-Lab/pixie-ecosystem-guide/blob/main/COMPANION-HOSTING-STATUS.md) +links the already prepared configuration, acceptance checks and rollback; do not +copy or improvise those instructions here. Local restart tests and a static preview +do not establish Railway persistence, hosted MCP acceptance or physical iPad support. -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. +Preserve the guide, ChatGPT Site, installed plugin, domains and existing source. +No new deployments, merges, Tangled synchronization, repository deletion/archival, +domain changes or plugin replacement are authorized by this update. Public plugin +release work in [training issue #42](https://github.com/Loptr-Lab/training/issues/42) +is historical follow-through, not the immediate contributor task or an instruction +to publish now. ## Current boundary @@ -47,4 +82,4 @@ Keep the existing repositories and domain. ecosystem.loptrlab.com remains the hu ## Source and maintenance -The companion README carries implementation commands and release details. Before editing, reconcile the actual deployed source and the GitHub contribution source; do not assume automatic synchronization. Follow the [canonical ecosystem architecture](https://github.com/ibloud/ibloud.github.io/blob/main/docs/ECOSYSTEM_ARCHITECTURE.md) and [PIXIE interface track](PIXIE_ANNOUNCER_TRACK.md). Existing work is reused; failed retrieval is not proof of loss. +The [Companion README on its existing review branch](https://github.com/Loptr-Lab/pixie-ecosystem-guide/blob/creator-workspace/apps/companion/README.md) carries implementation commands and release details. Before editing, reconcile the actual deployed source and that GitHub source; do not assume automatic synchronization. Follow the [canonical ecosystem architecture](https://github.com/ibloud/ibloud.github.io/blob/main/docs/ECOSYSTEM_ARCHITECTURE.md) and [PIXIE interface track](PIXIE_ANNOUNCER_TRACK.md). Existing work is reused; failed retrieval is not proof of loss.