Move the new FAQ entries from document/ (a generated tree that the docs
build does not read) to docs/skillhub/, which is what make docs-build and
the Pages deploy actually publish.
Also address review feedback:
- drop the SKILLHUB_BUILTIN_SKILLS_ENABLED tip; compose.release.yml does
not pass that variable through, so setting it has no effect
- correct the dependency list: object storage defaults to local, S3 is
recommended for production
- soften the 502 wording, since upstream/DNS/network can also cause it
- state the 32-character minimum for the cookie secret
- give a real bulk-install example and qualify v0.2.12 as a server version
- drop entries already covered by existing upgrade/MySQL/version questions
Signed-off-by: FenjuFu <92919259+FenjuFu@users.noreply.github.com>
Adds entries collected from real user-support threads to the reference FAQ
(both zh and en):
- 502 on auth APIs while the page loads, traced to server startup failure
on the SKILLHUB_DOWNLOAD_ANON_COOKIE_SECRET placeholder guard
- config changes not taking effect (.env.release.example vs .env.release,
restart vs recreate)
- built-in skill sync failure in offline environments
- upgrade path with Flyway auto-migration and volume retention
- external dependencies and the lack of MySQL support
- granting SUPER_ADMIN to an OAuth account via the bootstrap admin
- telling CLI and server versions apart
- installing skills into a target directory on an intranet
Signed-off-by: FenjuFu <fufenjupku@gmail.com>
When access-key / secret-key are left blank, fall back to the AWS
DefaultCredentialsProvider chain so that deployments on EC2, ECS,
and EKS can authenticate via instance profile, task role, or IRSA
without static credentials.
- Extract buildCredentialsProvider() in S3StorageService
- Add sts dependency for Web Identity Token (EKS) support
- Add unit tests for credential provider selection
- Update storage-spi docs (zh + en) and env example
* 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
* fix(auth): enable local bootstrap admin by default
