All Zyel Labs

By Chason Arthur · Revision 128.003 · Updated

Workflow engineering · Field notes

From active tasks
to a board
you can trust.

How we coordinate Codex work, preserve the owner’s Scrum board, and move reviewed updates from our primary Windows workstation to our AWS-hosted server.

Implementation notes · 4 November 2026 · Synthetic examples throughout

Our current path

01
Active Codex tasksAuthorized results and verified evidence
02
Primary workstationCurated JSON + PowerShell producers
03
AWS Systems ManagerSigned Run Command · durable command ID
04
Existing Linux serverNative PHP sync → private board + Wall

← Original result, readback and a zero-change repeat return to the coordinator.

Reading preferences · shared across Zyel Labs

Optional preferences stay in this browser for 30 days; no account or AWS sync is performed.

Enable JavaScript to use the shared Lab appearance controls.

Stable identityThe same work updates the same task.
Owner edits surviveVersions and fingerprints catch conflicts.
Evidence stays honestReviewed, deployed and done are distinct.
01 / ARCHITECTURE

One AWS-hosted server.
Two separate control loops.

The workstation is our producer and coordination boundary. It reads permitted task results, checks what was actually delivered, maps the work to existing Scrum identities, and prepares a small immutable batch. Its PowerShell wrappers use the existing approved AWS profile to reach the server through Systems Manager.

The Linux server runs the native Scrum application. A PHP command validates the batch, takes the existing lock, checks the current workspace and task versions, preserves a private backup, and commits only the accepted changes. The owner reads the result through the existing authenticated board.

The server is already in the AWS cloud. This path is workstation → AWS control plane → managed server → board UI. There is no separate second upload of the board to another cloud database in this workflow. SSM carries commands and results; the application’s private server-side state remains the board’s authoritative data.

Cloud coordination is a different loop. A cloud task can ask an authorized connected workstation task to do local work and report its results. A cloud conversation does not automatically inherit the workstation’s files, AWS profile or access to every other Codex conversation. Our bridge uses supported, authorized task access and explicit result handoffs.

This Lab documents our custom integration, rather than a built-in “sync all Codex chats to Scrum” feature. The download implements a small local teaching model; it does not connect to our board or provision AWS resources.

02 / RESPONSIBILITIES

Decide what each system owns.

LayerOwnsDoes not establish
Codex taskRequests, implementation results, artifact and test evidenceA successful turn alone does not prove the whole request is delivered.
CoordinatorSource mappings, curated events, scope and serialized native windowsA summary cannot manufacture an approval or deployment result.
Scrum boardNative task status, owner notes, versions and project membershipThe board is not a raw transcript archive.
Progress WallVersioned preview receipts and artifact observationsA new receipt does not mark a task done or approve public artwork.
AWS SSMCommand identity, execution status and bounded result transportTransport success is not application readback or product acceptance.

Our event phases distinguish requested, in_progress, locally_reviewed, awaiting_approval, deployed_verified and done. A deployed subset can remain in progress as a whole task. A blocked task retains the actual reason instead of quietly becoming completed.

Only verified whole-scope evidence supports done; deployment-required work also needs live production proof. Pauses, cancellations and reactivation have their own explicit owner-decision checks.

03 / HANDS ON

Preview. Apply. Repeat.

The essential behavior fits in a small experiment. The event expects workspace revision 7 and task version 3. Try a normal update, an intervening owner edit, and an already-processed event.

LOCAL SIMULATION · NO NETWORK OR ACCOUNT ACCESS

Starting condition
Workspace revision7
Task version3
Demo writes0

This browser model demonstrates identity and conflict handling. The production utility also validates privacy, source hashes, authorization, task mappings, completion evidence, locks and backups. JavaScript is optional for the rest of this tutorial.

04 / HOW TO

Run a reconciliation from the workstation.

  1. Inspect authorized work and current state.Read current task results through permitted task tools. Gather actual artifact, PR, deployment and verification links. Inspect existing projects and cards, current source pins, workspace revision and task versions. Keep unknown mappings visible as holds.
  2. Curate work metadata.Match stable source task/thread/message IDs to the existing native card. Select the supported project/category. Write a short factual summary and evidence phase. Leave private conversations, manuscript text, credentials and unrelated personal data out.
  3. Freeze and validate the batch.Retain its exact bytes and SHA-256. Run local ValidateOnly. It makes no AWS call. The example IDs in this Lab are synthetic and cannot be used as real source proof.
  4. Preview against the actual board.Use the existing wrapper. Read the proposed new/updated/unchanged/held counts and exact changed IDs. Resolve owner/version/source conflicts before any write. If nothing changed, stop.
  5. Apply the reviewed changes once.Within an admitted native window, recheck current controls and use the reviewed workspace fingerprint. The application takes the lock, verifies versions, backs up the current private state and performs its guarded commit.
  6. Read back and repeat the exact preview.Inspect every changed card and preservation evidence. Repeat the same immutable batch: expect zero proposed changes. Retain original command IDs, results and receipts; report actual counts and working board links.

Existing PowerShell wrapper pattern

These commands show the installed project’s workflow. Invoke-ScrumSync.ps1 is a custom producer, not an AWS or Codex built-in. Use your reviewed installation path and actual IDs; the download does not include production credentials or this private wrapper.

@@CODE_INSPECT@@

After accepting the exact preview, use its actual reviewed fingerprint. The hash below is deliberately a placeholder; never replace it with an old default or automatically authorize an arbitrary preview.

@@CODE_APPLY@@

The second preview matters. It proves the same event is already accounted for. Keep the original batch unchanged: rewriting its summary, timestamp or expected version while reusing an old message identity creates conflicting evidence.

05 / DATA CONTRACT

Send events, not a workspace replacement.

The producer sends reviewed task metadata. The server resolves stable source identities and applies a bounded change to an existing card, or creates genuinely new requested work in the existing project icebox. It preserves owner titles, notes and unrelated records according to the native contract.

@@CODE_EVENT@@

Illustrative native-shaped input: all IDs and the observation time above are synthetic. Real batches require actual authorized source identities, current guards and privacy review. The local Python demo uses its own smaller schema, clearly separated from this native shape.

Stable identity

The same source task, thread and message identify the same evidence event. An optional explicit board-card mapping resolves an existing card without guessing from its title.

Two conflict guards

The workspace revision/hash protects the overall preimage. The task version protects the individual card. A newer owner edit is a reason to reconcile, not overwrite.

Immutable event digest

An identical processed event is a no-op. The same identity with changed content is refused. New evidence needs a genuine new source event.

Minimal disclosure

Summaries and verified links are enough. IDs are provenance, not invented chat URLs. “Privacy reviewed” must reflect a real review of what is being sent.

A runnable local model

The source bundle has a dependency-free Python example and tests. It updates only in-memory synthetic state and includes no AWS client, task-session reader or production write route.

@@CODE_LOCAL@@

The tests cover repeat no-ops, changed-message conflicts, intervening owner edits, preservation of manual fields, completion evidence and deployment requirements. They demonstrate the mechanism; they do not certify a production sync.

06 / TRANSPORT

AWS carries the command.
The application decides the change.

The workstation’s approved AWS CLI profile signs a Systems Manager SendCommand request to the existing managed Linux node. Our wrappers bind the account/principal, instance/region, approved document, reviewed source hashes and bounded operation. They persist a local transport receipt and the original command ID before polling.

On the server, the native PHP CLI runs through the existing application-owner path. Temporary input is private; affected state receives a private preimage backup. SSM returns the execution result to the workstation. The coordinator then reconciles the actual application result and readbacks.

Inspect an original command after a lost response

@@CODE_SSM@@

This is a read-only lookup of the original command, not a replacement submission. Run Command is eventually consistent: a just-sent invocation may not appear immediately. Keep its ID and collect that result; a delayed lookup is not permission to send the write again.

Check the command’s terminal status and response code, then the application’s structured success/readback evidence. Preserve a pending native approval prompt as pending; a chat instruction and execution-tool approval are separate controls.

No automatic credential handoff. Connecting a cloud task or signing into the board does not give that task the workstation’s AWS permissions. Use the existing approved execution path. This tutorial does not create keys, change IAM, open network access or expose a new sync endpoint.

07 / VISUAL EVIDENCE

Sync the board first.
Attach receipts separately.

The Progress Wall references existing board tasks. Its receipt events carry the task/version and source mapping, artifact identity, actual verification time, real URL and verification kind: local review, private preview or live evidence.

The Wall has its own revision, lock, immutable event history and guarded producer. Its Apply step binds both workspace and Wall fingerprints. It cannot change native task status. A later task edit can make a receipt historical without erasing its original evidence.

Our sequence is board qualification/preview/apply/readback, then receipt preparation/preview/apply/readbacks and an identical no-change replay. Independent local drafting and public reads can run concurrently when they do not conflict; shared native mutation windows remain serialized.

A preview is not a public release. Preserve source-site frame restrictions: if X-Frame-Options or CSP blocks embedding, provide a verified link or permitted dated capture. Private artwork, owner photos and held versions keep their privacy and explicit approval state.

Do not relabel an old capture as a fresh verification. If a current public page has materially changed, preserve that page and rebase the receipt’s evidence before accepting a new batch.

08 / FAILURE HANDLING

Recover from evidence,
not assumptions.

ObservationNext action
Computer offline or profile unavailableKeep pending work. Report the missing environment/access; do not silently switch identities or assume cloud access.
Source or task version driftInspect current state, preserve owner edits, and prepare a reviewed successor using real source evidence.
Reader output exceeds its boundKeep the failed receipt. Compact the necessary projection and review the correction. An application output guard is not proof of an AWS quota.
Command submitted; result missingCollect the saved original command ID. Never treat an interrupted poll as proof of failed delivery.
Uncertain write or partial resultHold replay. Reconcile the journal, actual affected records and original command before deciding any bounded recovery.
Repeat preview proposes zero changesStop without another Apply. Preserve receipts and report the verified result.
Public artifact differs from its old hashHold that evidence binding. Ask the existing source owner to identify the newer accepted version; do not restore old site content to fit a receipt.

Production coordination retains exact originals, backups and uncertainty states. Restoring an old whole-workspace file over newer owner edits is not a reconciliation strategy.

@@ALTERNATIVES_AND_RECORDING@@
11 / KEEP BUILDING

Take the example apart.

Code, fixtures and a practical guide

The resource kit contains the complete readable tutorial source, production CSS build, browser simulator, Python model, synthetic fixtures, focused tests, setup guide and recording materials. Code is MIT licensed. Project Lead: Chason Arthur. No private task records, production wrappers, account/instance IDs or credentials are included.

Download SOURCE.zip

Teaching code, not a production connector. Python 3.10+ · Node.js 18+ for the CSS build · no AWS calls. The kit includes README, GETTING_STARTED, LICENSE, checksums, dependency pins and a recording storyboard.

Sources and implementation boundary

Project-specific behavior was checked against the existing Conversation-to-Scrum and Progress Wall runbooks and retained execution receipts on 4 November 2026. Those private operational records are not part of the download. The examples substitute synthetic identities and omit private deployment bindings. Product documentation below describes the platform capabilities, not this custom adapter.

Open the owner-authenticated board or Progress Wall if you have access. This public Lab grants no board access.

@@COMMUNITY@@