Skip to content

feat: add editable prompt file versions - #1390

Open
helloxjade wants to merge 1 commit into
OpenCSGs:mainfrom
helloxjade:codex/prompt-file-versions
Open

feat: add editable prompt file versions#1390
helloxjade wants to merge 1 commit into
OpenCSGs:mainfrom
helloxjade:codex/prompt-file-versions

Conversation

@helloxjade

Copy link
Copy Markdown

What is this feature?

Adds a minimal lifecycle for editable, named versions of individual prompt files in Prompt repositories.

A version is created only when the user explicitly requests one. Saving an existing named version updates the Git commit referenced by that version; it does not create another version automatically. Git history continues to retain each underlying file revision.

The change adds:

  • A prompt_versions table keyed by prompt repository, file path, and version name.
  • APIs to create, list, read, and update a named prompt-file version.
  • Git-ref based prompt parsing so version reads resolve the commit stored by the version record.
  • Read/write permission checks using the existing Prompt repository permissions.
  • Validation for .jsonl paths and the existing single-content prompt format.

Why do we need this feature?

Prompt files currently expose only the latest default-branch content. Users need stable, user-controlled version names without generating a new managed version for every typo or save. This provides the smallest general-purpose version lifecycle while keeping existing Prompt APIs and file formats compatible.

Who is this feature for?

Users and integrations that manage prompt files in Prompt repositories and need to address named versions such as v1 and v2.

Implementation notes

  • A prompt is identified by repository ID plus file path; renaming a file starts an independent version sequence.
  • Version names are trimmed, must be non-empty, and are unique per prompt file.
  • Creating a version stores a Git commit reference rather than copying prompt content.
  • Updating a named version writes the prompt to the repository default branch and advances that version's commit pointer.
  • Existing prompt create, edit, list, and view APIs remain unchanged.

Local test results

  • go test ./component ./api/handler -run 'Prompt' -count=1
  • go test ./builder/store/database -run '^TestPromptVersionStore$' -count=1 -v
  • go test ./api/router -run '^$'
  • go test ./builder/parquet ./builder/temporal -count=1
  • make swag
  • golangci-lint run --new-from-rev=HEAD — 0 issues

The full repository test run passed all executed packages. Two initial dependency downloads timed out and their affected packages were rerun successfully after configuring a reachable Go proxy.

Which issue(s) does this PR fix?

N/A

Special notes for your reviewer:

This PR intentionally excludes variables, multi-role messages, version comparison, rollback, dedicated publish permissions, and business audit integration.

@HaiHui886

HaiHui886 commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

@helloxjade Thanks for your contribution. CSGHub support create named version for prompt repo, Is it match your case? Can you describe what is your use case in detail to help us verify this commit?

@helloxjade

Copy link
Copy Markdown
Author

Thanks for the clarification. The existing Prompt Repo named-version feature may cover part of the use case, but the use case behind this PR is file-scoped version management.
A Prompt Repo may contain multiple prompt files, for example summary.jsonl and classification.jsonl. We want each file to have an independent version sequence, so clients can address a prompt by (repository, file_path, version).
For example:

  • summary.jsonl can have v1 and v2
  • classification.jsonl can remain at v1
  • Saving changes to summary.jsonl/v1 updates that named version
  • A new v2 is created only when the user explicitly requests it
    This is intended as an editable named version/pointer for one prompt file, rather than an immutable snapshot of the whole Prompt Repo. Repository-level versions would also include unrelated prompt files and couple their version lifecycles.
    If the existing Prompt Repo named-version feature already supports file-scoped version creation, version-specific reads, and updating an existing named version, then it may already match this use case. Could you please point me to the related API or implementation? I would be happy to reuse or adapt the existing mechanism instead of introducing a duplicate one.

@helloxjade Thanks for your contribution. CSGHub support create named version for prompt repo, Is it match your case? Can you describe what is your use case in detail to help us verify this commit?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants