feat(sell): allow for the control of your storefront branding

[HananINouman]

Operators can set seller-wide storefront branding with obol sell info set, independent of individual ServiceOffers. The controller publishes displayName, tagline, and logoUrl in the /api/services.json catalog envelope, and the public storefront consumes that envelope for the header, hero copy, metadata, manifest icons, favicon behavior, and generated OG image.

Summary

What changed:

• Adds seller-wide storefront branding fields: display name, tagline, and logo URL.
• Moves branding into the public /api/services.json catalog envelope so the storefront has one catalog fetch for services plus seller profile data.
• Adds obol sell info support for configuring seller branding without coupling it to any one ServiceOffer.
• Updates the public Next storefront to use seller branding in the header, metadata, web manifest, favicon/icon selection, and Open Graph image generation.
• Keeps the page hero title stable as Agent services while using the seller tagline for supporting copy.
• Fixes relative custom logo paths in /opengraph-image by resolving them against the public request origin before passing them to ImageResponse.
• Runs gofmt on the controller changes.

Why it matters:

• Sellers can present a recognizable storefront without duplicating branding across ServiceOffers.
• The public storefront reads a single catalog document for both services and branding, reducing fetch duplication and avoiding a separate public /api/storefront.json route.
• Relative logo paths no longer produce a runtime OG image failure.
• This is the first branding slice before broader customizable storefront work. The larger architecture proposal is tracked in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.

Risk level: medium

The change touches CLI UX, controller-rendered public catalog data, and public storefront rendering/metadata. It should not alter x402 payment routing, settlement, pricing, or ServiceOffer route behavior.

Commit under test: b734ca0aae5c0b2e75124956df6b3cf3bb7a5328

Base branch: main

Head branch: feat/storefront-customize

Scope

• Code
• Charts / manifests
• Flows / QA scripts
• Docs / skills
• Images / dependencies
• Other

Validation

CI checks at the time this description was updated:

Check	Status	Link
gitleaks	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505168/job/83447072531
lint-test	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072559
CRD generation up-to-date	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072546
CodeQL Analyze (actions)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068320
CodeQL Analyze (go)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068299
CodeQL Analyze (javascript-typescript)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068295
CodeQL Analyze (python)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068329

Local/unit checks:

go test ./cmd/obol ./internal/storefront ./internal/serviceoffercontroller -count=1
PASS

Storefront build:

cd web/public-storefront
npm ci
npm run build
PASS

Notes:

• npm ci reported existing dependency audit findings: 1 moderate, 1 high.
• next build passed. It emitted a workspace-root warning because a higher-level /Users/bussyjd/yarn.lock exists in this local environment.

Runtime spot check:

Mocked /api/services.json with logoUrl: "/custom.png"
GET /opengraph-image
HTTP 200

This validates the reviewed failure mode where ImageResponse previously rejected relative custom logo paths with Image source must be an absolute URL.

Integration tests:

Not run. This PR changes storefront branding/catalog rendering, not payment settlement or live chain flows.

Flow tests:

Flow	Network	QA machine label	Worktree	Result	Artifacts
Not run	N/A	N/A	N/A	N/A	N/A

Release smoke:

Not run.

Runtime / Security Notes

• Public route posture should remain unchanged for internal services: frontend and eRPC stay restricted to hostnames: ["obol.stack"].
• Public storefront branding is intentionally public metadata in the service catalog envelope.
• The storefront renderer still uses known local React components; this PR does not add arbitrary HTML, remote component execution, or public write actions.
• Custom logo handling now resolves relative URLs against the incoming request origin for generated OG images.

Live Chain Evidence

Not applicable. This PR does not register ERC-8004 identity, perform x402 purchases, or settle on-chain payments.

Review Notes

Known gaps:

• Broader storefront customization is intentionally out of scope for this PR. Architecture discussion and validation checklist are in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.
• Existing dependency audit findings from npm ci are not introduced or fixed here.
• Local signature verification reports the commit has a good SSH signature, but local Git cannot map it to a principal because /Users/bussyjd/.gitallowedsigners is not configured in this environment.

Follow-ups:

• Decide the next customization architecture before adding many more flat catalog fields. Proposed direction: versioned StorefrontConfig / StorefrontSnapshot and an Obol-owned A2UI-style component catalog (Architecture proposal: customizable public storefront via A2UI-style surface contract #669).
• Add stronger contract tests around catalog envelope parsing and fallback behavior if this surface keeps expanding.

Reviewer focus:

• CLI naming and operator UX: obol sell info set as the canonical branding command.
• Catalog contract: whether embedding branding in /api/services.json is the right public compatibility boundary.
• Storefront rendering: metadata, manifest, icon, and OG behavior with default, absolute custom, and relative custom logos.
• Security posture: confirm this does not broaden public tunnel exposure beyond intended storefront/catalog metadata.

[HananINouman]

Operators can set seller-wide storefront branding with obol sell info set, independent of individual ServiceOffers. The controller publishes displayName, tagline, and logoUrl in the /api/services.json catalog envelope, and the public storefront consumes that envelope for the header, hero copy, metadata, manifest icons, favicon behavior, and generated OG image.

Summary

What changed:

• Adds seller-wide storefront branding fields: display name, tagline, and logo URL.
• Moves branding into the public /api/services.json catalog envelope so the storefront has one catalog fetch for services plus seller profile data.
• Adds obol sell info support for configuring seller branding without coupling it to any one ServiceOffer.
• Updates the public Next storefront to use seller branding in the header, metadata, web manifest, favicon/icon selection, and Open Graph image generation.
• Keeps the page hero title stable as Agent services while using the seller tagline for supporting copy.
• Fixes relative custom logo paths in /opengraph-image by resolving them against the public request origin before passing them to ImageResponse.
• Runs gofmt on the controller changes.

Why it matters:

• Sellers can present a recognizable storefront without duplicating branding across ServiceOffers.
• The public storefront reads a single catalog document for both services and branding, reducing fetch duplication and avoiding a separate public /api/storefront.json route.
• Relative logo paths no longer produce a runtime OG image failure.
• This is the first branding slice before broader customizable storefront work. The larger architecture proposal is tracked in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.

Risk level: medium

The change touches CLI UX, controller-rendered public catalog data, and public storefront rendering/metadata. It should not alter x402 payment routing, settlement, pricing, or ServiceOffer route behavior.

Commit under test: b734ca0aae5c0b2e75124956df6b3cf3bb7a5328

Base branch: main

Head branch: feat/storefront-customize

Scope

• Code
• Charts / manifests
• Flows / QA scripts
• Docs / skills
• Images / dependencies
• Other

Validation

CI checks at the time this description was updated:

Check	Status	Link
gitleaks	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505168/job/83447072531
lint-test	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072559
CRD generation up-to-date	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072546
CodeQL Analyze (actions)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068320
CodeQL Analyze (go)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068299
CodeQL Analyze (javascript-typescript)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068295
CodeQL Analyze (python)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068329

Local/unit checks:

go test ./cmd/obol ./internal/storefront ./internal/serviceoffercontroller -count=1
PASS

Storefront build:

cd web/public-storefront
npm ci
npm run build
PASS

Notes:

• npm ci reported existing dependency audit findings: 1 moderate, 1 high.
• next build passed. It emitted a workspace-root warning because a higher-level /Users/bussyjd/yarn.lock exists in this local environment.

Runtime spot check:

Mocked /api/services.json with logoUrl: "/custom.png"
GET /opengraph-image
HTTP 200

This validates the reviewed failure mode where ImageResponse previously rejected relative custom logo paths with Image source must be an absolute URL.

Integration tests:

Not run. This PR changes storefront branding/catalog rendering, not payment settlement or live chain flows.

Flow tests:

Flow	Network	QA machine label	Worktree	Result	Artifacts
Not run	N/A	N/A	N/A	N/A	N/A

Release smoke:

Not run.

Runtime / Security Notes

• Public route posture should remain unchanged for internal services: frontend and eRPC stay restricted to hostnames: ["obol.stack"].
• Public storefront branding is intentionally public metadata in the service catalog envelope.
• The storefront renderer still uses known local React components; this PR does not add arbitrary HTML, remote component execution, or public write actions.
• Custom logo handling now resolves relative URLs against the incoming request origin for generated OG images.

Live Chain Evidence

Not applicable. This PR does not register ERC-8004 identity, perform x402 purchases, or settle on-chain payments.

Review Notes

Known gaps:

• Broader storefront customization is intentionally out of scope for this PR. Architecture discussion and validation checklist are in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.
• Existing dependency audit findings from npm ci are not introduced or fixed here.
• Local signature verification reports the commit has a good SSH signature, but local Git cannot map it to a principal because /Users/bussyjd/.gitallowedsigners is not configured in this environment.

Follow-ups:

• Decide the next customization architecture before adding many more flat catalog fields. Proposed direction: versioned StorefrontConfig / StorefrontSnapshot and an Obol-owned A2UI-style component catalog (Architecture proposal: customizable public storefront via A2UI-style surface contract #669).
• Add stronger contract tests around catalog envelope parsing and fallback behavior if this surface keeps expanding.

Reviewer focus:

• CLI naming and operator UX: obol sell info set as the canonical branding command.
• Catalog contract: whether embedding branding in /api/services.json is the right public compatibility boundary.
• Storefront rendering: metadata, manifest, icon, and OG behavior with default, absolute custom, and relative custom logos.
• Security posture: confirm this does not broaden public tunnel exposure beyond intended storefront/catalog metadata.

[HananINouman]

Operators can set seller-wide storefront branding with obol sell info set, independent of individual ServiceOffers. The controller publishes displayName, tagline, and logoUrl in the /api/services.json catalog envelope, and the public storefront consumes that envelope for the header, hero copy, metadata, manifest icons, favicon behavior, and generated OG image.

Summary

What changed:

• Adds seller-wide storefront branding fields: display name, tagline, and logo URL.
• Moves branding into the public /api/services.json catalog envelope so the storefront has one catalog fetch for services plus seller profile data.
• Adds obol sell info support for configuring seller branding without coupling it to any one ServiceOffer.
• Updates the public Next storefront to use seller branding in the header, metadata, web manifest, favicon/icon selection, and Open Graph image generation.
• Keeps the page hero title stable as Agent services while using the seller tagline for supporting copy.
• Fixes relative custom logo paths in /opengraph-image by resolving them against the public request origin before passing them to ImageResponse.
• Runs gofmt on the controller changes.

Why it matters:

• Sellers can present a recognizable storefront without duplicating branding across ServiceOffers.
• The public storefront reads a single catalog document for both services and branding, reducing fetch duplication and avoiding a separate public /api/storefront.json route.
• Relative logo paths no longer produce a runtime OG image failure.
• This is the first branding slice before broader customizable storefront work. The larger architecture proposal is tracked in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.

Risk level: medium

The change touches CLI UX, controller-rendered public catalog data, and public storefront rendering/metadata. It should not alter x402 payment routing, settlement, pricing, or ServiceOffer route behavior.

Commit under test: b734ca0aae5c0b2e75124956df6b3cf3bb7a5328

Base branch: main

Head branch: feat/storefront-customize

Scope

• Code
• Charts / manifests
• Flows / QA scripts
• Docs / skills
• Images / dependencies
• Other

Validation

CI checks at the time this description was updated:

Check	Status	Link
gitleaks	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505168/job/83447072531
lint-test	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072559
CRD generation up-to-date	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072546
CodeQL Analyze (actions)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068320
CodeQL Analyze (go)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068299
CodeQL Analyze (javascript-typescript)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068295
CodeQL Analyze (python)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068329

Local/unit checks:

go test ./cmd/obol ./internal/storefront ./internal/serviceoffercontroller -count=1
PASS

Storefront build:

cd web/public-storefront
npm ci
npm run build
PASS

Notes:

• npm ci reported existing dependency audit findings: 1 moderate, 1 high.
• next build passed. It emitted a workspace-root warning because a higher-level /Users/bussyjd/yarn.lock exists in this local environment.

Runtime spot check:

Mocked /api/services.json with logoUrl: "/custom.png"
GET /opengraph-image
HTTP 200

This validates the reviewed failure mode where ImageResponse previously rejected relative custom logo paths with Image source must be an absolute URL.

Integration tests:

Not run. This PR changes storefront branding/catalog rendering, not payment settlement or live chain flows.

Flow tests:

Flow	Network	QA machine label	Worktree	Result	Artifacts
Not run	N/A	N/A	N/A	N/A	N/A

Release smoke:

Not run.

Runtime / Security Notes

• Public route posture should remain unchanged for internal services: frontend and eRPC stay restricted to hostnames: ["obol.stack"].
• Public storefront branding is intentionally public metadata in the service catalog envelope.
• The storefront renderer still uses known local React components; this PR does not add arbitrary HTML, remote component execution, or public write actions.
• Custom logo handling now resolves relative URLs against the incoming request origin for generated OG images.

Live Chain Evidence

Not applicable. This PR does not register ERC-8004 identity, perform x402 purchases, or settle on-chain payments.

Review Notes

Known gaps:

• Broader storefront customization is intentionally out of scope for this PR. Architecture discussion and validation checklist are in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.
• Existing dependency audit findings from npm ci are not introduced or fixed here.
• Local signature verification reports the commit has a good SSH signature, but local Git cannot map it to a principal because /Users/bussyjd/.gitallowedsigners is not configured in this environment.

Follow-ups:

• Decide the next customization architecture before adding many more flat catalog fields. Proposed direction: versioned StorefrontConfig / StorefrontSnapshot and an Obol-owned A2UI-style component catalog (Architecture proposal: customizable public storefront via A2UI-style surface contract #669).
• Add stronger contract tests around catalog envelope parsing and fallback behavior if this surface keeps expanding.

Reviewer focus:

• CLI naming and operator UX: obol sell info set as the canonical branding command.
• Catalog contract: whether embedding branding in /api/services.json is the right public compatibility boundary.
• Storefront rendering: metadata, manifest, icon, and OG behavior with default, absolute custom, and relative custom logos.
• Security posture: confirm this does not broaden public tunnel exposure beyond intended storefront/catalog metadata.

[HananINouman]

Operators can set seller-wide storefront branding with obol sell info set, independent of individual ServiceOffers. The controller publishes displayName, tagline, and logoUrl in the /api/services.json catalog envelope, and the public storefront consumes that envelope for the header, hero copy, metadata, manifest icons, favicon behavior, and generated OG image.

Summary

What changed:

• Adds seller-wide storefront branding fields: display name, tagline, and logo URL.
• Moves branding into the public /api/services.json catalog envelope so the storefront has one catalog fetch for services plus seller profile data.
• Adds obol sell info support for configuring seller branding without coupling it to any one ServiceOffer.
• Updates the public Next storefront to use seller branding in the header, metadata, web manifest, favicon/icon selection, and Open Graph image generation.
• Keeps the page hero title stable as Agent services while using the seller tagline for supporting copy.
• Fixes relative custom logo paths in /opengraph-image by resolving them against the public request origin before passing them to ImageResponse.
• Runs gofmt on the controller changes.

Why it matters:

• Sellers can present a recognizable storefront without duplicating branding across ServiceOffers.
• The public storefront reads a single catalog document for both services and branding, reducing fetch duplication and avoiding a separate public /api/storefront.json route.
• Relative logo paths no longer produce a runtime OG image failure.
• This is the first branding slice before broader customizable storefront work. The larger architecture proposal is tracked in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.

Risk level: medium

The change touches CLI UX, controller-rendered public catalog data, and public storefront rendering/metadata. It should not alter x402 payment routing, settlement, pricing, or ServiceOffer route behavior.

Commit under test: b734ca0aae5c0b2e75124956df6b3cf3bb7a5328

Base branch: main

Head branch: feat/storefront-customize

Scope

• Code
• Charts / manifests
• Flows / QA scripts
• Docs / skills
• Images / dependencies
• Other

Validation

CI checks at the time this description was updated:

Check	Status	Link
gitleaks	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505168/job/83447072531
lint-test	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072559
CRD generation up-to-date	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072546
CodeQL Analyze (actions)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068320
CodeQL Analyze (go)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068299
CodeQL Analyze (javascript-typescript)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068295
CodeQL Analyze (python)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068329

Local/unit checks:

go test ./cmd/obol ./internal/storefront ./internal/serviceoffercontroller -count=1
PASS

Storefront build:

cd web/public-storefront
npm ci
npm run build
PASS

Notes:

• npm ci reported existing dependency audit findings: 1 moderate, 1 high.
• next build passed. It emitted a workspace-root warning because a higher-level /Users/bussyjd/yarn.lock exists in this local environment.

Runtime spot check:

Mocked /api/services.json with logoUrl: "/custom.png"
GET /opengraph-image
HTTP 200

This validates the reviewed failure mode where ImageResponse previously rejected relative custom logo paths with Image source must be an absolute URL.

Integration tests:

Not run. This PR changes storefront branding/catalog rendering, not payment settlement or live chain flows.

Flow tests:

Flow	Network	QA machine label	Worktree	Result	Artifacts
Not run	N/A	N/A	N/A	N/A	N/A

Release smoke:

Not run.

Runtime / Security Notes

• Public route posture should remain unchanged for internal services: frontend and eRPC stay restricted to hostnames: ["obol.stack"].
• Public storefront branding is intentionally public metadata in the service catalog envelope.
• The storefront renderer still uses known local React components; this PR does not add arbitrary HTML, remote component execution, or public write actions.
• Custom logo handling now resolves relative URLs against the incoming request origin for generated OG images.

Live Chain Evidence

Not applicable. This PR does not register ERC-8004 identity, perform x402 purchases, or settle on-chain payments.

Review Notes

Known gaps:

• Broader storefront customization is intentionally out of scope for this PR. Architecture discussion and validation checklist are in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.
• Existing dependency audit findings from npm ci are not introduced or fixed here.
• Local signature verification reports the commit has a good SSH signature, but local Git cannot map it to a principal because /Users/bussyjd/.gitallowedsigners is not configured in this environment.

Follow-ups:

• Decide the next customization architecture before adding many more flat catalog fields. Proposed direction: versioned StorefrontConfig / StorefrontSnapshot and an Obol-owned A2UI-style component catalog (Architecture proposal: customizable public storefront via A2UI-style surface contract #669).
• Add stronger contract tests around catalog envelope parsing and fallback behavior if this surface keeps expanding.

Reviewer focus:

• CLI naming and operator UX: obol sell info set as the canonical branding command.
• Catalog contract: whether embedding branding in /api/services.json is the right public compatibility boundary.
• Storefront rendering: metadata, manifest, icon, and OG behavior with default, absolute custom, and relative custom logos.
• Security posture: confirm this does not broaden public tunnel exposure beyond intended storefront/catalog metadata.

[HananINouman]

Operators can set seller-wide storefront branding with obol sell info set, independent of individual ServiceOffers. The controller publishes displayName, tagline, and logoUrl in the /api/services.json catalog envelope, and the public storefront consumes that envelope for the header, hero copy, metadata, manifest icons, favicon behavior, and generated OG image.

Summary

What changed:

• Adds seller-wide storefront branding fields: display name, tagline, and logo URL.
• Moves branding into the public /api/services.json catalog envelope so the storefront has one catalog fetch for services plus seller profile data.
• Adds obol sell info support for configuring seller branding without coupling it to any one ServiceOffer.
• Updates the public Next storefront to use seller branding in the header, metadata, web manifest, favicon/icon selection, and Open Graph image generation.
• Keeps the page hero title stable as Agent services while using the seller tagline for supporting copy.
• Fixes relative custom logo paths in /opengraph-image by resolving them against the public request origin before passing them to ImageResponse.
• Runs gofmt on the controller changes.

Why it matters:

• Sellers can present a recognizable storefront without duplicating branding across ServiceOffers.
• The public storefront reads a single catalog document for both services and branding, reducing fetch duplication and avoiding a separate public /api/storefront.json route.
• Relative logo paths no longer produce a runtime OG image failure.
• This is the first branding slice before broader customizable storefront work. The larger architecture proposal is tracked in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.

Risk level: medium

The change touches CLI UX, controller-rendered public catalog data, and public storefront rendering/metadata. It should not alter x402 payment routing, settlement, pricing, or ServiceOffer route behavior.

Commit under test: b734ca0aae5c0b2e75124956df6b3cf3bb7a5328

Base branch: main

Head branch: feat/storefront-customize

Scope

• Code
• Charts / manifests
• Flows / QA scripts
• Docs / skills
• Images / dependencies
• Other

Validation

CI checks at the time this description was updated:

Check	Status	Link
gitleaks	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505168/job/83447072531
lint-test	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072559
CRD generation up-to-date	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072546
CodeQL Analyze (actions)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068320
CodeQL Analyze (go)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068299
CodeQL Analyze (javascript-typescript)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068295
CodeQL Analyze (python)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068329

Local/unit checks:

go test ./cmd/obol ./internal/storefront ./internal/serviceoffercontroller -count=1
PASS

Storefront build:

cd web/public-storefront
npm ci
npm run build
PASS

Notes:

• npm ci reported existing dependency audit findings: 1 moderate, 1 high.
• next build passed. It emitted a workspace-root warning because a higher-level /Users/bussyjd/yarn.lock exists in this local environment.

Runtime spot check:

Mocked /api/services.json with logoUrl: "/custom.png"
GET /opengraph-image
HTTP 200

This validates the reviewed failure mode where ImageResponse previously rejected relative custom logo paths with Image source must be an absolute URL.

Integration tests:

Not run. This PR changes storefront branding/catalog rendering, not payment settlement or live chain flows.

Flow tests:

Flow	Network	QA machine label	Worktree	Result	Artifacts
Not run	N/A	N/A	N/A	N/A	N/A

Release smoke:

Not run.

Runtime / Security Notes

• Public route posture should remain unchanged for internal services: frontend and eRPC stay restricted to hostnames: ["obol.stack"].
• Public storefront branding is intentionally public metadata in the service catalog envelope.
• The storefront renderer still uses known local React components; this PR does not add arbitrary HTML, remote component execution, or public write actions.
• Custom logo handling now resolves relative URLs against the incoming request origin for generated OG images.

Live Chain Evidence

Not applicable. This PR does not register ERC-8004 identity, perform x402 purchases, or settle on-chain payments.

Review Notes

Known gaps:

• Broader storefront customization is intentionally out of scope for this PR. Architecture discussion and validation checklist are in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.
• Existing dependency audit findings from npm ci are not introduced or fixed here.
• Local signature verification reports the commit has a good SSH signature, but local Git cannot map it to a principal because /Users/bussyjd/.gitallowedsigners is not configured in this environment.

Follow-ups:

• Decide the next customization architecture before adding many more flat catalog fields. Proposed direction: versioned StorefrontConfig / StorefrontSnapshot and an Obol-owned A2UI-style component catalog (Architecture proposal: customizable public storefront via A2UI-style surface contract #669).
• Add stronger contract tests around catalog envelope parsing and fallback behavior if this surface keeps expanding.

Reviewer focus:

• CLI naming and operator UX: obol sell info set as the canonical branding command.
• Catalog contract: whether embedding branding in /api/services.json is the right public compatibility boundary.
• Storefront rendering: metadata, manifest, icon, and OG behavior with default, absolute custom, and relative custom logos.
• Security posture: confirm this does not broaden public tunnel exposure beyond intended storefront/catalog metadata.

[HananINouman]

Operators can set seller-wide storefront branding with obol sell info set, independent of individual ServiceOffers. The controller publishes displayName, tagline, and logoUrl in the /api/services.json catalog envelope, and the public storefront consumes that envelope for the header, hero copy, metadata, manifest icons, favicon behavior, and generated OG image.

Summary

What changed:

• Adds seller-wide storefront branding fields: display name, tagline, and logo URL.
• Moves branding into the public /api/services.json catalog envelope so the storefront has one catalog fetch for services plus seller profile data.
• Adds obol sell info support for configuring seller branding without coupling it to any one ServiceOffer.
• Updates the public Next storefront to use seller branding in the header, metadata, web manifest, favicon/icon selection, and Open Graph image generation.
• Keeps the page hero title stable as Agent services while using the seller tagline for supporting copy.
• Fixes relative custom logo paths in /opengraph-image by resolving them against the public request origin before passing them to ImageResponse.
• Runs gofmt on the controller changes.

Why it matters:

• Sellers can present a recognizable storefront without duplicating branding across ServiceOffers.
• The public storefront reads a single catalog document for both services and branding, reducing fetch duplication and avoiding a separate public /api/storefront.json route.
• Relative logo paths no longer produce a runtime OG image failure.
• This is the first branding slice before broader customizable storefront work. The larger architecture proposal is tracked in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.

Risk level: medium

The change touches CLI UX, controller-rendered public catalog data, and public storefront rendering/metadata. It should not alter x402 payment routing, settlement, pricing, or ServiceOffer route behavior.

Commit under test: b734ca0aae5c0b2e75124956df6b3cf3bb7a5328

Base branch: main

Head branch: feat/storefront-customize

Scope

• Code
• Charts / manifests
• Flows / QA scripts
• Docs / skills
• Images / dependencies
• Other

Validation

CI checks at the time this description was updated:

Check	Status	Link
gitleaks	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505168/job/83447072531
lint-test	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072559
CRD generation up-to-date	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072546
CodeQL Analyze (actions)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068320
CodeQL Analyze (go)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068299
CodeQL Analyze (javascript-typescript)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068295
CodeQL Analyze (python)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068329

Local/unit checks:

go test ./cmd/obol ./internal/storefront ./internal/serviceoffercontroller -count=1
PASS

Storefront build:

cd web/public-storefront
npm ci
npm run build
PASS

Notes:

• npm ci reported existing dependency audit findings: 1 moderate, 1 high.
• next build passed. It emitted a workspace-root warning because a higher-level /Users/bussyjd/yarn.lock exists in this local environment.

Runtime spot check:

Mocked /api/services.json with logoUrl: "/custom.png"
GET /opengraph-image
HTTP 200

This validates the reviewed failure mode where ImageResponse previously rejected relative custom logo paths with Image source must be an absolute URL.

Integration tests:

Not run. This PR changes storefront branding/catalog rendering, not payment settlement or live chain flows.

Flow tests:

Flow	Network	QA machine label	Worktree	Result	Artifacts
Not run	N/A	N/A	N/A	N/A	N/A

Release smoke:

Not run.

Runtime / Security Notes

• Public route posture should remain unchanged for internal services: frontend and eRPC stay restricted to hostnames: ["obol.stack"].
• Public storefront branding is intentionally public metadata in the service catalog envelope.
• The storefront renderer still uses known local React components; this PR does not add arbitrary HTML, remote component execution, or public write actions.
• Custom logo handling now resolves relative URLs against the incoming request origin for generated OG images.

Live Chain Evidence

Not applicable. This PR does not register ERC-8004 identity, perform x402 purchases, or settle on-chain payments.

Review Notes

Known gaps:

• Broader storefront customization is intentionally out of scope for this PR. Architecture discussion and validation checklist are in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.
• Existing dependency audit findings from npm ci are not introduced or fixed here.
• Local signature verification reports the commit has a good SSH signature, but local Git cannot map it to a principal because /Users/bussyjd/.gitallowedsigners is not configured in this environment.

Follow-ups:

• Decide the next customization architecture before adding many more flat catalog fields. Proposed direction: versioned StorefrontConfig / StorefrontSnapshot and an Obol-owned A2UI-style component catalog (Architecture proposal: customizable public storefront via A2UI-style surface contract #669).
• Add stronger contract tests around catalog envelope parsing and fallback behavior if this surface keeps expanding.

Reviewer focus:

• CLI naming and operator UX: obol sell info set as the canonical branding command.
• Catalog contract: whether embedding branding in /api/services.json is the right public compatibility boundary.
• Storefront rendering: metadata, manifest, icon, and OG behavior with default, absolute custom, and relative custom logos.
• Security posture: confirm this does not broaden public tunnel exposure beyond intended storefront/catalog metadata.

[HananINouman]

Operators can set seller-wide storefront branding with obol sell info set, independent of individual ServiceOffers. The controller publishes displayName, tagline, and logoUrl in the /api/services.json catalog envelope, and the public storefront consumes that envelope for the header, hero copy, metadata, manifest icons, favicon behavior, and generated OG image.

Summary

What changed:

• Adds seller-wide storefront branding fields: display name, tagline, and logo URL.
• Moves branding into the public /api/services.json catalog envelope so the storefront has one catalog fetch for services plus seller profile data.
• Adds obol sell info support for configuring seller branding without coupling it to any one ServiceOffer.
• Updates the public Next storefront to use seller branding in the header, metadata, web manifest, favicon/icon selection, and Open Graph image generation.
• Keeps the page hero title stable as Agent services while using the seller tagline for supporting copy.
• Fixes relative custom logo paths in /opengraph-image by resolving them against the public request origin before passing them to ImageResponse.
• Runs gofmt on the controller changes.

Why it matters:

• Sellers can present a recognizable storefront without duplicating branding across ServiceOffers.
• The public storefront reads a single catalog document for both services and branding, reducing fetch duplication and avoiding a separate public /api/storefront.json route.
• Relative logo paths no longer produce a runtime OG image failure.
• This is the first branding slice before broader customizable storefront work. The larger architecture proposal is tracked in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.

Risk level: medium

The change touches CLI UX, controller-rendered public catalog data, and public storefront rendering/metadata. It should not alter x402 payment routing, settlement, pricing, or ServiceOffer route behavior.

Commit under test: b734ca0aae5c0b2e75124956df6b3cf3bb7a5328

Base branch: main

Head branch: feat/storefront-customize

Scope

• Code
• Charts / manifests
• Flows / QA scripts
• Docs / skills
• Images / dependencies
• Other

Validation

CI checks at the time this description was updated:

Check	Status	Link
gitleaks	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505168/job/83447072531
lint-test	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072559
CRD generation up-to-date	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072546
CodeQL Analyze (actions)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068320
CodeQL Analyze (go)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068299
CodeQL Analyze (javascript-typescript)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068295
CodeQL Analyze (python)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068329

Local/unit checks:

go test ./cmd/obol ./internal/storefront ./internal/serviceoffercontroller -count=1
PASS

Storefront build:

cd web/public-storefront
npm ci
npm run build
PASS

Notes:

• npm ci reported existing dependency audit findings: 1 moderate, 1 high.
• next build passed. It emitted a workspace-root warning because a higher-level /Users/bussyjd/yarn.lock exists in this local environment.

Runtime spot check:

Mocked /api/services.json with logoUrl: "/custom.png"
GET /opengraph-image
HTTP 200

This validates the reviewed failure mode where ImageResponse previously rejected relative custom logo paths with Image source must be an absolute URL.

Integration tests:

Not run. This PR changes storefront branding/catalog rendering, not payment settlement or live chain flows.

Flow tests:

Flow	Network	QA machine label	Worktree	Result	Artifacts
Not run	N/A	N/A	N/A	N/A	N/A

Release smoke:

Not run.

Runtime / Security Notes

• Public route posture should remain unchanged for internal services: frontend and eRPC stay restricted to hostnames: ["obol.stack"].
• Public storefront branding is intentionally public metadata in the service catalog envelope.
• The storefront renderer still uses known local React components; this PR does not add arbitrary HTML, remote component execution, or public write actions.
• Custom logo handling now resolves relative URLs against the incoming request origin for generated OG images.

Live Chain Evidence

Not applicable. This PR does not register ERC-8004 identity, perform x402 purchases, or settle on-chain payments.

Review Notes

Known gaps:

• Broader storefront customization is intentionally out of scope for this PR. Architecture discussion and validation checklist are in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.
• Existing dependency audit findings from npm ci are not introduced or fixed here.
• Local signature verification reports the commit has a good SSH signature, but local Git cannot map it to a principal because /Users/bussyjd/.gitallowedsigners is not configured in this environment.

Follow-ups:

• Decide the next customization architecture before adding many more flat catalog fields. Proposed direction: versioned StorefrontConfig / StorefrontSnapshot and an Obol-owned A2UI-style component catalog (Architecture proposal: customizable public storefront via A2UI-style surface contract #669).
• Add stronger contract tests around catalog envelope parsing and fallback behavior if this surface keeps expanding.

Reviewer focus:

• CLI naming and operator UX: obol sell info set as the canonical branding command.
• Catalog contract: whether embedding branding in /api/services.json is the right public compatibility boundary.
• Storefront rendering: metadata, manifest, icon, and OG behavior with default, absolute custom, and relative custom logos.
• Security posture: confirm this does not broaden public tunnel exposure beyond intended storefront/catalog metadata.

[HananINouman]

Operators can set seller-wide storefront branding with obol sell info set, independent of individual ServiceOffers. The controller publishes displayName, tagline, and logoUrl in the /api/services.json catalog envelope, and the public storefront consumes that envelope for the header, hero copy, metadata, manifest icons, favicon behavior, and generated OG image.

Summary

What changed:

• Adds seller-wide storefront branding fields: display name, tagline, and logo URL.
• Moves branding into the public /api/services.json catalog envelope so the storefront has one catalog fetch for services plus seller profile data.
• Adds obol sell info support for configuring seller branding without coupling it to any one ServiceOffer.
• Updates the public Next storefront to use seller branding in the header, metadata, web manifest, favicon/icon selection, and Open Graph image generation.
• Keeps the page hero title stable as Agent services while using the seller tagline for supporting copy.
• Fixes relative custom logo paths in /opengraph-image by resolving them against the public request origin before passing them to ImageResponse.
• Runs gofmt on the controller changes.

Why it matters:

• Sellers can present a recognizable storefront without duplicating branding across ServiceOffers.
• The public storefront reads a single catalog document for both services and branding, reducing fetch duplication and avoiding a separate public /api/storefront.json route.
• Relative logo paths no longer produce a runtime OG image failure.
• This is the first branding slice before broader customizable storefront work. The larger architecture proposal is tracked in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.

Risk level: medium

The change touches CLI UX, controller-rendered public catalog data, and public storefront rendering/metadata. It should not alter x402 payment routing, settlement, pricing, or ServiceOffer route behavior.

Commit under test: b734ca0aae5c0b2e75124956df6b3cf3bb7a5328

Base branch: main

Head branch: feat/storefront-customize

Scope

• Code
• Charts / manifests
• Flows / QA scripts
• Docs / skills
• Images / dependencies
• Other

Validation

CI checks at the time this description was updated:

Check	Status	Link
gitleaks	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505168/job/83447072531
lint-test	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072559
CRD generation up-to-date	Passed	https://github.com/ObolNetwork/obol-stack/actions/runs/28174505186/job/83447072546
CodeQL Analyze (actions)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068320
CodeQL Analyze (go)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068299
CodeQL Analyze (javascript-typescript)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068295
CodeQL Analyze (python)	In progress	https://github.com/ObolNetwork/obol-stack/actions/runs/28174501577/job/83447068329

Local/unit checks:

go test ./cmd/obol ./internal/storefront ./internal/serviceoffercontroller -count=1
PASS

Storefront build:

cd web/public-storefront
npm ci
npm run build
PASS

Notes:

• npm ci reported existing dependency audit findings: 1 moderate, 1 high.
• next build passed. It emitted a workspace-root warning because a higher-level /Users/bussyjd/yarn.lock exists in this local environment.

Runtime spot check:

Mocked /api/services.json with logoUrl: "/custom.png"
GET /opengraph-image
HTTP 200

This validates the reviewed failure mode where ImageResponse previously rejected relative custom logo paths with Image source must be an absolute URL.

Integration tests:

Not run. This PR changes storefront branding/catalog rendering, not payment settlement or live chain flows.

Flow tests:

Flow	Network	QA machine label	Worktree	Result	Artifacts
Not run	N/A	N/A	N/A	N/A	N/A

Release smoke:

Not run.

Runtime / Security Notes

• Public route posture should remain unchanged for internal services: frontend and eRPC stay restricted to hostnames: ["obol.stack"].
• Public storefront branding is intentionally public metadata in the service catalog envelope.
• The storefront renderer still uses known local React components; this PR does not add arbitrary HTML, remote component execution, or public write actions.
• Custom logo handling now resolves relative URLs against the incoming request origin for generated OG images.

Live Chain Evidence

Not applicable. This PR does not register ERC-8004 identity, perform x402 purchases, or settle on-chain payments.

Review Notes

Known gaps:

• Broader storefront customization is intentionally out of scope for this PR. Architecture discussion and validation checklist are in Architecture proposal: customizable public storefront via A2UI-style surface contract #669.
• Existing dependency audit findings from npm ci are not introduced or fixed here.
• Local signature verification reports the commit has a good SSH signature, but local Git cannot map it to a principal because /Users/bussyjd/.gitallowedsigners is not configured in this environment.

Follow-ups:

• Decide the next customization architecture before adding many more flat catalog fields. Proposed direction: versioned StorefrontConfig / StorefrontSnapshot and an Obol-owned A2UI-style component catalog (Architecture proposal: customizable public storefront via A2UI-style surface contract #669).
• Add stronger contract tests around catalog envelope parsing and fallback behavior if this surface keeps expanding.

Reviewer focus:

• CLI naming and operator UX: obol sell info set as the canonical branding command.
• Catalog contract: whether embedding branding in /api/services.json is the right public compatibility boundary.
• Storefront rendering: metadata, manifest, icon, and OG behavior with default, absolute custom, and relative custom logos.
• Security posture: confirm this does not broaden public tunnel exposure beyond intended storefront/catalog metadata.