docs: align public API usage with owner contracts - #6
Conversation
|
A remediação foi implementada e validada localmente e no CI disponível. Solicito nova revisão sobre segurança, isolamento de tenant, idempotência, contratos, migrações e interoperabilidade entre módulos.\n\n@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 40b0efd0ff
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| client_assertion_type: { type: string, const: 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer' } | ||
| client_assertion: { type: string } | ||
| resource: { type: string } | ||
| tenant_id: { type: string } |
There was a problem hiding this comment.
Ao adicionar tenant_id aos schemas de authorization_code (e também de refresh_token, linhas 231-234), o contrato público passa a aceitar um tenant informado pelo cliente em grants que já devem estar vinculados ao authorization code/refresh token. Em validadores/SDKs gerados a partir deste OpenAPI, isso viola o modelo documentado de tenant derivado da identidade e cria um caminho suportado para tentativas de troca de tenant; mantenha o seletor somente no grant de serviço ou rejeite-o nesses grants.
Useful? React with 👍 / 👎.
| additionalProperties: false | ||
| required: [type, payload] | ||
| properties: | ||
| type: { type: string, enum: [PAYMENT_CAPTURE, PAYMENT_DISBURSEMENT, PAYMENT_SETTLEMENT, PAYMENT_RECONCILIATION] } | ||
| queue: { type: string, const: payments, default: payments } | ||
| payload: | ||
| oneOf: | ||
| - $ref: '#/components/schemas/PaymentStartPayload' | ||
| - $ref: '#/components/schemas/PaymentSettlementPayload' | ||
| - $ref: '#/components/schemas/PaymentReconciliationPayload' | ||
| max_attempts: { type: integer, minimum: 1, default: 3 } | ||
| type: { type: string, const: PAYMENT_CAPTURE } | ||
| payload: { $ref: '#/components/schemas/PaymentStartPayload' } |
There was a problem hiding this comment.
Com este novo schema, cada variante de CreateJob tem additionalProperties: false e expõe apenas type e payload; porém src/content/docs/v1/guides/payment-jobs.mdx:16 ainda instrui o envio de queue e max_attempts. Esse curl copiado pelos integradores será rejeitado como 400 contra o contrato publicado, então remova esses campos do guia ou recoloque-os no schema se ainda forem aceitos.
Useful? React with 👍 / 👎.
| - $ref: '#/components/schemas/CreatePaymentDisbursementJob' | ||
| - $ref: '#/components/schemas/CreatePaymentSettlementJob' | ||
| - $ref: '#/components/schemas/CreatePaymentReconciliationJob' | ||
| discriminator: { propertyName: type } |
There was a problem hiding this comment.
Sem mapping, a resolução do discriminator do OpenAPI usa o valor de type como nome implícito de schema em components (especificação); como os payloads usam PAYMENT_CAPTURE, PAYMENT_DISBURSEMENT, etc., mas os schemas se chamam CreatePaymentCaptureJob e similares, geradores/validadores que aplicam o discriminator não conseguem selecionar o subtype correto. Adicione um mapping de cada valor de type para o respectivo schema ou remova o discriminator e deixe o oneOf ser resolvido pelos const.
Useful? React with 👍 / 👎.
1 participant
Summary
private_key_jwt, the five institutional roles, canonical production hosts, and durable legacy batch states.Validation
pnpm guardian:checkpnpm contracts:checkpnpm testpnpm buildNotes
The portal builds 22 static pages and preserves owner contract provenance through
sources.lock.json.