Package and export a project

Applies to SiliconForge 0.1.2 · Updated 2026-09-30. Check platform limits.

Before this task: Review results for the exact source →

Export a reproducible digital-IP project, not a SiliconForge installer. Package integrity, engineering readiness and software redistribution rights are separate questions.

Recover saved source without qualification#

Choose Application menu → Export source copy…, or use the same action in Package, and select a new .tar.gz filename. This separate offline recovery action remains available in read-only subscription access and does not require passing engineering checks. Keep the archive and its JSON sidecar together.

It copies saved source files and permitted public project metadata, not unsaved editor changes. Private application state, Git history, caches and credential-like files are excluded; unsafe paths and links are rejected. It is not a complete workspace backup. The manifest identifies a source-recovery-copy with readiness not_evaluated: archive integrity is not design qualification, and this action does not activate paid work. Review the copy before sharing it.

Review what will leave the workspace#

Save source edits, inspect the intended deliverables and remove credentials or private design material you are not authorized to share. Include relevant RTL, tests/assertions, constraints, licenses/notices, dependency locks and verification profile/evidence. Missing information must remain visible; an archive file alone does not prove the design is ready.

To author missing project inputs without a terminal, use the application menu → New project file…. Supported text includes HDL, .sdc/.xdc constraints, .md/.rst documentation, and standard README, LICENSE, COPYING or NOTICE filenames (also with .txt). Enter the constraints and licensing terms appropriate to your project; do not add placeholder files merely to satisfy the inventory. Reopen and edit saved files under Project → Files. These text files are not automatically HDL compilation inputs. Creation and saving require an active desktop subscription.

Export from the native application#

1. Open Package and read Package input checklist, input cards and Export manifest.
2. Resolve missing or stale evidence and dependency/license issues appropriate to the recipient. “Inputs present” means the structural package inventory is available, not that engineering checks passed. Read retained failures and current source/profile bindings in Verify; missing package inputs remain visible.
3. Choose Export reproducible package. Select a new .tar.gz filename; the archive and its JSON sidecar must not already exist.
4. Preserve the archive together with <archive>.json. The native export is a sf/project-package-v2 workspace-inventory package, not the older committed-tree command format below.
5. Verify it through project.package.verify using the same core capability version, and inspect the returned readiness and manifest.

Expected result: a deterministic archive, hash-bound sidecar and explicit readiness information. A structurally valid export may still report missing engineering inputs; package verification checks integrity, not whether every test establishes your product requirements. Internal databases/assistant state are excluded from this native export.

Advanced: export a committed Git tree#

For operators with authorized access to a compatible source checkout, the core CLI also supports a simpler offline Git-tree export. This is a distinct compatibility interface: it requires a Git repository with no tracked modifications, exports the requested committed revision, and does not include untracked work. Run from a compatible SiliconForge source checkout with its dependencies installed, PYTHONPATH=core:., and a python resolving to that environment. These are not commands to run in a bare installed-app folder:

python -m sf_core export --workspace /path/to/project \
  --destination /path/to/new-export --tree HEAD
python -m sf_core package --workspace /path/to/project \
  --destination /path/to/project.tar.gz --tree HEAD
python -m sf_core package --verify /path/to/project.tar.gz
python -m sf_core package --extract /path/to/project.tar.gz \
  --destination /path/to/new-restored-project

This CLI archive uses sf/project-package-v1. Keep its .json sidecar and use the matching CLI verifier/extractor; do not feed a native v2 archive to the v1 verifier. Both archive destinations must be new, and extraction must not overwrite an existing working project. Any confidential file committed to the selected tree must be reviewed before export; Git history selection is not secret scanning.

Example: hand off the stream register#

Use the two-file stream example, save it and inspect Package. The demo intentionally lacks a complete release/license/constraint package: keep those missing categories visible rather than fabricating them. Export to a new destination, verify the matching format, and inspect the file manifest. The receiver should rerun the directed test with the stated simulator and recognize its limited coverage.

Failure and recovery#

A destination-exists error protects previous artifacts; choose a new destination rather than overwriting an unreviewed archive. A dirty-tree error in the Git CLI means tracked work is not safely bound to the selected commit; review and commit or preserve it, never discard it just to export. Hash, unsafe-path or symlink failures require inspecting the package/source boundary, not disabling verification. An application-installer release gate is not required to export your own project and does not certify it.

Related: dependency provenance, RPC and CLI reference, backup and restoration, engineering evidence.

Need help? Report an issue. Include your application version; never include credentials.