Development plans — redesign configuration guide

Redesign activation and coexistence

Specified in PRD: Development plan is included with Performance; there is no separate campaign activation switch. The profile replacement is behind enable new Neobrain hybrid platform mode.

Verified in code: SmrDisplayService::isIdpDisplayable() requires both enable_new_neobrain_hybrid_platform and the SMR-scoped read-user-development permission. The existing employee/manager pane gates still apply. If the check fails, the templates render legacy objectives. The frame resolves a personal or admin IDP path according to permitted space and the target user. A new header alone does not prove IDP activation.

Nextgen profile read routes require read-user-development; status/task routes require update-user-development-status. Other-user access additionally uses company and visibility filters. The rights migration makes both rights eligible for employee, manager, HR and admin presets; eligibility is not a deployed grant. The PRD makes admins read-only, so validate actual role grants before rollout.

Configure a redesigned campaign question

The steps below follow the PRD and the settings Observed in application. Creating/saving a new form was not exercised.

1. Open Performance → Forms [new] in an authorized administration workspace. Use an editable draft appropriate to the campaign.
2. Add a Development plan question within a section. Set its title and optional description; use role-based customization for wording when needed.
3. Set Required according to campaign policy. Confirm the campaign includes employee and manager, either together or sequentially. A second evaluator is an option, not a third evaluation mode.
4. Configure What participants can do using the table below.
5. Save the draft, reopen it and preview both employee and evaluator views before associating it with a test campaign.
6. Verify the plan-wide cap, allowed fields and retained historical content before launching. The PRD locks settings once the campaign launches.

Setting	PRD allowed values/default	Observed existing form
Maximum trainings requested per employee	Integer ≥ 0, no upper product bound; 0 = unlimited, default 0. Catalogue + off-catalogue across the whole plan.	4; label explicitly states 0 = unlimited.
Comments on requests	Switch, on.	On, disabled for editing.
Off-catalog requests	Switch, on.	On, disabled for editing.
Duration	Optional request field; switch on. Hidden from settings when off-catalogue disabled in PRD.	On.
URL	Optional request field; switch on.	On.
Wished start date	Optional request field; switch on. This is a training request date, not an axis deadline.	On.
Tasks within a development axis	Switch, on.	On.

Settings apply to all participant roles in the PRD; role-specific wording does not make off-catalogue requests manager-only. The PRD has no axis-count cap. PRD wording limits: question title 80 characters, description 500; axis title 80, description 2,000; off-catalogue description 2,000; comment 200. Confirm deployed validation rather than assuming local implementation matches all limits.

Local code differs from the deployed form and PRD

Verified in code: nextgen-front BuildDevelopment.vue exposes a minimum-1 request input, configurable manager-opinion levels (1–10, three initially), and tasks. Its validation requires a non-null positive cap and nonempty opinion labels. Nextgen-back ReviewDevelopmentQuestionDTO represents unlimited as null, allows positive caps, and defines tasks plus opinion options. These inspected files do not expose the full set of PRD switches shown in the deployed form.

Therefore do not submit 0 to the checked backend DTO expecting unlimited, and do not replace the deployed form's settings with the local schema. The local source and PS Testing are different evidence sets; no migration or deployment mapping was established. See the technical guide for further differences in evaluator rights and signature cleanup.

Historical content, safe rollout and rollback

Specified in PRD: switching comments, off-catalogue requests or tasks off in a later campaign does not delete old content. It restricts future additions/edits while retaining existing content and some status/removal operations. Disabled optional fields retain stored values. A stricter cap can leave a carried plan over limit; adding and advancing are blocked until participants remove sufficient requests. Each participant may need to remove their own additions.

Before rollout, record the current gates, rights, question settings and example profile contents. Validate one authorized employee, one manager and one read-only reader in the test tenant. Test manual creation, catalogue selection, limits, no-result AI, shared permissions, review signature and profile follow-up. Pay particular attention to preservation of unrelated/completed axes because the checked synchronization code differs from the PRD.

Restore recorded question settings on an editable draft or a later campaign according to campaign state. Reverting a display switch changes the rendered generation; it is not a verified data rollback. Recreating old settings does not reverse signature synchronization or deletions. No automatic migration/recovery procedure was established.

Troubleshooting

Symptom	Configuration check
Legacy editor remains visible	Module gate, hybrid flag and SMR read right; this can be intentional fallback.
Manager cannot see the pane	plandev, profile section, role scope and user visibility.
Can read but cannot change statuses	Separate status right and deployed role grant.
Existing form cannot be edited	Read-only form state/access; inspect an authorized editable draft.
Cannot publish local form with unlimited cap	Front validation requires positive value; backend uses null for unlimited. This differs from deployed 0 wording.
Request fields absent	Off-catalogue and individual field switches on the deployed form.
Plan blocked after reducing the cap	Historical requests still count; no automatic deletion.

Evidence and limitations

• Observed in application: legacy objective/action persistence and existing redesigned form settings in PS Testing as Jim Carter; no administrator save or campaign launch.
• Verified in code: legacy profile templates, Service/V2/SmrDisplayService.php, Company/ProspectBundle/Services/ViewSection/PerformanceSection.php; nextgen-front src/modules/ModuleConfig/Campaigns/modules/FormBuilder/{components/Builder/BuildDevelopment.vue,validation/developmentQuestion.validation.ts}; nextgen-back src/Domain/V2/ReviewForm/DTO/ReviewDevelopmentQuestionDTO.php, src/Http/Api/Routing/V2/development.yaml, rights migration Version20260909101500.php.
• Specified in PRD: Individual Development Plan, version 106, read 23 October 2026.
• Not verified: current tenant switch values/inheritance, permissions administration, draft save, mode restriction at runtime, rollout/migration, PDF and preservation after signature. No application source repository was modified.