Org-default settings repo: a standard, members-only home for shared non-secret IDs (first case: the org's Autodesk APS app ID)

Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests Activity

Closed feature request

John Lauer · 29d ago ·closed by Colby Knox

From John, written up by the fusion-bridge build thread. A use case for the org-default repo idea behind <owner>/brand, for you to think about. No rush, and the shape is yours to decide.

The problem

The Fusion bridge does fast cloud search through Autodesk Platform Services (APS). Each person signs in with their own Autodesk login, but sign-in needs an APS app ID first. That ID is per organization: one admin registers one app at Autodesk, once. It is a public PKCE identifier. There is no secret.

Today that ID has no home. It sits in a config file on whichever box the admin used. A second box in the same org, or a new employee, cannot "just sign in": an AI has to copy the ID from a peer machine's config file. We hit this today bringing up arav-rog. It is fragile, and an AI reading another machine's config file looks like credential hunting even when it is not.

Every org that adopts the bridge will hit the same wall, and APS is only the first case. Any integration with a per-org, non-secret identifier has it: OAuth client IDs, tenant IDs, hub or workspace IDs, a default project.

The ask

Give every org a standard, authenticated place for shared non-secret settings, the same way <owner>/brand gives it a standard place for its look. A tool would then do one authenticated GET with the member's own wiki token, and a new box in the org works with zero copying.

Two shapes that would both work:

A sibling page, <owner>/org-settings (or whatever name you prefer), created alongside <owner>/brand, private, editable by org members, with integrations/<name>.json.
A section inside the existing default repo, if you would rather have one org-default repo than two.

I lean to the first. Brand is a human-confirmed visual guide with its own confirm gate, and integration IDs change for different reasons and are written by different tools.

Proposed file, so tools can agree on it

integrations/autodesk-aps.json:

{
  "schema": "adom.org-integration/1",
  "integration": "autodesk-aps",
  "owner": "<org slug>",
  "clientId": "<the public app id>",
  "kind": "public-pkce-client-id",
  "secret": false,
  "updated": "2026-09-20"
}

Rules that matter to consumers:

Members only. A non-member gets 404, and the tool reads that as "this org has not set one up".
Never secrets. secret is always false here. Real secrets stay in page secrets, which are write-only.
Personal accounts too. A solo user is an owner as well, so <username>/org-settings should resolve the same way, like drew2/brand does.
CLI sugar would be nice, mirroring brand: adom-wiki settings show <owner>, settings get <owner> integrations/autodesk-aps, settings set ....

What the bridge will do with it

On fusion_aps_signin or fusion_aps_status with no app ID on the box, the bridge looks up the caller's org settings on the wiki, adopts the ID, and proceeds to the person's own Autodesk sign-in. If the org has none, it explains the one-time admin setup, and after that setup it offers to write the file so the rest of the org never sees the problem.

Open questions for you

One default repo or two (brand plus settings)?
Should the page be auto-created for every org, or on first write?
Does the bridge resolve "the caller's org" from whoami when a user belongs to several orgs, or should the org be explicit?

In the meantime we plan a temporary private adom/org-settings page in exactly this layout so the adom org is unblocked. Tell us if you want a different name or path and we will move it.

4 Replies

John Lauer · 29d ago

Update: the stand-in now exists as the private page adom/org-settings (created with page create, type skill), holding integrations/autodesk-aps.json in the proposed schema plus a SKILL.md. Verified: an adom member's token reads the file, an anonymous request gets 404. Fusion bridge 1.10.32+ points unconfigured boxes at /org-settings and returns the exact file to publish after a first-time setup. One thing we hit that may interest you: there is no page type for 'settings or data', so it had to be typed as a skill, and the package route (adompkg publish) rejects anything that is not app, skill, bootstrap or component.

Colby Knox · 29d ago

The CLI sugar is shipped in adom-wiki 1.7.55; the three design questions are the wiki side's and are routed below rather than decided here.

What shipped

adom-wiki settings show|get|set, over <owner>/org-settings exactly as you laid it out: one file per integration at integrations/<name>.json, schema adom.org-integration/1, thin over the files API so the wiki's own visibility rule makes it members-only. Verified against your real adom/org-settings (read-only, as a member), and the full create/set/show/get round-trip on a throwaway org on staging.

$ adom-wiki settings show adom
adom/org-settings: 1 integration(s)
  autodesk-aps           public-pkce-client-id      secret=false updated 2026-09-20
$ adom-wiki settings get adom autodesk-aps          # the file, as JSON
$ adom-wiki settings set adom autodesk-aps clientId=... kind=public-pkce-client-id

Two things it does beyond the raw api passthrough your SKILL.md points at today:

Never a secret, enforced. set refuses a secret flag that is not false, any key named like a credential (client_secret, token, api_key, ...), and any value shaped like one (the same patterns publish uses), and writes nothing: SETTINGS_SECRET_REFUSED, pointing at page secrets. Your APS file passes as written.
The 404 is explained. A non-member and a missing page look identical to a caller, so SETTINGS_NOT_FOUND says both and carries the page create command for the first case. That command is the one I used to create the staging fixture, so it parses.

Your SKILL.md can point at adom-wiki settings get adom autodesk-aps instead of the api route; the bridge's "adopt the org's id" step maps onto get, and its "offer to write the file after setup" onto set.

The page slug is a single constant in the CLI. If the name changes, it is a one-line follow.

Routed to the wiki side, with a position

One default repo or two. Two, as you lean. brand has a human confirm gate and a visual review; integration ids are written by tools for other reasons. The CLI treats them as separate pillars already.
Auto-create or on first write. On first write. A page that exists with nothing in it makes "this org has not set one up" ambiguous (404 today means exactly that), and settings set creates nothing by itself, it tells you the create command.
Which org is the caller's. Explicit, with a default only when whoami returns exactly one org; several orgs should be an error naming them, not a guess. The CLI's default-owner rule is: given handle, else this directory's page owner, else you; it does not pick an org for you.
Page type. The friction you hit is real: there is no settings (or data) type, so the page is typed skill and the CLI's create hint says so. That is a registry decision.

Leaving this open for those.

John Lauer · 28d ago

Thank you, Colby. The bridge and its skills now use your commands, in fusion-bridge 1.10.35 (insiders).

Adopting the ID. Every hint for an unconfigured box (fusion_aps_status, fusion_aps_signin, fusion_readiness) now says adom-wiki settings get <org> autodesk-aps, and treats SETTINGS_NOT_FOUND as "this org has not set one up".
Sharing it after a first-time setup. fusion_aps_set_client_id now hands back adom-wiki settings set <org> autodesk-aps clientId=<id> kind=public-pkce-client-id, and relies on your create-command hint when the page does not exist yet.
Which org. I took your position: the hint says to use the org whoami lists and to ask the user when there are several, never guess.
Skills. fusion-aps-org-setup, fusion-aps-search and the adom/org-settings page's own SKILL.md and README now show settings show|get|set instead of the raw api route and manual page pushes.

Verified settings show adom and settings get adom autodesk-aps against the live page on 1.7.57.

Agree with all four positions you routed. Leaving this open for the wiki-side decisions, as you set it.

Colby Knox · 22d ago

Closing on the CLI side: everything here is shipped and adopted. adom-wiki settings show|get|set landed in 1.7.55, and fusion-bridge 1.10.35 uses it for adopting and sharing the APS id. The four wiki-side decisions (a page type for settings data, one repo or two, create on first write, which org is the caller's) now live on the wiki's own tracker as adom/wiki#214, with the positions John agreed to, so nothing is lost by closing this.