Skip to content

Project notice

1.31.0 — Nova-Seed projects and inspectable Ascension cycles

Version 1.31.0 brings the Nova-Seed Studio, authorized native execution, recovery hardening and linked successor cycles into one release path. It extends the existing Studio and shared MARK wallet rather than introducing another wallet or transaction journal. Original research, diagrams, deployed contracts and deployment records remain available.

These notes describe the release scope. The release-readiness record identifies the integration and verification status. A version label does not establish that a tag, release asset or public website has been published. Use the matching release manifest, checksums and public-site acceptance for the actual delivered identity.

Start with something you can keep

  1. Open the English/French first-use guide, then open Nova-Seed Studio. Preparing a project needs no wallet or paid model.
  2. Describe the work, check its exact plan, encrypt the package and download recovery before continuing. Keep the capsule passphrase separately. The older readable kit contains plaintext plan information; the private full-project export encrypts the extended project history.
  3. For execution on your own machine, follow installation and the local operator handoff. The administrator first installs trusted identities and private role credentials. Work files cannot create that authority.
  4. Review the actual result and its evidence. Worker execution, result acceptance, contract payment and adoption of a better method are separate decisions. Continue with new inputs and fresh permissions.

The archived October 11 Mainnet deployment supports inspection and eligible recovery. New exposure stays blocked. No replacement production profile is approved by this release document. A software release does not deploy or upgrade contracts, start a paid provider session, or authorize a live canary.

What changes

  • A recoverable project. Keep the opportunity, exact plan, seed, campaign, jobs, native results, evaluation and successor cycles together. Private recovery preserves original signed records while importing them as historical evidence, without reactivating grants or spending permissions.
  • Real bounded work through the installed runtime. Seal richer terms before posting, bind the actual assignment, obtain a separate controller grant and execute through the existing SUCCESSOR dispatcher. The local console provides typed setup, pairing, explicit signing/execution and acceptance-owner review.
  • Stricter recovery and delivery checks. Preserve exact signed bytes and large timestamps, distinguish SHA-256 integrity from the contract's Keccak commitment, verify the selected receipt and event, and reject mismatched plans, roles, profiles and imported authority. Native delivery and extended cycle records retain their separate schema and trust requirements.
  • Clearer financial observations. Recheck retained settlements against current canonical chain observations. Separate recipient income, burns, refundable custody, backing, stake and the selected owner's wallet balance. A reinvestment suggestion reserves nothing; actual funding still uses the existing separate approval and purchase confirmations.
  • A deliberate next mission. Freeze the comparison before execution, preserve negative findings, review the proposed change, verify the rights to the selected source artifact and create distinct input, assignment, run, result and settlement identities for the successor.
  • One maintained release route. Carry the combined source through existing regression, preservation, browser, contract, packaging, public-site and publication checks. Previous successful branch runs do not automatically qualify a merge resolution or regenerated release assets.

Evidence and limits

The historical 80-case index, engineering map and implementation handoff remain inspectable. Their recorded snapshot has 10 passed, 65 partial and 5 blocked requirements. It includes an actual production-browser/native/ disposable-EVM journey with three jobs across two cycles. Those reports identify their own source hashes and environments; their results are not relabeled as verification of 1.31.0's combined source.

New integration results must identify the merged commit, actual environment, commands, outcomes and artifact digests. The release manifest and validation archive provide the delivered release's evidence. A failed broad run cannot be turned into a passing run by summing selected retries. Historical broad pytest and type-check failures remain recorded until separately superseded by appropriately scoped results.

The complete 80-case product scope is not claimed. Per-edge observed actions, shared allocations across projects/devices, complete principal-return and cost accounting, and all interruption/scale trials retain their documented limits. Human accessibility, physical wallets, real storage accounts, independent actors, live model/provider execution and Mainnet commissioning need separate evidence. Fixture keys and local storage do not establish those capabilities; no realized profit or general agent capability is asserted.

Upgrade and recovery

Use assets from one release and install into a new environment. Pause the old process, keep a private backup and an independently retained journal checkpoint, and follow operator recovery. Do not run two versions against the same private home. Retain or reprovision the operator configuration, trusted identities, private signer files and separate approval-token slots; a public project export does not back up those secrets. Existing capsule/readable-kit formats keep their original meaning.

Export project recovery and unresolved transaction intents before changing browser environments. An uncertain submission requires reconciliation before another attempt. A frontend rollback does not reverse a transaction, pause immutable contracts, erase obligations or reactivate an old runtime grant.

Français · commencer et conserver son travail

  1. Ouvrez le guide de première utilisation, puis le Studio. La préparation locale ne demande ni portefeuille ni modèle payant.
  2. Décrivez le travail, vérifiez le plan, chiffrez le paquet et téléchargez la sauvegarde. Conservez le mot de passe séparément. L'ancien kit lisible contient le plan en clair; l'export privé chiffre l'historique étendu. N'utilisez jamais la phrase de récupération de votre portefeuille.
  3. Pour exécuter le travail, installez la version correspondante et utilisez la console locale. Les identités de confiance et les autorisations sont préparées séparément par l'administrateur.
  4. Examinez le résultat réel, puis les décisions de revue et de règlement. Une nouvelle mission reçoit de nouveaux paramètres, des autorisations actuelles et ses propres preuves; renommer un ancien résultat ne constitue pas une nouvelle exécution.

Les résultats historiques restent liés à leurs sources d'origine. Les contrôles de la version intégrée et l'identité de sa publication doivent être vérifiés séparément. Cette version ne prétend pas satisfaire les 80 exigences, qualifier un portefeuille physique ou un service externe, ni autoriser une activité Mainnet. Les restrictions du déploiement archivé et les droits des autres participants restent en vigueur.