Codaegis

Help with code-change decisions

Fictional, local, resettable, provider-free, and consequence-free.

Customer operating guide

Follow the current controls from sign-in through one read-only Decision, records, support, and account closure.

Start here

One route through the current customer controls.

This guide names the controls you will see and the recovery action to take when an outcome is unclear. Server status remains authoritative.

These are real account controls for admitted customers. The fictional example is a separate learning experience: it does not authorize source, fund an account, or submit customer work.

Sign in to Codaegis

01

Sign in, establish eligibility, and read current terms

Sign in with the identity control. Codaegis account admission is a separate step from GitHub authorization. After sign-in, the completion page opens the workspace automatically; if it does not, choose Open workspace.

Sign-in alone does not establish eligibility. Follow the admission policy offered by the service; if no offer or access is available, use the account Support path instead of assuming enrollment is open.

  1. For a new individual account, review the offered version, check I agree to the current Terms of Service (version), then choose Create individual workspace. This first admission records the version; it is separate from the exact-document workflow below.
  2. Under Account, choose Review terms and notices. Verify the exact offered document, check I have read and agree to this exact version and document digest., then choose Accept this version or Accept this upcoming version, as shown. A stale offer requires a refresh and another review.
  3. A notice is recorded as presented only after it is visibly rendered. Choose Read exact notice document before Acknowledge notice. Notice acknowledgement records receipt, not consent.

If acceptance or acknowledgement is unconfirmed, choose Check current status, then Retry same acceptance or Retry same acknowledgement for the retained request. It stays on the current page; recovery after reload depends on session storage, which can be unavailable or lost when the tab closes. If the exact request identity is lost and readback does not confirm the outcome, use Support before replacing it. Do not consent to different bytes as a recovery step. If no versioned terms are published, there is no new version to accept; the original version-only consent is not evidence of exact old document bytes.

You may leave required terms unaccepted. Genuinely new funding, Decisions, and source activity remain paused, while saved records, eligible refunds, Support, closure, and already admitted completion and reconciliation remain available. An admitted running Decision may finish and be retrieved; do not replace it because terms changed. Notice presentation, acknowledgement, and explicit acceptance are separate records.

Under Outbound notice delivery, choose Refresh delivery history and Open delivery history to inspect bounded pages of recorded intent and observations. Previous deliveries, Next deliveries, Previous observations, and Next observations replace the current page instead of building an unbounded browser history. The recipient is shown only as Server-verified email recipient; no address or provider identifier is disclosed. Delivery history does not replace the document itself: use Read exact notice document to display and verify its exact body before acknowledging it.

  • Delivery intent recorded does not confirm dispatch. Dispatch recorded does not confirm provider acceptance or receipt.
  • Provider accepted request is not evidence that the customer received the notice. Only Delivery evidence recorded names a recorded delivery observation, and that still does not acknowledge the notice or accept terms.
  • Delivery failure recorded and Delivery outcome uncertain do not authorize a blind resend. Refresh the history and use Support if the record remains unresolved. Delivery record held for review means review is needed; this page does not invent an exact reason.

In the signed-in workspace: open Account, then choose “Review terms and notices.”

Back to guide contents

02

Connect one read-only GitHub source

In Source, choose Confirm GitHub account. Then enter the repository owner and name and choose Verify repository. A callback message tells you to check the current connection; the callback alone does not confirm a usable connection.

  • Codaegis uses read-only source access for the selected repository. It cannot merge, deploy, publish, or write to that repository.
  • If the current grant can only be renewed, the control says Renew existing GitHub access. That action cannot add a different account, installation, or repository.
  • To stop future source reads, revoke GitHub access through GitHub. Signing out or revoking GitHub access does not erase saved records or close the Codaegis account.

In the signed-in workspace: choose Source, then “Confirm GitHub account” or “Renew existing GitHub access,” as shown.

Back to guide contents

03

Fund work, set a monthly limit, or request an eligible refund

Billing separates three requests: Add prepaid funds, Set monthly UTC limit, and Request eligible refund. Their action buttons are Add funds, Save limit, and Request refund.

Read the displayed available balance, reserved amount, Decision price, funding bounds, price version, and monthly UTC limit before acting. Amounts come from the current account policy. If Billing is unavailable, use Try again; this guide supplies no fallback price or funding amount. Values marked non-live belong only to that non-live account.

  • Add funds creates a funding operation; it does not itself complete payment. Continue only through a validated Continue funding link and return to Billing to read the recorded status.
  • The monthly UTC limit is a hard account control. Lowering it does not undo earlier spending or reservations. A stale price or amount outside the current bounds is rejected rather than silently adjusted.
  • A refund can be requested only for an eligible settled funding receipt and its available refundable amount. A request does not erase completed Decisions or required accounting records.

Unused credits do not expire. Completed work consumes its reserved amount once; confirmed failed work restores available value. An unclear outcome stays subject to readback and reconciliation. Eligible unused cash-funded refunds follow the original funding method when possible; requesting a refund is not confirmation that money arrived. Timing, fees, and detailed exceptions remain unpublished on the refund policy, so do not infer a refund date or fee from this guide.

In the signed-in workspace: choose Billing, then select the required request.

Back to guide contents

04

Start one immutable Decision and recover before retrying

In New Decision, select the Read-only GitHub repository, enter the Pull request number, choose the AI authoring context, and answer the Consequential risk trigger. Then choose Start one decision.

  • The browser needs local storage and Web Locks so it can save the exact request and prevent two tabs from starting the same local intent at once.
  • If the acknowledgement is ambiguous or unavailable, choose Recover saved Decision. Do not create another request. Replaying the same key reads the same Decision and does not rerun it.
  • On the result page, use Refresh durable state. A failed, timed-out, or stale Decision has no verdict; repair the cause and form a new intent rather than treating it as Review.
  • Prepare another Decision appears only after a terminal state and a fresh readback. A completed packet keeps Answer, Why, Missing proof, Next action, and Safe state together; Export JSON and Export Markdown export that packet.

In the signed-in workspace: choose New Decision and complete the four fields before “Start one decision.”

Back to guide contents

05

Recover Decisions and prepare coherent customer-record snapshots

Decisions lists completed packets found among the latest 50 Decision records. Unfinished records consume that window and are not shown there. Use the current result page for the latest running, failed, timed-out, or stale Decision. An unavailable list does not mean records are empty or deleted.

Prepare and recover

Under Account, choose Prepare current record snapshot. New snapshots use bounded volumes; older single-manifest snapshots remain readable under their original contract. If confirmation is unavailable, use Check current snapshots, then Retry the same snapshot request only for the retained exact request. An exact committed request can replay after account closure or snapshot expiry: it returns the original immutable root manifest and does not renew availability. Resolve an unknown outcome through scoped readback or exact replay before choosing Abandon this retry and prepare a new snapshot; that action discards the browser-held retry key.

The index shows one bounded page of 10 snapshots at a time. Use Previous snapshots and Next snapshots, then choose Open snapshot for one immutable root manifest. The changing index is not itself a coherent export. A multi-volume root reports the complete record, byte, volume, and file counts without loading every volume into the page. Use Previous volumes and Next volumes to move through fixed pages, then Open volume for one bounded volume manifest. If preparation is unavailable until a download policy is configured, no duration is promised here. Existing records can still be checked with Refresh record snapshots.

If browser storage is unavailable, the exact uncertain request stays on this page only. After reloading, check the index for a committed snapshot. A draft that never reached the service is not durable history.

Download and verify

Download manifest retrieves the root manifest. Start full record download requests the exact NDJSON byte stream with server backpressure. For interruption recovery, open each volume and use Download volume manifest and Start volume download. A click does not prove that the browser completed any download.

Use Verify and download file for an individual bounded file and Show more files to reveal the rest of the open volume. Keep the root manifest, volume manifests, and files from the same snapshot. Follow numeric volume ordinal first and numeric file ordinal within each volume, both starting at zero; filename alphabetical order can put 10 before 2. Verify the root volume-chain digest, each volume chain and manifest digest, and each file’s byte count and SHA-256. Concatenate the binary bytes in that order before decoding UTF-8 and parsing NDJSON, because a character or JSON line can cross a file boundary. The final completion object repeats the snapshot identity and complete counts. Do not treat a partial volume set as a complete snapshot.

  • The snapshot contains the customer-facing records currently available to this account across the families named by its manifest. It is not raw source, a provider export, or a global compliance export.
  • Records unavailable when prepared names any records whose retention had already expired, with the exact excluded count. “Coherent” does not mean expired content was restored.
  • A current record snapshot includes the exact notice documents and the customer-visible delivery intents, server-verified recipient metadata, and observations that remain available under current retention. It does not expose transport credentials or provider-held protected data. An older frozen export remains unchanged, and preparing a new snapshot does not extend an earlier deadline.
  • The displayed Available until value is the download deadline. No new general retention duration is promised. After expiry, metadata can remain visible while bytes are denied.
  • If any volume or file is missing, corrupt, incomplete, or expired, stop and reread the root and volume manifests. Do not combine volumes or files from different snapshots. A deliberate new snapshot uses records available under current policy and cannot recreate content already unavailable.
  • A bounded snapshot may contain up to 64 volumes. Each volume retains the existing limit of 512 files at 256 KiB each. Preparation publishes only a complete root; overflow or failure leaves no readable partial snapshot. The server’s configured limits remain authoritative.

The separate original export remains the closure prerequisite. Existing v1/v2 original exports keep their immutable 16 MiB format and original 30-day download window. For a larger history, choose Prepare bounded original account export; it creates a separately designated multi-volume original export only when its own server policy permits. A normal current snapshot does not substitute for it, and no new download duration is promised here. Close account access becomes available only after current account status confirms an original export.

In the signed-in workspace: choose Decisions for completed packets, or open the latest result for nonterminal status. Use Account for exports and current record snapshots.

In the signed-in workspace: use the current result page for the latest Decision, and keep an exact result link for an earlier unfinished Decision.

In the signed-in workspace: choose Account, then Current customer records.

Back to guide contents

06

Use case history, exact replay, and current status in Support

Open Support and find My support cases. Choose an existing case to read its original request, replies, delivery state, response state, resolution state, and any current escalation handling. Use Refresh cases or Refresh case status for fresh state.

You do not need a saved case URL: sign in as the same customer and use the case index, including Load more for older cases. After navigation or reload, this index can recover a committed request whose acknowledgement was lost; a never-recorded local draft cannot be recovered there.

  • For a new issue, choose an allowed topic, acknowledge the safe-content guidance, and choose Record support case.
  • If confirmation is unavailable, keep the original subject and message unchanged. Use Refresh my cases for readback and Retry the same request only for that exact request. A request recorded before closure can still replay afterward even when its topic is no longer allowed for new intake.
  • Use Record reply, or Record reply and reopen when shown. An uncertain reply also needs exact replay or readback before another reply.
  • Do not include credentials, private source, full packet contents, internal prompts, or payment-card and bank data. No response time or SLA is promised.

A new case or reply and an exact replay have different confirmations. An existing request is not added again, and replay does not invent reopening or a queue change. Initial topic guidance is not a human response. Current status may require human handling; there is no promised staffed coverage or automatic resolution. The in-app case remains the record to check, and opening an email draft does not prove delivery.

For email recovery, open Account, then Email verification and history. Use the verified primary email of your original sign-in account. When verification sending is available, request a code and paste it under Confirm email ownership. Opening or refreshing the page sends nothing. An uncertain send stays held; use its still-valid code if it arrived, or recover the original record through Support. An explicitly offered replacement preserves the earlier attempt. If recipient authorization has expired while its ownership proof remains valid, choose Refresh recipient authorization; this sends no email.

To associate an email with Support, return to Support email association, prepare a reference for your own existing case, then review received text and explicitly confirm it in the application. An email address or From header cannot establish authorship. Verification, association, notice receipt and Terms acceptance remain separate. Closed accounts retain only continuing obligations; email verification does not reopen service. If sign-in itself is unavailable, use the original account’s existing sign-in recovery options.

In the signed-in workspace: choose Support, then find “My support cases.”

Back to guide contents

07

Close access while continuing obligations stay visible

Before closure, use Prepare original account export and, when useful, Prepare current record snapshot. Complete downloads before each displayed deadline. Authenticated continuing record access remains available after service access closes; closure does not renew a download window.

  1. In Account, type CLOSE MY CODAEGIS ACCESS exactly and choose Close account access.
  2. If closure is pending, choose Check closure status. Pending is not active access, and it is not proof that every deletion or retained obligation is complete.
  3. After access closes, new funding, Decisions, and source activity stop. Records, eligible refund requests, terms/notices, and existing Support cases remain available with valid authentication. New Support intake is limited to your own refund, billing, privacy, or closure obligations that the server currently permits.
  4. Refund, dispute, tax, security, deletion, backup, legal-hold, and Support states continue on their own recorded timelines. Account closure does not rewrite completed Decisions, receipts, or immutable exports.

If closure confirmation is lost, use Check current account status and Retry the same account request. If the signed-in identity changes, the account view holds old records; choose Reload account to load the current identity. No saved request authorizes a different customer.

Provider-held records, protected disclosures, global retention, deletion, and backup completion require their own handling. A download deadline is not proof of erasure. Read the Privacy policy for current disclosures and use Support for an unresolved privacy obligation; unpublished provider and retention details are not supplied by this guide.

In the signed-in workspace: choose Account for exports and closure. Use Support for the topics the current server allows after closure.

Back to guide contents