Self-hosted deployments want every new account to have somewhere of its
own to publish, without asking an administrator for a namespace first and
without pushing drafts into `global`.
Add an operator-controlled policy, off by default so upgrading changes no
behaviour. When enabled, an account that becomes usable gets a namespace
it owns. "Private" here means a team namespace whose only member is that
account: namespaces have no visibility flag, and skill visibility stays a
property of each skill.
Trigger points. UserActivatedEvent is published wherever an account first
becomes usable:
- LocalAuthService.register
- IdentityBindingService.bindOrCreate, for ACTIVE first logins
- AdminUserAppService.updateUserStatus, on a transition into ACTIVE
The third matters for deployments that gate access behind approval: those
accounts are created PENDING at the first OAuth attempt and only become
usable when an administrator approves them.
Why an AFTER_COMMIT listener rather than a call alongside
GlobalNamespaceMembershipService.ensureMember. Both namespace.created_by
and namespace_member.user_id reference user_account(id), which rules out
each obvious alternative:
- Joining the registration transaction lets a slug clash roll the
registration back, so a namespace failure costs the user their account
— or, on OAuth, their login.
- Suspending it with REQUIRES_NEW leaves the new transaction unable to see
the uncommitted user_account row, so the foreign key check blocks on the
outer transaction's row lock and the two wait on each other.
Provisioning after commit avoids both. The listener is deliberately not
@Async, so the namespace exists by the time the user's next request
arrives, and it swallows failures.
Naming. Two templates over ${username}, ${email_prefix} and ${user_id};
unknown placeholders are left in place so a typo is visible rather than
silently dropped. ${username} falls back to the email local part and then
to the user id. Slugs go through the existing slug rules, which is why the
console renders a live preview: underscores are not legal in a slug, so
`${username}_space` yields `alice-space`. A taken or reserved candidate
gets a numeric suffix, so `admin` becomes `admin-2`. Owning any non-global
namespace already skips provisioning, which keeps re-enabling an account
from handing out a second one.
The templates are not exposed in application.yml: they contain ${...},
which Spring would resolve as property references, and Boot 3.2 predates
placeholder escaping. Only the enable flag lives there; templates are set
in the console and default from PersonalNamespaceProvisioningProperties.
Updating the policy writes an audit entry with the before and after.
* feat(api): return skill labels from the skill listing endpoints on request
Skill labels were reachable only one skill at a time, through
/api/{v1,web}/skills/{namespace}/{slug}/labels, so a client rendering a list had
to issue a follow-up request per row.
Add includeLabels=true to GET /api/v1/skills and GET /api/web/skills. The labels
array is populated only when the parameter is set and left out of the payload
otherwise, so existing responses are byte-identical.
Labels for the whole page are resolved by SkillLabelProjectionService in three
queries — assignments, definitions, translations — rather than three per skill.
Closes#710
Signed-off-by: FenjuFu <fufenjupku@gmail.com>
* fix(api): use include parameter for skill labels
Signed-off-by: XiaoSeS <87064762+XiaoSeS@users.noreply.github.com>
* test(api): reject unsupported include before search
Signed-off-by: XiaoSeS <87064762+XiaoSeS@users.noreply.github.com>
---------
Signed-off-by: FenjuFu <fufenjupku@gmail.com>
Signed-off-by: XiaoSeS <87064762+XiaoSeS@users.noreply.github.com>
Co-authored-by: XiaoSeS <87064762+XiaoSeS@users.noreply.github.com>
Fix three blockers and one contract drift issue surfaced in code review:
1. API token policy: add skill:publish scope policy and authentication
policy for /api/cli/v1/skills/*/publish/validate. Without these the
AntPathMatcher pattern /publish would not cover /publish/validate,
so Bearer-token requests would be rejected by the scope filter.
2. Warnings semantics: dry-run now treats warnings as making valid=false.
The CLI publish flow uses confirmWarnings=false, so the real publish
rejects any warnings; dry-run must mirror that to avoid false positives.
3. Visibility parameter: validate endpoint now accepts the same
visibility multipart field as publish. The CLI forwards --visibility
so invalid values are caught at dry-run time rather than at publish.
4. Schema drift: resolvedSlug and resolvedVersion are nullable in
practice (returned as null when validation fails before resolution).
Updated schema.d.ts to reflect string | null instead of optional string.
Tests added:
- RouteSecurityPolicyRegistryTest: validate endpoint scope check
- CliDryRunValidateTest: custom + invalid visibility cases
- publish-dry-run.test.ts: --visibility forwarded to server
Add a validate-only endpoint (POST /api/cli/v1/skills/{namespace}/publish/validate)
that runs the full pre-publish validation chain without persisting anything.
This allows developers to check their package locally before actual publishing.
The validation covers:
- SKILL.md existence and frontmatter parsing (name, description required)
- File extension whitelist and size limits
- Credential leak scanning with line-number precision
- Slug generation and name conflict detection
CLI usage: `skillhub publish <path> --dry-run`
Closes#429
Introduce a dedicated `/space/$namespace/$slug/compare` page that compares
two published skill versions GitHub-style: left file list + right unified
diff. Backend exposes `GET /versions/compare` returning structured diff
(computed via java-diff-utils) with per-file hunks, binary placeholder,
and truncation flags. Frontend uses two version selectors scoped to
PUBLISHED versions, a file search box, active-file highlighting, and
whitespace-preserving unified view. E2E covers the publish + rerelease
+ approve round trip; controller/domain tests cover happy path and
same-version rejection.
Add an "Update" button to each skill card on the My Skills dashboard
page. Clicking it navigates to the Publish page with the skill's
namespace and visibility pre-selected, reducing manual steps when
re-publishing a skill package.
- Add visibility field to SkillSummaryResponse so the list API exposes
each skill's current visibility setting
- Add publish-prefill module to normalize and validate URL search params
- Wire TanStack Router validateSearch on the publish route
- Add E2E tests covering the prefill flow and invalid-param fallback
* feat(publish): allow warning-confirmed pre-publish checks\n\nFixes #287
* fix(i18n): add missing register validation translation keys
The registration form uses i18n keys like register.usernameInvalid,
register.passwordTooShort etc. but they were never defined in the
locale files, causing E2E tests to fail because the raw key strings
were displayed instead of human-readable messages.
* feat: display username and email in namespace member management
MemberResponse DTO now includes displayName and email fields.
NamespacePortalQueryAppService batch-loads UserAccount data via
findByIdIn to avoid N+1 queries. Frontend member table shows
username (with userId as fallback subtitle) and email columns
instead of raw user IDs.
* test(namespace): add displayName/email assertions and new test coverage
- Controller: add displayName and email assertions to addMember and updateMemberRole tests
- QueryAppService: add listMembers tests for batch user enrichment and null degradation
- CommandAppService: add addMember/updateMemberRole tests for displayName/email population and graceful degradation
Addresses PR #236 review feedback comments:
- Issue 2: Controller tests now assert displayName and email from mocked UserAccount
- Issue 3: Service layer tests now cover batch query and null user degradation
* fix: increase nginx upload limit and filter Chrome DevTools logs
- Add client_max_body_size 100M to nginx config to allow large skill package uploads
- Silently handle Chrome DevTools .well-known requests to reduce log noise
Fixes#193
* feat(domain): add Unicode slug support with emoji validation
- Update SLUG_PATTERN to support Unicode letters (\p{L}), numbers (\p{N}), and symbols (\p{So})
- Add UPPERCASE_PATTERN to maintain lowercase-only validation
- Modify slugify() to preserve Unicode characters instead of replacing with hyphens
- Add 8 new test cases covering Chinese, Japanese, Korean, emoji, and mixed Unicode slugs
- Maintain backward compatibility with existing ASCII slug validation
- All 16 tests passing
Implements Phase 1 of unicode-slug-support-v1.0-prd.md
* feat(web): add URL encoding for Unicode slugs and improve monospace font support
- Encode skill slugs in all navigation URLs using encodeURIComponent
- Encode slugs in API client methods for proper HTTP request handling
- Update share button to generate properly encoded URLs
- Extend monospace font stack with system fonts for better Unicode support
- All frontend tests pass (506 tests)
Related to Unicode slug support PRD phase 2 and 3
* feat(web): regenerate API types for Unicode slug support
- Update OpenAPI schema types after backend slug validator changes
- Reflects new Unicode-aware slug pattern validation
* remove
* fix(skill): resolve duplicate result error when deleting skill with shared namespace+slug
V13 migration changed the unique constraint from (namespace_id, slug) to
(namespace_id, slug, owner_id), allowing multiple skills with the same
namespace+slug but different owners. The findByNamespaceSlugAndSlug query
returned Optional<Skill> which threw IncorrectResultSizeDataAccessException
when 2 rows matched.
Changed the query to return List<Skill> and added ownerId query param to
DELETE endpoints so the frontend can specify exactly which skill to delete.
* fix(review): keep failed scans reviewable and expose feedback
* feat(profile): add field policy config and GET response
Add per-field edit policy configuration (editable, requiresReview) to
application.yml and expose it in the GET /api/v1/user/profile response
via a new fieldPolicies map, enabling the frontend to dynamically render
fields based on backend-driven policies.
* feat(profile): implement mixed submission in PATCH
Split profile update changes by per-field policy: fields without
requiresReview apply immediately, fields with requiresReview enter
the pending queue. Return PARTIALLY_APPLIED status with appliedFields
and pendingFields maps when both paths trigger in a single request.
* feat(web): rewrite profile page with dynamic fields
Render profile fields dynamically from backend fieldPolicies, with
whole-page read/edit mode toggle. Handle APPLIED, PENDING_REVIEW, and
PARTIALLY_APPLIED responses. Add i18n keys for review hints and
partial-apply toasts in both en and zh.
* merge: resolve deepwiki.yml conflict with package-lock.json fix
* api schema
* fix(profile): align moderation defaults and tests
* ci(deepwiki): run crawler on release publish
