[poplolioi11]

The source-installation instructions use inconsistent directory and Conda environment names: cloning sfl.git creates sfl, but the next command enters secretflow; the environment is created as secretflow and activated as sfl. Use cd sfl and create the sfl environment to make both sequences consistent.

Fixes #131.

This PR also fixes the existing CircleCI path-filtering bootstrap failure encountered on the documentation change. Job 5323, at head aca2e9c, fails in Set parameters before filtering or tests: the downloaded get-pip.py rejects Python 3.9 and requires Python 3.10 or newer. Change only the filter job's image tag from 3.9 to 3.11, which the existing orb supports and the project already lists as supported. The mappings, continuation configuration, test selection and application dependencies are unchanged.

Validation:

• Original documentation correction on main c383e40: a local Git fixture reproduced the failing cd secretflow and passing cd sfl; Conda arguments agree, but Conda itself was not run.
• The targeted Sphinx 8.2.3/MyST HTML and gettext builds succeeded, all 35 extracted message IDs were unchanged, and real Chromium readback confirmed the rendered code blocks. No translation-catalog changes were required. The contribution guide's docs/update_po.sh is absent on this main, so a targeted gettext check was used.
• The same current get-pip.py fails under native Python 3.9.6 with the error from CircleCI, and succeeds under Python 3.11.18 using an isolated user-package directory. Installing virtualenv and creating a virtual environment also succeed under 3.11.
• The actual parameter helper embedded in the failed CircleCI configuration was exercised under both interpreters with six synthetic Git-change cases: documentation, source, tests, dependency metadata, continuation configuration and setup configuration. All 12 runs produced the expected parameters, unchanged between versions. Only its temporary output location was redirected for local isolation.
• Parsed YAML comparison confirms the image tag is the only CI configuration change; git diff --check passes. The official cimg/python:3.11 tag is active for Linux amd64.

The local bootstrap checks ran on macOS. After pushing 14a7374, CircleCI pipeline #320 successfully ran the actual Linux path-filtering job 5324, including bootstrap and continuation. The subsequent build and sfl-lite jobs 5325 and 5339 could not start: CircleCI reports resource-class-not-in-plan for the configured Docker 2xlarge+ resource class. That separate project-resource issue remains for maintainers; application tests have not run. The complete SFL installation and full documentation-site build were not run locally.

AI assisted the changes. An independent assistant statically reviewed the CI diagnosis; executable results above were produced by local commands, not by the reviewer.

[poplolioi11]

The GitHub check currently reports unittest-workflow failing at path-filtering/filter (1 of 1 job, before any unit-test jobs are shown): https://github.com/secretflow/sfl/runs/121529643729

This PR changes only the two installation code-block lines. The local Git naming reproduction, targeted Sphinx/MyST rendering, unchanged-gettext comparison and browser readback passed, as described above. I could not determine the filter failure's cause from the available GitHub summary, and have not changed the CI configuration or rerun the workflow.

Could a maintainer please inspect that filter job when reviewing? Thank you.

[poplolioi11]

I traced the filter failure to its actual Set parameters log: the current get-pip.py rejects Python 3.9 before parameter generation. Commit 14a73743c80688e4296db5c92fdfef2332c9fe79 changes only the filter executor tag to Python 3.11; mappings and application dependencies are unchanged. The PR description includes the local before/after checks.

The original blocker is now confirmed fixed on CircleCI: path-filtering job 5324 passes on that commit, and continuation succeeds.

The subsequent build job 5325 and sfl-lite job 5339 stop before execution with resource-class-not-in-plan: the configured Docker 2xlarge+ resource class is unavailable for this project or invalid. The other jobs are not run, so I am not claiming application-test success. Could a maintainer check the project's supported resource class? I have left the build/test resource settings unchanged. Thank you.